I have been experimenting with restoring files to /tmp that I have saved from my Ubuntu server just to understand how to do it. I am using BackBlaze B2 as the storage backend.
In particular, I noticed that I can restore a file from /etc/apache2/sites-available with no issue. But I cannot restore any of the linked files in /etc/apache2/sites-enabled. I get the warning
[Warning-Duplicati.Library.Main.Operation.RestoreHandler-NoFilesRestored]: Restore completed without errors but no files were restored
Are there any settings that would restore the linked files? Or, is that a bad idea?
When you make the backup, you can control how the links are stored with --symlink-policy and --hardlink-policy.
The default for --symlink-policy is Store and for --hardlink-strategy it is All.
I assume these are symlinks are that is most common.
With the Store setting, the symlinks are stored as they appear on the filesystem, and thus restored as that, meaning if you backup a symlink a -> /etc then that linking information is stored, and the restore will re-create the symlink.
If you want to store the content being linked to (i.e. ignoring the fact that it is a symlink) then you can use --symlink-policy=follow, which will treat symlinks as normal files.
Is the problem that you are seeing that the symlinks are not restored?
I have seen that this warning is sometimes a bit misleading, because it will not restore anything if the files are already present. I have not investigated, but it is plausible that the warning could also appear if only symlinks/directories are restored.
Yes, the links are symlinks. Files in sites-available are symlinked to sites-enabled when that virtual site is enabled in apache2.
When I did the practice restore, I wasn’t thinking about symlinks or real files. I just tried to restore a “file” from sites-enabled, thinking it would restore the file that the symlink referred to. Upon further reflection, I see how that my not work.
I just ran another test where I restored both the sites-available and sites-enabled directories, and the symlinks were all restored to sites-enabled folder, which make sense now.