Hi Hugh, I get that; yet I only see gnutar in your config file (same as
what I use), not xfs, which is why I am wondering where it is being invoked.
I just now checked my own amdump.1 and sure enough, I've got the following:
------------------------------------------------------------------------
amdump: start at Thu Nov 6 02:49:02 EST 2025
amdump: datestamp 20251106
amdump: starttime 20251106024902
amdump: starttime-locale-independent 2025-11-06 02:49:02 EST
planner: pid 3221567 executable /usr/lib/amanda/planner version 3.5.1
planner: build: VERSION="Amanda-3.5.1" BUILT_DATE="" BUILT_MACH=""
planner: BUILT_REV="7557" BUILT_BRANCH="tags" CC="gcc"
planner: paths: bindir="/usr/sbin" sbindir="/usr/sbin"
planner: libexecdir="/usr/lib/amanda"
planner: amlibexecdir="/usr/lib/amanda" mandir="/usr/share/man"
planner: AMANDA_TMPDIR="/tmp/amanda"
planner: AMANDA_DBGDIR="/var/log/amanda" CONFIG_DIR="/etc/amanda"
planner: DEV_PREFIX="/dev/" DUMP="/sbin/dump"
planner: RESTORE="/sbin/restore" VDUMP=UNDEF VRESTORE=UNDEF
planner: XFSDUMP="/sbin/xfsdump" XFSRESTORE="/sbin/xfsrestore"
planner: VXDUMP=UNDEF VXRESTORE=UNDEF
------------------------------------------------------------------------
Which is very odd, xfsdump must be compiled-in, but for me inactive,
because I actually don't have either /sbin/xfsdump or /sbin/xfsrestore
on my system. I get no errors when I run amcheckdump. I assume that
you *do* have /sbin/xfsdump and /sbin/xfsrestore? Yet, you should be
using gnutar based on your config... unless it has been overridden, say,
in dumptypes.
On 2025-11-06 14:20, Hugh E Cruickshank wrote:
From: Winston Sorfleet Sent: November 5, 2025 17:16
Hugh, I don't see xfsdump invoked at all, it should be going to your
LTO based on what I see and assuming that /dev/changer isn't some weird
link to something other than the scsi symbolic for the robot. Do you
have something weird in your advanced.conf, dumptypes, or tapetypes?
Can you do a grep xfs in the directory?
Hi Winston:
The amcheckdump does not do a dump it only checks a previous amdump run.
We use it as sort of a verification step. Out backup scripts generally
look like:
:
/usr/sbin/amdump WeeklySet1
/usr/sbin/amcheckdump WeeklySet1
The amdump writes the tape and the amcheckdump reads & verifies the tape.
As per the man page:
Amcheckdump verifies Amanda dump images by reading them from storage
volume(s) and verifying that the images can be parsed by the
appropriate application (if available). For example, a GNUTAR image
is passed to GNU Tar for parsing, and any errors (e.g., corrupt or
missing data) are noted.
At this point I am only assuming the amdump is writing a valid tape but I
do not know for sure. I am going to try to extract the images on the tape
and confirm that they have been written as xfsdump or tar format, as
appropriate. If there are xfsdump images then I will know amdump worked
correctly and amcheckdump did not. If there are no xfsdump images then I
will know amdump did not work correctly.
Regards, Hugh
