Helmut Waitzmann wrote:
"Henry Andrew" <address@hidden> writes:
I use /var/log/snar to record the files that were backed up so that
future incrementals can refer to this file and only bakup the newest
files. This has been working perfectly for some tmie, but recently
after a botched upgrade to the latest version of Ubuntu, I was forced to
re-install my current version.
So you use that version of tar, which you used to use before the botched
upgrade, right?
Actually I was wrong; the version of GNU Tar in Ubuntu 6.06 is 1.15.1
and I used this version before the botched upgrade to Ubuntu 6.1 and
afterwards when I re-installed Ubuntu 6.06 I still have version 1.15.1.
As I have /home on a separate partition, this didn't involve restoring
the archive,
You didn't touch any file in the file hierarchy "/home", right?
Not during the reinstallation, no, but a whole bunch of files have
changed since I reinstalled. I used my system for 1 week before
attempting a new weekly incremental backup.
however, I did not backup /var/log/snar, but I have a copy of it on the
DVD that I burnt the yearly archive to.
Now, even though I have copied snar back to /var/log, using cp -p to
make sure that it retains it's original timestamp,
You restored latest version of the file "/var/log/snar", which was there
before the botched upgrade, right?
Then I think, your system behaves strange, in deed:
Yes, when I performed the first master backup (yearly), I burnt the
snar file to the DVD along with the tar archive. It is this file that
I restored to it's previous location at /var/log with original
timestamp.
my weekly backups are backing up every file on /home, as if it is unable
to recognise the snar file.
If you know for certain, that your "/home" filesystem has not changed
during and since the botched upgrade, make a backup to "/dev/null", just
to create a new "/var/log/snar" GNU tar snapshot file.
If there might be changes in your "/home" file hierarchy, but you can
identify all of them, make a backup to "/dev/null" as above, and then
touch each of the changed inodes, to trigger a new backup.
To identify the changes, you could restore "/home" from the backup into
a different place, for example "/restored_home". Maybe you have to use
GNU tar's option "--strip-components" to achieve that.
With "cmp" together with "find" you could traverse both hierarchies
finding files wich differ in their contents and files which are only in
one of both hierarchies.
There is no easy way to find inodes which differences consist of only the
filenames that are hardlinked to them, though.
This is probably too much work for me. From my point of view it is
easier to make a new yearly backup and go from there.
|