Is restore missing an -id switch? (And other thoughts)

Support
#1

Need a quick sanity check before writing an issue or maybe diving into the code:

I have two systems (foo and bar) that are backed up to the same storage with IDs of the same names. foo has been retired but its snapshot and revisions were kept around in case there was a need to restore anything. That need arose and I went to restore some of its files to bar but found there was no way to make restore use the foo id other than adding an entry to the preferences file that’s identical other than the id field.

Is my read on that correct? All of the other commands that can operate on storage except init and backup have an -id switch. Is there a reason restore doesn’t?

A couple of other things I’ve observed while doing some overhaul of the duplicacy-scripts package:

The terminology surrounding IDs, snapshots and revisions seems inconsistent. If there are storages (e.g., wasabi://us-east-1@s3.wasabisys.com/bucket) containing IDs (foo, bar) and IDs containing revisions (1, 2, 3), what’s a snapshot and why is it called that?

It seems like the storage configuration should define only access to the storage itself and the commands should consistently have an -id switch to pick a snapshot.

That’s my TED talk, thanks for listening. :slight_smile:

#2

Only init and add have an -id switch; backup and restore do not. The reason is, the ID should be defined once, when you set up the backup/restore. It is a dangerous situation if you can freely change the ID when doing a backup/restore which might lead to accidental overwrites.

#3

Only init and add have an -id switch; backup and restore do not.

The list, check, cat, diff, history, prune and copy commands have an -id switch, too. There’s more destructive potential in prune than restore: restoring from the wrong ID can be undone by restoring from the right one; mistakenly-pruned revisions are gone for good.

The reason is, the ID should be defined once, when you set up the backup/restore. It is a dangerous situation if you can freely change the ID when doing a backup/restore which might lead to accidental overwrites.

As a default when doing backups, absolutely. There’s never a reason to write a machine’s data to a different backup set.

Can’t say I agree with that philosophy when it comes to restores, but I’m one of those people who believes the rm chainsaw shouldn’t have a blade guard. Restoring files from defunct systems’ backups is a common-enough operation that calling it a fundamental feature for backup software isn’t a stretch. Adding an additional argument to a command line to pick a different ID isn’t any more dangerous than picking a different system’s tape off the shelf.

The restore script I use to wrap Duplicacy allows restoration to directories other than the original location by exploiting the fact that Duplicacy looks for a .duplicacy file in the current directory. Exploiting it further by writing a one-time-use configuration with the ID set as I want it is a hack, but it’s one I can live with if I need to.

#4

Hardly. Prune doesn’t do anything without enough parameters.

This assumes you have a recent backup since the b0rked prune.

Initialising an empty area separate from other IDs is simply safer than allowing users to accidentally restore the wrong data on top of a repository. Since by default, restore behaviour is that you’re restoring data of the current repository - not to anything other than the original location - therefore, it makes sense it has somewhere sensible for it to be restored to, and that’s the correct OR empty location.

This is less about a missing -id parameter and more about where Duplicacy keeps its metadata in general. Rclone, for instance, keeps its in ~/.config/.rclone. Duplicacy instead uses the cwd. That’s the philosophy, and it should be one or the other not both.

Now, there might be an argument for moving away from that, but with the current workings, merely providing an -id flag would be insufficient - you’d also need some kinda mandatory -restoreto param to keep it safe. So changing the philosophy now would be dangerous, yes. (Personally, I’m not against deprecating the old methodology and using a central config, but until such time… adding just -id would be the real hack here IMO.)

#5

Wherever the configuration lives, it still takes custom-written preferences to get restore to use a different ID. A global switch to set the preferences directory would be welcome, but the current arrangement (CWD and parents) allows it to be forced with a cd.

The current workings are fine. With the default behavior being in-place, a mandatory -restoreto when -id is present would be, too. I’d use both all the time anyway.

Lack of -restoreto was why the workaround in my wrappers was developed in the first place. The only time I ever do in-place restores is when the destination is completely gone (e.g., disk failure or misapplied rm -rf). It’s taken seven years for me to need to restore files from a different system. I got around it manually that time and, in the interest of utility, a second workaround for other IDs is in the works.

If end-user safety is the priority, there’s an argument to be made for not allowing users to do operations on IDs not in the configuration (list, cat, diff, history). After years of inspecting the contents of IDs written by other systems with those commands, I found the inability to restore them surprising and wondered if it was an oversight.