[Box Backup] Following Symbolic Links

[Martin Ebourne]

On Thu, 2006-06-15 at 11:51 -0600, Peter Porter wrote:
> Gentoo links several important config files under /etc to a place in the 
> portage tree, under /usr/portage/.  Certainly a bad assumption of me not 
> to check the entire directory structure to be sure, but in looking for a 
> solution the cleanest option (in my opinion) would be to have a follow 
> symlinks option.

How should such an option work?

/etc often contains a lot of state in symlinks. eg. the /etc/rc.d/rcN.d
directories are all symlinks and contain all of the runlevel
configuration in a sysvinit system.

On some systems the /etc/alternatives directory similarly contains a
bunch of symlinks which themselves are the configuration.

If you had a tar style option of backing up the file behind the symlink
instead of the symlink then a restore wouldn't be much use because you
wouldn't be back where you started and you would have lost information.

The only conceivable way such an option could work in a backup program
would be to back the symlink up correctly and then also magically back
up the destination file in its true location. Then the backup program is
implicitly adding new parts of the filesystem to back up. Maybe that's
all grand until someone executes 'ln -s / root' in their home directory
to get full filesystem access under samba, or any other number of
possibilities.

Sure tar has such an option, but tar is primarily an archiver not a
backup program, no matter what it's original use was. I bet the original
version didn't have a follow symlinks option, and you'd be daft to use
it if you were doing a backup.

> Specifically naming each symlinked directory will make for a messy 
> config and backup store.

If you had an option to do this automatically the backup store would be
just as messy, and the whole thing would be less controlled and less
transparent than doing it manually.

>   Furthermore, it's certainly forseeable that a 
> program may add a symlinked folder/item at a later date and, chances 
> are, I will be unaware.

That is true and I agree could be a problem. Maybe an optional warning
for symlinks pointing outside the backup tree would be the way to deal
with this.

> I can certainly see the general design benefit of backing files up as 
> they exist on the unix filesystem, but given this situation I see why 
> the option was added to tar, and I don't see a clean method to guarantee 
> that everything that logically falls under the /etc folder is backed up.

I don't think this really has anything to do with design benefits, but
simply a backup system should restore you to the state where you were
before you needed it. (If only insurance really did this!) If it backed
up the files behind the symlinks instead of the symlinks it would not be
doing this.

I can think of a third alternative which might be better. It would be
possible to back up both the symlink and the file behind it at its
symlink location. Thus you could restore the symlinks but also access
the data behind it. I suspect this would be complicated to implement
(including the tests), potentially confusing to operate (although I
think that is surmountable) but utterly useless if someone symlinked a
directory rather than a file. I've no idea if Ben would be prepared to
accept such a patch if someone who was experiencing this problem was
prepared to write it.

Cheers,

Martin.