Paul Bijnens wrote at 19:41 +0200 on Sep 27, 2007:
> On 2007-09-27 18:07, John E Hein wrote:
> > I can't think of any way to see if they changed - I don't have a
> > record of what they were before. Is there a way to look in the
> > gnutar-list files and see? I suppose I will extract the tar files
> > off tape and extract devno from the archive (howto hints for getting
> > the devno from tar archives welcome).
>
> It's even simpler.
> Go to the client, and locate the gnutar-lists directory there.
Indeed. I was looking for the format documented in the .info
pages for gnutar, but couldn't find it.
> That is the place where Amanda store the incremental-stamps of
> gnutar.
> Each file begins a number (epoch time stamp in seconds of start of that
> run) followed by lines like:
> 64768 292933 ./usr/kerberos/man
> That first number is the device number (major * 256 + minor).
> The second number is the inode number of the file.
> The problem that you noticed is that an incremental level is the
> same as the level 0 backup. So compare the device entries
> of the level 0 and the incremental level that was too large.
> If the device numbers are the same, then you hit another problem.
> I'm curious.
>
> Version of Tar is also important as different versions use different
> formats. The format above is "format 0", and is used by gnutar versions
> up to 1.15.1. There is also a "format 1", and a "format 2", see:
>
> http://www.gnu.org/software/tar/manual/html_node/Snapshot-Files.html#Snapshot-Files
Excellent... saved me a source dive.
The devno (minor number in this case) did change, by the way, from 134
to 86.
Thanks all for the explanations.
> > Next time I do something like this, I'll check before/after listings
> > of /dev.
> >
> > Now... let's say the devno did change, and I noticed and know what it
> > is before and after. What's the best way to avoid the inevitable
> > incremental dump of everything? I don't see a way to tell gnutar to
> > ignore the devno. Is there one? If so, is there a better way?
>
> Not known to me. But very interested.
> Try to keep the device numbers the same. :-)
> Or hand-edit those gnutar incremental state file with a small perl
> program to update the devicenumbers.
Now that I know the format, my plan would be to copy off the old
incremental snapshot file, use sed to substitute the new devno in the
latest incremental file(s) for the DLEs associated with the device.
Of course, I'll have to remember to save off a listing of /dev
Supporting a per-DLE mode to [temporarily] ignore a change in devno in
amanda should be easy.
And maybe adding a "devno changed" check in amcheck would be nice -
the client has the gnutar-list files, so it would require some work in
the client side of amcheck.
For us, this was a large raid, so suffering through a couple days of
huge incremental dumps was painful (particularly while getting 'dumps
way too big' for some DLEs) and threw the balance out of whack.
|
