Open nmiculinic opened 8 years ago
Well, if one only has cases where following symlinks at backup time and restoring something different at restore time is fine, I guess there are no problems.
BUT: as soon as you have some symlinks that better stay symlinks at restore time and some other symlinks that you want followed (== restored as their target), you are in trouble.
Good observation. Perhaps something as follow-symblinks = {never, always, same-file-system, regex-matching} option would provide enough flexibility while keeping complexity down.
Two things come to mind
This looks to me like a very small niche and making it work requires little effort (unless there is something wrong with my suggestion, please tell :)
I moved the --read-special
symlink issue to #1215, it is a special case while this ticket is about the generic symlink following.
Any progress on this option?
@d2dyno no, and I have quite some doubts this is even a desirable feature.
The idea of a backup is that you get back the same state after restore and that means "not following symlinks, archiving symlinks as symlinks, restoring symlinks as symlinks" and that is what borg does right now. You just need to make sure you backup all filesystems / backup roots you need for recovery.
Also, as soon as you start following symlinks, there could be some interesting effects with endless recursion or that you might end up with wanting to follow some but not other symlinks.
Hi, I understand it may be causing some headaches but I have the following situation/setup where e.g. the ~/Documents folder is actually a link to another directory on another partition of the drive. This allows to have various OS (of the multiboot setup) to share the same documents etc. Inside the documents directory/partition here are other links to other directories/partitions because I was running out of space on the main documents directory/partition. I'm not sure but how does back-in-time/rsync manage symlinks ? Maybe the same approach could be followed. If the user has a switch he can choose what suits him best. Thanks
Personally I agree with Thomas- I have multiple symlinks that need to be restored exactly as they are if my server crashed, otherwise my entire file structure would be broken on restore. I think this would be the same for most people running Linux production servers.
Might be useful for some people as an additional feature but the current core functionality re: symlinks should definitely stay as it currently is
As a temporary solution you could try using rclone mount -L
and run borg on mounted folder. This is merely a suggestion, as, though it worked for me with restic, it produced weird errors on borg duo to locked files on my setup.
Borg backup currently saves symbolic links as they are, not following them. I propose adding an option to follow symbolic links as flag to borg create.
Usecase: I use anything-sync-daemon and profile-sync-daemon to store Desktop/chrome profile in tmpfs and speed up my chrome startup time and speed.
However they work by creating symbolic links in place of real folders, and I would like to backup my home dir without such issues.