Hello guys,
I am planning to migrate my rsnapshot backups to restic (thanks btw for the very nice backup tool!). The documentation states that
Restic supports storage and preservation of hard links. However, since hard links exist in the scope of a filesystem by definition, restoring hard links from a fuse mount should be done by a program that preserves hard links. A program that does so is rsync, used with the option –hard-links.
As rsnapshot heavily works with hard links I would like to treat hard links like normal files. My workaround would be to cp the folder I am going to backup beforehand to get rid of the hard links. But copying 200-300 GB on an external hard drive 20 times would take some time…
Anybody any idea how to treat a hard link as non hard link?
PS: My current migration is to use rustic to migrate as it allows to specify the path (via --as-path). Also I hacked a --time into rustic. After migration I want to use restic on the same repo. rustic currently does not handle hard links when restoring but the information about hard links is saved to the repo (so when I use restic to restore the hard links are again considered)
I just realized that this probably doesn’t matter. Can somebody confirm this?
May the following folder structure be given:
- /home/user/folder1/file1
- /home/user/folder1/file2
- /home/user/folder2/file3
file1, file2 and file3 are pointing to the same inode. Then I create a backup of folder1. When I restore this backup to /home/user/restored the files in /home/user/restored/ share the same inode but do not share the same inode than any file under /home/user/folder*?
In other words: Upon restore no file in the restored folder points to a file outside the restored folder?
Note that restic restores only hard links within a snapshot. I don’t know if this applies to you rsnapshot scenario, it could be that hard links only occur between files which would land in different snapshots - those won’t be restored, of course.
When restoring, restic identifies hard links (IIRC) by looking for files which
- have links > 1
- have same inode and same device_id
You are right that rustic also saves that information. One possibility (as you already hacked rustic) is to add another option which sets links = 1 for all files. src/backend/ignore.rs would be the right place.
If you want to use restic after the migration, make sure to run restic check on the repository and make some restore tests using restic!
Out of curiosity: Is there something missing in rustic which prevents you from using it after the migration?
Also, as you already made some changes which seem to be missed currently, feel free to open a PR. Other users might be thankful to find these options if they have the same need in future!
Note that restic restores only hard links within a snapshot.
That’s good. Thanks for confirming.
If you want to use restic after the migration, make sure to run restic check on the repository and make some restore tests using restic!
Certainly will do this.
Out of curiosity: Is there something missing in rustic which prevents you from using it after the migration?
I tested restic some days ago and liked it. I found rustic by accident and found out that is has the --as-path flag which I needed for migration. Unless I find anything in restic that is bad or annoys me I’ll stick with restic because it is the “reference implementation”, larger user basis, etc. Or in short: I am happy with restic 
Also, as you already made some changes which seem to be missed currently, feel free to open a PR. Other users might be thankful to find these options if they have the same need in future!
I thought about this, but currently it is not in a shape to be merged back. I’ll have look if I find the time to do it properly.
Fair enough - hope you enjoy restic. And if you ever need one of the extra functionalities, you’ll know you can switch back and forth any time.
You can put a WIP PR and I’ll see how we can get it finished together!