Ideas for improving UX for restic find, dump, restore

Features and Ideas
1

I’m using restic 0.9.3.

As I’m starting to use restic, I thought I’d note a few places where the default behavior was surprising to me, in case it sparks interest in any (backward compatible) improvements. I’m happy to file github issues or pull requests against any/all of them, but I’m to new to this forum, and looking for advice on what is appropriate, or if they are all uninteresting.

Find:

% restic find /etc/pass*
Found matching entries in snapshot d6c808d9
/etc/passwd
/etc/passwd-

My suggestion: This would be more useful, I think, if the output contained the snapshot host/timestamp also, and the snapshots should be displayed sorted by timestamp (just like restic snapshots), instead of in random order. I’d expect the output would be similar to “restic snapshots” with the found files listed for each snapshot.

% restic find /etc/pass*
repository 6939311d opened successfully, password is correct
ID        Time                 Host                Tags        Paths    Files
-------------------------------------------------------------------------------------------
d6c808d9  2019-01-14 13:51:26  host.example.com              /etc
     /etc/passwd
     /etc/passwd-

413251b6  2019-01-15 12:21:30  host.example.com              /etc
     /etc/passwd
     /etc/passwd-

Dump:

What I want to say:

% restic dump latest /etc/passwd

As is, this didn’t work for me, since my latest snapshot is for another top-level directory. I expected “latest” to exclude snapshots that don’t contain /etc/passwd. (Workaround is to use the --path flag).

My suggestion: When calculating the “latest” snapshot for a file or folder, choose the latest snapshot that contains that file or folder (i.e. logically, the snapshot from a “find” command on that file, having the latest timestamp). I’d rather pay the cost of the search as part of my dump request, rather than get no result and have to do the search manually to get the right snapshot id, then manually give that to dump.

Restore:

What I wanted to say to simply get back files I accidentally modified:

% sudo restic restore latest /etc/pass*
Found /etc/passwd in snapshot 12345678 (2019-01-14 13:51:26 host.example.com).
Overwrite existing /etc/passwd [y/N/a/q]:  y
/etc/passwd restored
Found /etc/passwd- in snapshot 12345678 (2019-01-14 13:51:26 host.example.com).
Overwrite existing /etc/passwd- [y/N/a/q]: q
/etc/passwd- unchanged, restore aborted, quitting.

(i.e. when a file exists and is about to be overwritten, in the absence of a --force flag, ask for confirmation: yes restore it, no don’t restore it, restore this and all remaining without asking for further confirmation, quit/abort)

I expected the arguments to be parallel to “restic dump” i.e. , rather than putting those in flags (natch, the -i flag would remain for backward compatibility).

In 0.9.3, I get an error if I don’t specify the --target flag. I can see how this is for safety, but I’d prefer having overwrite confirmation for safety, regardless of target. I expected that the default would be to restore to original location with confirmation, if I wanted to put it someplace else, I’d specify that with a --target flag, and if I wanted to overwrite without confirmation, I’d specify a --force (-f) flag. It seems that overwriting existing files during a restore should always require confirmation by default (absent --force), whether restoring to the original location or to an explicit target. (If the target is an empty directory, then there would be no overwriting, thus no confirmation requests).

Does any of this sound worth pursuing?

1 Like
2

I’d argue that this would be surprising behavior for most users. If a snapshot doesn’t have a specific file, the answer is “file not found” and not “let me go look for another snapshot containing that file.”

IMO, latest is already a bit “too magic” and I prefer explicitly listing snapshot IDs. I would suggest that everyone else do so as well. Having a magic keyword refer to something you didn’t expect it to is a bad thing for software to do to you.

Adding more magic to that keyword seems like a move in the wrong direction.

I disagree here, as well. The current behavior makes the most sense: tell restic exactly where you want to put the files. (--target / really isn’t that hard to write, is it?)

Restoring to / by default invites trouble. Let’s say you restore a backup where some files have since been deleted. You’re going to restore a bunch of files without confirmation, which you may not have intended to and now you have to go “weed” your filesystem of stuff you didn’t mean to restore into the root of the filesystem.

This is especially true when running restic as root, where you have the potential to throw old data all over your filesystem by mistake with no easy way to clean up the mess.

--target is required for a very good reason.

Taking that a step further, --target / is so dangerous that you should never even do it. Restore somewhere under /tmp, verify that you got the data you wanted to, and then move the data back where it goes.

There is also restic mount which provides a more interactive way to look for what you need and inspect it prior to restoring it, without restoring into a temporary location.

3

Good feedback. Thanks!

1 Like
4

You are right, this could be improved. There’s already an open ticket on Github for this:

2 Likes
5

Thanks for pointing that out. I’m sorry I didn’t see that when I was looking through the bug reports.

1 Like