marcusklaas / backbonzo Goto Github PK

The reason is twofold: std::fs::Metadata has been removed from the stdlib. Instead, we should use something like https://github.com/alexcrichton/filetime. Secondly, we still rely on the iter_reduce crate, which is gone now. We should be able to switch to itertools relatively easily (http://bluss.github.io/rust-itertools/doc/itertools/trait.Itertools.html#method.fold_results).

Specifically on how to drive this thing.

Should be twice as dense as hex encoding.

Write 1 hour and 30 seconds instead of 3630 seconds, for example.

For example: set all timestamps to the unix epoch after completing a transfer.

Currently, an attacker can gather more information on the sequence of blocks.

Number of deleted blocks/ bytes.

Idem for &Path/ PathBuf.

Check that data has not been tampered with

It will show up in the process list etc. There are plenty of alternatives:

• pass as file descriptor
• set as environment variables
• read from file

This way we don't wait for the sqlite file to be flushed to disk for every update. It will speed up the backup process significantly.

After many months of neglect, it has finally stopped compiling.

We probably need to store hashes after encryption as well, which will inflate our index size... The alternative is to decrypt files and compute hashes after. Which can be done now by restoring to /dev/null.

Need to think about this a bit more...

Combining a backup and cleanup in a single operation is problematic. When a file backup isn't fully completed in a backup due to a time out, its blocks are removed in the cleanup. This means work is discarded.

If we manage this ourselves, we no longer have to pass databases to our exporter threads. It will reduce database contention as well. Ideally, we'd just use the sqlite database a storage mechanism. We could do the same for file hashes.

It seems to die on cargo test because sqlite3 cannot handle pragma queries very well...

With a commit hash, version and link to this page.

Goal is to make clear to whoever finds a backbonzo backup what it is and how to decrypt it.

For example when a directory contains a symlink to itself. The easiest solution would be to ignore symlinks altogether.