Re: amcheckdump xfsrestore errors
Winston Sorfleet <[email protected]> Thu, 6 Nov 2025 19:07:51 -0500
| Newsgroups | gmane.comp.archivers.amanda.user |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format.
--------------0Ol0tot8a04EDIl9Mv4wEqUU
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
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
>
--------------0Ol0tot8a04EDIl9Mv4wEqUU
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit
<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>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.</p>
<p>I just now checked my own amdump.1 and sure enough, I've got the
following:</p>
<hr width="100%" size="2">amdump: start at Thu Nov 6 02:49:02 EST
2025<br>
amdump: datestamp 20251106<br>
amdump: starttime 20251106024902<br>
amdump: starttime-locale-independent 2025-11-06 02:49:02 EST<br>
planner: pid 3221567 executable /usr/lib/amanda/planner version
3.5.1<br>
planner: build: VERSION="Amanda-3.5.1" BUILT_DATE="" BUILT_MACH=""<br>
planner: BUILT_REV="7557" BUILT_BRANCH="tags" CC="gcc"<br>
planner: paths: bindir="/usr/sbin" sbindir="/usr/sbin"<br>
planner: libexecdir="/usr/lib/amanda"<br>
planner: amlibexecdir="/usr/lib/amanda"
mandir="/usr/share/man"<br>
planner: AMANDA_TMPDIR="/tmp/amanda"<br>
planner: AMANDA_DBGDIR="/var/log/amanda"
CONFIG_DIR="/etc/amanda"<br>
planner: DEV_PREFIX="/dev/" DUMP="/sbin/dump"<br>
planner: RESTORE="/sbin/restore" VDUMP=UNDEF VRESTORE=UNDEF<br>
planner: XFSDUMP="/sbin/xfsdump"
XFSRESTORE="/sbin/xfsrestore"<br>
planner: VXDUMP=UNDEF VXRESTORE=UNDEF<br>
<br>
<hr width="100%" size="2">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.
<p><br>
</p>
<div class="moz-cite-prefix">On 2025-11-06 14:20, Hugh E Cruickshank
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:018d01dc4f52$714e1f10$53ea5d30$@com">
<pre wrap="" class="moz-quote-pre">From: Winston Sorfleet Sent: November 5, 2025 17:16
</pre>
<blockquote type="cite">
<pre wrap="" class="moz-quote-pre">
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?
</pre>
</blockquote>
<pre wrap="" class="moz-quote-pre">
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
</pre>
</blockquote>
</body>
</html>
--------------0Ol0tot8a04EDIl9Mv4wEqUU--