No answers back, but I think I've stumbled on the solution and post it
here for the next poor soul who makes the same mistake. Noticed from
another recent post that clients can generate a sendsize.*.debug. Looked
for this on my client that failed to estimate, and found that the
automatically generated 'arguments' line specified the --exclude-from
option and that the estimate failed with message that this option's
argument was a directory. Sure enough, --exclude-from needs the name of a
file that specifies other files for exclusion; what I gave it (via
"exclude list" in my disklist entry) was the top directory of the subtree
to be omitted. I'm pretty sure that the fix is to use "exclude" instead of
"exclude list" (which I had hastily cribbed from one of the examples that
shipped in disklist). I'll make this change for tonight, and will post
again only if it fails and I need more ideas.
The "side question" I posed wrt successful recovery of gnutar'd stuff only
on the original host is still open. I suspect there are clues in the
arrangement of the gnutar-lists, but the answer is not clear to me yet.
Robert L. Becker, Jr.
Col, USAF, MC
Department of Cellular Pathology
Armed Forces Institute of Pathology
Washington, DC 20306-6000
301-319-0300
On Tue, 4 Jun 2002, Robert L. Becker Jr. wrote:
>
> I have a partition on one client that exceeds a tape (as I realized after
> first L0 attempt failed) and is too large for my holding disk. I have
> specified smaller parts (with appropriate 'exclude list') for gnutar to
> handle. Amcheck reports no problem for the client. The L0 attempt for all
> of the partition subparts ran last night. It appeared that one of the
> subparts taped ok. The other two (those with 'exclude' set) were flagged
> as "No Estimate" in the amstatus output during amdump's run, and failed.
> Here are the disklist entries:
>
> # optimas:/reed split up into manageable chunks (wrt holding disk, tape size)
> optimas3.cpt.afip.org /reed/becker/duplicates_pol_thickness/dense comp-user-tar
> optimas3.cpt.afip.org /reed/becker/duplicates_pol_thickness {
> comp-user-tar
> exclude list "dense"
> }
> optimas3.cpt.afip.org /reed {
> comp-user-tar
> exclude list "becker/duplicates_pol_thickness"
> }
>
[...snip...]
> [As a side question, the test recovery worked for putting the data back
> onto optimas3, but it failed when I tried putting the data on another
> host, i.e. the Amanda server, raleigh. Here is the amrecover session
> targeting raleigh:
>
> raleigh 116# /usr/local/amanda/sbin/amrecover Daily
> AMRECOVER Version 2.4.2p2. Contacting server on raleigh ...
> 220 raleigh AMANDA index server (2.4.2p2) ready.
> 200 Access OK
> Setting restore date to today (2002-06-04)
> 200 Working date set to 2002-06-04.
> 200 Config set to Daily.
> 501 No index records for host: raleigh. Invalid?
> Trying raleigh.cpt.afip.org ...
> 200 Dump host set to raleigh.cpt.afip.org.
> $CWD '/tmp/recover_reed' is on disk '/dev/root' mounted at '/'.
> 200 Disk set to /dev/root.
> Invalid directory - /tmp/recover_reed
> amrecover> sethost optimas3
> 501 No index records for host: optimas3. Invalid?
> Trying optimas3.cpt.afip.org ...
> 200 Dump host set to optimas3.cpt.afip.org.
> amrecover> setdisk /reed/becker/duplicates_pol_thickness/dense
> 200 Disk set to /reed/becker/duplicates_pol_thickness/dense.
> amrecover> add m109[5-6]*
> Added dir /m1095p1230 at date 2002-06-04
> Added dir /m1096p1230 at date 2002-06-04
> amrecover> list
> TAPE Daily002 LEVEL 0 DATE 2002-06-04
> /m1096p1230
> /m1095p1230
> amrecover> extract
>
> Extracting files using tape drive /dev/rmt/tps1d4nrsv on host raleigh.
> The following tapes are needed: Daily002
>
> Restoring files into directory /tmp/recover_reed
> Continue? [Y/n]: y
>
> Load tape Daily002 now
> Continue? [Y/n]: y
> :f
> tar: ./m1096p1230: Not found in archive
> tar: ./m1095p1230: Not found in archive
> tar: Error exit delayed from previous errors
> extract_list - child returned non-zero status: 2
> Continue? [Y/n]: amrecover> n
> Invalid command - parse error
> amrecover>
> amrecover> exit
>
> I suspect the problem is due to a mismatch between relative vs absolute
> paths used in the recovery. Whatever the problem, I don't know how to
> untangle it. Can someone point the way? Thanks.
>
