Hi,
I have a couple of questions that I'd be grateful if someone could
help answer. As a brief background, we manage several Apple Xserves
running OS X Server 10.5, which provide services to a relatively small
group of users based mainly on open source platforms (e.g., Apache,
Subversion, Trac, TurboGears, etc.). We have used a backup strategy
developed around BRU in the past, but are now considering moving to
GNU tar (for several reasons). OS X 10.5 comes with version 1.15.1
pre-installed, patched by Apple to handle HFS extended attributes and
resource forks.
We have been running several tests using --listed-incremental to
create (and restore) full (level 0) and differential (level 1)
backups. Everything has worked nicely, exactly according to the
documentation. The one thing we noticed, however, is that files are
picked up in the incremental dumps even when only their atime has
changed -- despite the fact that neither their ctime nor mtime has
changed (i.e., the file has merely been accessed but not modified in
any way). This can make the differential archives pretty large,
especially in our case since we have several large database files
(e.g., ZODB files for Zope or SQLite database files) that are accessed
regularly but changed much less frequently. My question is: Is this
the expected behavior, and, if so, is there any way to generate an
incremental dump capable of restoring the filesystem *except* for the
atimes that would be smaller in size?
A second (and less important) question concerns the implementation of
the --exclude-from option when combined with --compare.
Unfortunately, we are unable to use --verify when creating an archive
because -- even with the patched version of GNU tar distributed with
OS X -- the --verify option doesn't appear to handle HFS resource
forks (i.e., GNU tar tries unsuccessfully to compare the ._* files
representing the resource forks in the archive with the filesystem).
For this reason, we have tried using --compare to verify an archive
after creating it. However, while this works fine with full (level 0)
dumps, using it with differential (level 1) dumps requires manually
excluding those files that haven't changed and are therefore not
included in the archive; otherwise, GNU tar reports that the contents
of the directories containing those files differ. Problem is, when we
pass in a long list of all the filenames excluded from the archive
(generating by parsing the output from gnutar --list) via the --
exclude-from option, the time required for the comparison blows up.
This suggests that GNU tar is iterating through all of the files
listed in the --exclude-from file over and over, rather than storing
them in a hash table and looking for matches that way. Is this
correct, and, if so, is there some other way to use --compare with a
level 1 (or higher) dump?
Any information or pointers to references on these issues would be
much appreciated (I have been unsuccessful Googling on them).
Thanks,
-- Phil
- [Bug-tar] question RE incremental backups Phil Schumm
-
