So backups are moving along. They are large, so it takes time (one run is 2-3 days, for example -- That's 1 tape!).
It appears that after commenting out most of the DLEs and forcing a full on a set that can actually fit on a single tape, following backups are correctly incrementing. I'm still working my way through the DLEs (probably about 1/3 the way through what I was backing up before the glitch). It will literally take me 2+ months to correct / recover from, so I really cannot afford for this to happen again.... Perhaps it was a device number changing or something....Although the confusing thing that comes up as I think about it more...The client is a "FreeBSD Jail" running on a FreeNAS system. That means that the devices are hidden from the jail; the filesystem is "just there" (due to jail settings), so it doesn't see any /dev entries or similar. To the jail, everything is just a single filesystem with no device backing. So I don't know if it could be device minor changing, etc. I don't know what else it could be, though.... The hardware (mac address) of the amanda SERVER did change, but it kept the same IP address (after an initial snafu), as the hard drive was transplanted into a system with an identical motherboard/cpu. The first run attempt failed due to security checks, which I traced down to an IP change (DHCP), but for which was corrected before the first full run. I don't expect this to happen again. --Jim On Sun, Jun 16, 2019 at 3:40 PM Nathan Stratton Treadway <[email protected]> wrote: > On Sat, Jun 15, 2019 at 20:35:30 +0200, Uwe Menges wrote: > > On 6/15/19 6:43 PM, Jim Kusznir wrote: > > > Ever since, any backup is run as a level 0 (even though it reports > doing > > > a level 1, 2, etc). Everything runs as 0. > > > > > > How do I fix this? > > > > I fixed a similar symptom on my system with > > property "CHECK-DEVICE" "NO" > > (using amgtar), which hands "--no-check-device" to GNU tar, > > which makes it no longer think the toplevel dir has been renamed, > > so it doesn't store all files in its incremental. > > Yes, if the device for the filesystems in question are changing from > boot to boot, then using the --no-check-device option is necessary to > allow the incrementals to work as expected across reboots. But I > believe that option is not available for the GNUTAR application, so > assuming Jim is indeed using GNUTAR then it seems worth making sure > that's actually his problem before trying to implement that particular > solution.... > > > I think what happened to me is that some LVM volumes got mounted with a > > different minor number, triggering that. > > > > Given that LVM is really common nowadays, I wonder if that option should > > be default.. I can't think of a use case where the current default is > > preferable, at the moment. > > Yes. In particular, as long as --one-file-system is passed to GNU tar > (the default situation in Amanda) then every file backed up by that run > of tar is going to be on one single device, and the check-device > operation when building the list of incremental changes is never going > to be useful. (And obviously, in the case of changed device numbers for > the filesystem, the check is actually harmful). > > I don't know about changing the actual default in the amgtar application > itself at this point in time, but perhaps it at least makes sense to > recommend disabling check-device in the example amanda.conf and other > documentation.... > > Nathan > > > ---------------------------------------------------------------------------- > Nathan Stratton Treadway - [email protected] - Mid-Atlantic region > Ray Ontko & Co. - Software consulting services - > http://www.ontko.com/ > GPG Key: http://www.ontko.com/~nathanst/gpg_key.txt ID: 1023D/ECFB6239 > Key fingerprint = 6AD8 485E 20B9 5C71 231C 0C32 15F3 ADCD ECFB 6239 >
