Reading the doc I found this:
Symlinks are archived as symlinks,
restic does not follow them. When you restore, you get the same symlink again, with the same link target and the same timestamps.
Which is ok for most of the use cases (actually is desired y you’re making a server backup or somethink like that), but it would be nice to have an option to overide this in some cases.
My case: we use restic to “pack” the backups bcause in this way we can restore them in other location and run some tests against them, but we don’t have the destinatino of such symlink, also this save us a lot of time.
ATM we copy the link content to a folder and then backup the “pack”, but we are talking about 8 - 20G each time we do this and even when restic is very fast doing its job (takes about 2 minutes to complete the backup) the time it takes to copy the files is huge compared to this,
I know this is a very particular use case, but it would really help to have al option like: --override-and-follow-symlink (not an actual proposal)
What do you think about this?
There is a precedent for this in other archivers, like tar, which has
You might consider creating a feature request on the issue tracker.
Thanks, I created the issue here in case someone wants to follow it
You could use
mount --bind to construct a directory which has the data for a new snapshot just as you’d like to have it, without the need to copy everything. Are you aware of bind mounts? For example, let’s say you want to save a new snapshot with
/mail, you could do the following:
mount --bind /home/user/work /mnt/snapshot/foo
mount --bind /var/mail /mnt/snapshot/mail
restic backup .
I agree that this is a good workaround in cases where the user has root privileges. In other cases, providing a
--dereference switch would be in line with other Linux archive tools and would be useful for users who don’t have root access or don’t want to elevate to root to run their backups.
@fd0 We don’t run the tests neither the backup process itself as root user so when we backup the non root user won’t be able to generate such structure, but it is a clever workaround that can be used meanwhile to save a lot of time.
As @cdhowie mentions we try to give those users the minimun that they need to get the job done, +1 for the --dereference
I wonder if there is perhaps another potential option. I can see the case where a user wants the symlinks backed up, but also wants the files they point to in the backup regardless of whether they are a decedent of one of the listed paths.
Perhaps this calls for an
--include-symlink-targets option, where the target of all encountered symlinks are also included in the backup (at the same path as the link target)?