On Tue, Jul 02, 2019 at 18:22:20 -0700, Jim Kusznir wrote:
> 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
Okay, that lends support to the theory that the problem is something
related to rebooting (as opposed to something more dynamic/real-time).
> 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....
As I mentioned before I am not familiar with FreeNAS and FreeBSD Jails,
but all Unix filesystem have a device number assigned to them as part of
the basic "API" of being a filesystem, and by default GNU tar checks
that number as part of the scanning-for-changes it does when preforming
an incremental backup. So, even though the "physical" device is hidden
by the "jail" infrastructure, there must be some device number assigned
to the filesystem as it is seen from within the jail.
In my June 18 email I asked if the "stat" command was available with the
jail... and I still think that's the easiest way to find out what's
going on, if it is available.
If not, I'm curious if the jail really does not have any /dev directory
at all? Or is it rather that there are virtualized entries found there?
(For example, what does "df /path/to/a/directory/" show when run from
within the jail... and assuming a device-like name showes up in the
output, what does "ls -l /dev/<DEVNAME-FROM-df-OUTPUT>" say?)
>
> 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.
Unless that first failed attempt actually managed to do a partial run
and corrupt the GNU tar snapshot files on the client (which seems
unlikely), I don't think these networking problems on the server side
are related to the incremental problems on the client side.
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
