#1952 new enhancement

rename "tahoe backup" to "tahoe snapshot" — at Version 8

Reported by: zooko Owned by:
Priority: normal Milestone: undecided
Component: code-frontend-cli Version: 1.9.2
Keywords: tahoe-backup usability docs Cc: tahoe-lafs.org@…
Launchpad Bug:

Description (last modified by ambimorph)

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.

Change History (8)

comment:2 follow-ups: Changed at 2013-04-23T05:31:24Z by 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.

comment:3 in reply to: ↑ 2 Changed at 2013-04-23T07:38:15Z by 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.

comment:4 in reply to: ↑ 2 ; follow-up: Changed at 2013-04-23T15:03:25Z by 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?

comment:5 Changed at 2013-04-29T20:24:20Z by daira

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

comment:6 in reply to: ↑ 4 Changed at 2013-04-29T20:26:54Z by 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)).

comment:7 Changed at 2013-04-29T20:29:40Z by 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.

comment:8 Changed at 2014-06-16T00:30:03Z by ambimorph

  • Description modified (diff)

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.

Note: See TracTickets for help on using tickets.