New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unable to backup/restore files/dirs with same name #549
Comments
Thanks for reporting this issue, I think this is a bug. |
Probably will happen whenever top-level directories have the same name. Because the full path is not restored, only the top-level directory. Solution is to reconstruct the full path upon restore, and restore each tree into the full path. So resulting path would be like Does the patch need to be implemented as part of the restore? |
I also suspect this is the case. At the moment, restic works like this: When called as
So only the last path component from the arguments to the In order to correct this, I propose implementing the same behavior as
This will require some work in the archiver part of restic. I don't think we'll need to touch restore at all. |
#588 I reported the same thing. But that one has a test case you can use. |
@fd0 I propose to also include an option (--store-full-path) to backup where it explicitly stores the full 'real' path of the backup target. The reasoning is that in the tar case and with several other backup tools you can get a little convoluted restore tree. While this is a good sane default I personally would like it if my restores resemble the entire layout of the original filesystem for host backups. (Even better if restore could also prefix the hostname to the restore location) |
@trbs I think the default needs to be to store full paths, with a switch for the special case of using relative paths. Reason being that rel paths can produce unexpected or undefined behaviour, but abs can't. If you want to request prefixes or some other form of path mangling, I'd suggest that's an entirely separate issue. |
I've thought about this and I think we need to change the backup behavior so that always the full path (as given on the command-line) is saved. That's what |
+1 for |
Hate to just +1, but I'm also very interested in solution for this bug. Have several pending installations of restic, where this bug is unfortunately a showstopper. Thanks @fd0 for your work on this, I understand it's not easy to unwind now. |
-1 for As to prefixing the hostname to the backup location, this seems it can be easily done from the cmdline, as most people know from which host they are going to restore beforehand :) |
Given that you're not 1.0 yet, I vote that, if a breaking change has to be made in order for the ideal fix, go ahead and do it sooner rather than later. |
@mholt I agree, I'm already working on this. As I said, this is caused by a bad design decision early on and needs to be corrected. |
Maybe not for 0.7.1, but for 0.8.0 or so. I've already started working on it though. Maybe a bit of background: This is caused by the archiver code, which is the oldest code present in restic. Unfortunately (as I was just beginning to learn Go back in 2013/2014) the archiver code is very complex and I made a lot of beginner mistakes (too much concurrency, too many channels). I also worried about things that turned out to be not a problem at all, and overlooked things that became a problem (e.g. the index handling). So, I've already started on reimplementing the archiver code completely, using concurrency only when it makes sense (i.e. processing individual chunks) and not reading 20 files from the disk in parallel. This code also includes proper directory walking and will insert the complete paths into the repo. Fortunately, this is really just the archiver that needs to be touched, the rest of the code will (thanks to the design of restic and the repo) just continue to work fine. |
will this change affect existing repositories and if so, how? |
"affecting" in terms of "new backups will have a slightly different structure", yes, but that's about it. No |
@fd0 Any idea when we might expect snapshots that contain the full original path? We are currently working on automating backups and restores using restic. When automating the restore, having the source path intact is essential. If I have a server with two 'data' directories being backed up (and this is not theoretical, we have a number of servers with Confluence and JIRA 'data' directories that need to be backed up) - the restore process needs to know which data directory belongs to Confluence and which data directory belongs to JIRA. A name like 'data' and 'data-1' obviously doesn't cut it here. I think the best workaround for now is backing up the data directories in seperate snapshots and tagging them with 'JIRA' or 'Confluence'? |
There's no timeline, sorry. |
Yes, but per #1225 you won't be able to easily merge them into one repo later. |
Regarding option |
For full-system backups I've described a workaround here: https://forum.restic.net/t/full-system-restore/126/8 It's not pretty but will do the job until #1494 is done. |
This bug worried me a bit, but I can't reproduce it in 0.8.3 with the steps provided. Is this still an open issue? |
Yes, unfortunately this is still an issue. |
Hm, I somehow can't replicate the issue, so not sure what I'm doing different. I attached my test script. |
You can reproduce it like this:
For the two subdirs, restic uses the basename of the subdir as the top-level dir in the repo, so for either Listing the latest snapshot shows it:
In your test case, the basenames of |
From the release notes of version 0.9:
I just want to give you some statistics: first backup:
second one:
so a lot longer, means a lot longer :-) |
@fd0, awesome work! Thanks so much! Your backup tool has become my favorite for all my off-site backups (using b2) :-) |
Output of
restic version
restic 0.1.0
compiled at 2016-07-20 12:42:43 with go1.6.3
Expected behavior
After restore all directories should be restored.
Actual behavior
Only one directory is restored.
Steps to reproduce the behavior
/tmp/restic/FILESNEW01/Dir01/Test01.txt
/tmp/restic/FILESNEW01/Dir01/Test02.txt
/tmp/restic/FILESNEW01/Dir01/Test03.txt
/tmp/restic/FILESNEW02/Dir01/Test01.txt
/tmp/restic/FILESNEW02/Dir01/Test02.txt
/tmp/restic/FILESNEW02/Dir01/Test03.txt
content of files:
cat /tmp/restic/FILESNEW01/Dir01/Test0*
Content file. /tmp/restic/FILESNEW01/Dir01/Test01.txt
Content file. /tmp/restic/FILESNEW01/Dir01/Test02.txt
Content file. /tmp/restic/FILESNEW01/Dir01/Test03.txt
cat /tmp/restic/FILESNEW02/Dir01/Test0*
Content file. /tmp/restic/FILESNEW02/Dir01/Test01.txt
Content file. /tmp/restic/FILESNEW02/Dir01/Test01.txt
Content file. /tmp/restic/FILESNEW02/Dir01/Test03.txt
I want backup
Commands:
Initiate repository in /tmp/restic/BACKUP directory
Make backup
scan [/tmp/restic/FILESNEW01/Dir01 /tmp/restic/FILESNEW02/Dir01]
scanned 2 directories, 6 files in 0:00
[0:00] 16.67% 0B/s 51B / 306B 0 / 8 items 0 errors ETA 0:00 duration: 0:00, 0.01MiB/s
snapshot 4d197b90 saved
Checking if backup exists in repository
ID Date Host Directory
4d197b90 2016-07-26 14:14:43 nebss /tmp/restic/FILESNEW01/Dir01 /tmp/restic/FILESNEW02/Dir01
Restore backup
restoring <Snapshot 4d197b90 of [/tmp/restic/FILESNEW01/Dir01 /tmp/restic/FILESNEW02/Dir01] at 2016-07-26 14:14:43.208840145 +0300 EEST> to /tmp/restic/RESTORE/
Checking if directories/files exists
Dir01
Content file. /tmp/restic/FILES01/Dir01/Test01.txt
Content file. /tmp/restic/FILES01/Dir01/Test02.txt
Content file. /tmp/restic/FILES01/Dir01/Test03.txt
The text was updated successfully, but these errors were encountered: