rename "tahoe backup" to "tahoe snapshot" #1952

New Issue

zooko · 2013-04-23T03:52:01Z

zooko commented

2013-04-23 03:52:01 +00:00

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:/tahoe-lafs/trac-2024-07-25/issues/6978, comment:14:/tahoe-lafs/trac-2024-07-25/issues/6978.

`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:[/tahoe-lafs/trac-2024-07-25/issues/6978](/tahoe-lafs/trac-2024-07-25/issues/6978), comment:14:[/tahoe-lafs/trac-2024-07-25/issues/6978](/tahoe-lafs/trac-2024-07-25/issues/6978).

zooko added the

labels 2013-04-23 03:52:01 +00:00

zooko added this to the undecided milestone 2013-04-23 03:52:01 +00:00

zooko commented

2013-04-23 03:59:10 +00:00

[//pipermail/tahoe-dev/2013-April/008200.html mailing list thread]

daira commented

2013-04-23 05:31:24 +00:00

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.

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 commented

2013-04-23 07:38:15 +00:00

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.

Replying to [daira](/tahoe-lafs/trac-2024-07-25/issues/1952#issuecomment-91514): > 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 commented

2013-04-23 15:03:25 +00:00

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?

Replying to [daira](/tahoe-lafs/trac-2024-07-25/issues/1952#issuecomment-91514): > 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 commented

2013-04-29 20:24:20 +00:00

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

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

daira commented

2013-04-29 20:26:54 +00:00

Replying to [zooko]comment:4:

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)).

Replying to [zooko]comment:4: > 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 commented

2013-04-29 20:29:40 +00:00

... 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.

... 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 commented

2014-06-16 00:30:03 +00:00

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.

I just went through a similar experience as described in [Taylor's S4 Usability Notes](https://github.com/LeastAuthority/leastauthority.com/issues/196) 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 commented

2014-06-16 16:30:29 +00:00

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:91519 are imagined future features).

Replying to [ambimorph](/tahoe-lafs/trac-2024-07-25/issues/1952#issuecomment-91520): > I just went through a similar experience as described in [Taylor's S4 Usability Notes](https://github.com/LeastAuthority/leastauthority.com/issues/196) 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:91519](/tahoe-lafs/trac-2024-07-25/issues/1952#issuecomment-91519) are imagined future features).

lpirl commented

2015-01-06 12:00:51 +00:00

Replying to daira:

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

+1!

Replying to [daira](/tahoe-lafs/trac-2024-07-25/issues/1952#issuecomment-91519): > I wouldn't be averse to having `tahoe snapshot` be an alias for, say, `tahoe cp -r --immutable --use-backupdb`. +1!

Sign in to join this conversation.