rename "tahoe backup" to "tahoe snapshot"

[zooko]

tahoe backup is a good tool! It does a really cool thing. However, it doesn't do "backup". Proof: there is no tahoe restore. If you were try to simulate "restore" by running tahoe cp -r, it would be unable to do all sorts of things that you expect from a backup-and-restore program, such as restoring symlinks, restoring mtime and ctime, restoring uid and gid, or delta-compressing between subsequent versions.

Maybe we should rename tahoe backup to tahoe snapshot. Then people who want backup would stop complaining that tahoe backup is a crummy backup tool, they would start using a good backup tool (such as duplicati+Tahoe-LAFS), and they would start using the newly created tahoe snapshot tool for its cool snapshot-making behavior.

See comment:13:ticket:1946, comment:14:ticket:1946.

[zooko]

mailing list thread

[daira]

I'd much rather enhance tahoe backup to record more metadata (and to tolerate errors better), and add a tahoe restore (or tahoe cp --restore) command to restore that metadata. I think that tahoe backup is a good idea for backups because:

• it makes effective use of immutable files and directories;
• I like the transparency of a backup being a snapshot rather than some opaque thing in some weird format I don't understand, as it is for most backup programs.

[ClashTheBunny]

Replying to daira:

I'd much rather enhance tahoe backup to record more metadata (and to tolerate errors better), and add a tahoe restore (or tahoe cp --restore) command to restore that metadata.

I think that this would be nice for many reasons, including making Tahoe-LAFS more of a file system and less just an object store.

• I like the transparency of a backup being a snapshot rather than some opaque thing in some weird format I don't understand, as it is for most backup programs.

From the Duplicati website:

Duplicati is built using standard tools and formats. Un-encrypted archives are simple .zip archives. Encrypted archives are .zip archives that can be decrypted with AES Crypt. So, even without Duplicati all your data are belong to you :-)

And from duplicaty's webiste:

Standard file format: Athough archive data will be encrypted, inside it is in standard GNU-tar format archives. A full backup contains normal tarballs, and incremental backups are tar archives of new files and the deltas from previous backups. The deltas are in the format produced by librsync's command-line utility rdiff.

Although you should never have to look at a duplicity archive manually, if the need should arise they can be produced and processed using GnuPG, rdiff, and tar.

[zooko]

Replying to daira:

I'd much rather enhance tahoe backup to record more metadata

But, even after someone does that, mightn't people still want a tahoe snapshot that doesn't record more metadata, for the other use case?

[daira]

See also #1325 (make tahoe backup keep more filesystem metadata).

[daira]

Replying to zooko:

But, even after someone does that, mightn't people still want a tahoe snapshot that doesn't record more metadata, for the other use case?

See #658 ("tahoe cp" should avoid full upload/download when the destination already exists (using backupdb and/or plaintext hashes)).

[daira]

... and #835 ("tahoe cp -r --mutable/--immutable": make mutable copy of immutable directories or vice versa).

I wouldn't be averse to having tahoe snapshot be an alias for, say, tahoe cp -r --immutable --use-backupdb.

[ambimorph]

I just went through a similar experience as described in ​Taylor's S4 Usability Notes for the tahoe-LAFS part in terms of managing the interfaces (both web and command line), and trying to not so much *restore* but even *find* the files that I backed up. I independently discovered this same discussion about backup vs. snapshot, and tahoe cp -r.

I now don't understand why I would ever use backup instead of cp -r, if I want to be able to navigate the files later. It also took me a long time to figure out how to get the top level directory included in the cp, by repeating the name of it after the alias.

[daira]

Replying to ambimorph:

I just went through a similar experience as described in ​Taylor's S4 Usability Notes for the tahoe-LAFS part in terms of managing the interfaces (both web and command line), and trying to not so much *restore* but even *find* the files that I backed up. I independently discovered this same discussion about backup vs. snapshot, and tahoe cp -r.

I now don't understand why I would ever use backup instead of cp -r, if I want to be able to navigate the files later. It also took me a long time to figure out how to get the top level directory included in the cp, by repeating the name of it after the alias.

tahoe backup backs up the whole directory structure; the use of the backupdb to not upload some files/directories is just an optimisation, and the corresponding links to already-uploaded objects are still made on the Tahoe side. Note that this depends on the structure created by tahoe backup being immutable. tahoe cp -r is not able to use this optimisation because it always creates mutable directories (the --immutable and --use-backupdb options mentioned in comment:7 are imagined future features).

[lpirl]

Replying to daira:

I wouldn't be averse to having tahoe snapshot be an alias for, say, tahoe cp -r --immutable --use-backupdb.

+1!