BackupEdge + symlinks
Roger Cornelius
handles symbolic links to directories.
When you tell edge to follow symbolic links during a backup, i.e., use
the edge "h" option, or enable "Follow Symlinks" in the backup domain
in edgemenu, and a symbolic link points to a directory, the directory
entry will be backed up, but the files and directories it contains
will not.
This is not documented anywhere that I can find. Indeed, the
description of the "Follow Symlinks" setting in the "Creating Backup
Domains" section of the edge User Guide states: "In other words, if
this option is checked, the Domain treats Symbolic Links as if they
were not links.". If that's the case, then the contents of the
directory SHOULD be backed up, because that is what would happen if
the symlink were not a symlink, but a real directory.
Imagine the following directory hierarchy:
/u/somedir/photos/
/u/somedir/more-photos -> /u2/somedir/more-photos/
/u/somedir/videos/
/u/somedir/other-stuff/
/u2/somedir/more-photos/
You backup /u/somedir using edge with the "follow symlinks" option:
cd /;edge cvhf /tmp/arc.edge ./u/somedir
You might be surprised that the contents of /u2/somedir/more-photos
did not get backed up. This is a contrived example, but a legitimate
one.
I don't know whether to consider this a bug or feature, but it's
undesirable behaviour IMO. At the very least it should be clearly
spelled out in the documentation and help screens.
Noteworthy is, given the appropriate option to follow symlinks, SCO
tar, GNU tar, and pax all back up the directory which is the target of
the symlink, AND the files/directories that directory contains. To
me, this is what "follow symlinks" should do.
Pat Welch
Hi, Roger.
First, what version of Edge, running under exactly which OS/version?
If I interpret this correctly:
/u/somedir/more-photos -> /u2/somedir/more-photos/
as:
/u/somedir/more-photos is symlinked *TO* /u2/somedir/more-photos/.
IOW, /u2/somedir/more-photos/ is the *real* dir.
And you are backing up the /u/somedir/ directory.
Did you expect to get *2* full copies of the contents under
/u/somedir/more-photos as well as /u2/somedir/more-photos/ just because
they are symlinked?
I note in that case you did not tell Edge to also backup the /u2 dir in
your sample command.
Some questions if there were really no files under the
/u/somedir/more-photos/ dir in the backup:
1) What were the exact permissions of both the symlinked and source dir?
Use ls -la on them.
Also, any strangeness? Like they both report they are symlinks of *each
other* - that would not be a good thing. :)
2) Did you run the backup using root permissions or as a regular user?
3) Any chance there's a *real* dir named /u/somedir/more-photos?
Depending on the OS, a symlink may not *replace* an existing dir, but
overlay it in such a way as to cause confusion when a program like Edge
is walking the dirs and symlinks.
To test this, rm the symlinked dir (make darn sure it's really the
symlinked one of course!), then try to cd to it.
If you can cd to it, then you had a hidden *real* dir and that was the
problem. rmdir the stray dir and redo the symlink.
4) Have you run, as root, fsck -ofull (if this is SCO OS 5) on the block
device /u/somedir/more-photos is in?
If /u is part of the root filesystem and not separate, then you can
still do this in multi-user mode remotely - just be darn sure you don't
say Y to any repair suggestions that come up. You can ignore any free
list issues that come up when running fsck in multi-user mode.
--
----------------------------------------------------
Pat Welch, UBB Computer Services, a WCS Affiliate
SCO Authorized Partner
Microlite BackupEdge Certified Reseller
Unix/Linux/Windows/Hardware Sales/Support
(209) 745-1401 Cell: (209) 251-9120
E-mail: pat...@inreach.com
----------------------------------------------------
Roger Cornelius
Sorry for leaving that out.
SCO OSR507 w/MP5 & OSR6 w/MP4, edge 02.03.01
Redhat Enterprise Linux kernel 2.4.21, edge 02.03.00
> If I interpret this correctly:
>
> /u/somedir/more-photos -> /u2/somedir/more-photos/
>
> as:
>
> /u/somedir/more-photos is symlinked *TO* /u2/somedir/more-photos/.
>
> IOW, /u2/somedir/more-photos/ is the *real* dir.
>
> And you are backing up the /u/somedir/ directory.
Yes, that is correct.
> Did you expect to get *2* full copies of the contents under
> /u/somedir/more-photos as well as /u2/somedir/more-photos/ just because
> they are symlinked?
>
> I note in that case you did not tell Edge to also backup the /u2 dir in
> your sample command.
Using the command I cited, I expected 1 copy - I got 0.
> Some questions if there were really no files under the
> /u/somedir/more-photos/ dir in the backup:
>
> 1) What were the exact permissions of both the symlinked and source dir?
> Use ls -la on them.
>
> Also, any strangeness? Like they both report they are symlinks of *each
> other* - that would not be a good thing. :)
>
> 2) Did you run the backup using root permissions or as a regular user?
>
> 3) Any chance there's a *real* dir named /u/somedir/more-photos?
>
> Depending on the OS, a symlink may not *replace* an existing dir, but
> overlay it in such a way as to cause confusion when a program like Edge
> is walking the dirs and symlinks.
>
> To test this, rm the symlinked dir (make darn sure it's really the
> symlinked one of course!), then try to cd to it.
>
> If you can cd to it, then you had a hidden *real* dir and that was the
> problem. rmdir the stray dir and redo the symlink.
>
> 4) Have you run, as root, fsck -ofull (if this is SCO OS 5) on the block
> device /u/somedir/more-photos is in?
>
> If /u is part of the root filesystem and not separate, then you can
> still do this in multi-user mode remotely - just be darn sure you don't
> say Y to any repair suggestions that come up. You can ignore any free
> list issues that come up when running fsck in multi-user mode.
Testing was done as root on the 3 systems described. There were no
filesystem anomalies that would contribute to the outcome. I believe
that sadly, this is just the way edge works. Did you try the example
I provided? I will be surprised if you don't see the same results I
described.
Pat Welch
Huh.
I got the same results on testing.
Per the Technical Manual:
"h Archive the contents of the symbolically linked named files.
edge cv
will archive symbolic linkage information only, while
edge chv
will archive the contents."
The phrase "symbolically linked named *files*" may be why dirs are not
followed - the manual seems to imply only symlinked *files* are followed
and copied, not dirs.
If so, the wording needs to be expanded on to make that clear.
I'll kick this over to Microlite's tech support and see what they say.
Nico Kadel-Garcia
This is RHEL 3. Ye ghods, take that dog out back and shoot it.
More seriously, that OS is so old it should seriously be replaced,
ASAP, unless it's linked to something that demands its ancient kernel,
such as VMWare ESX. But otherwise, you might strongly consider testing
this issue against a more modern RHEL release, such as RHEL 4 or
ideally RHEL 5.