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