This question goes well with the post sent recently by M Boeckman,
about splitting
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"
}
Here is the relevant part of the logfile, with two FAIL lines:
START driver date 20020604
START planner date 20020604
INFO planner Adding new disk
optimas3.cpt.afip.org:/reed/becker/duplicates_pol_thickness/dense.
INFO planner Adding new disk
optimas3.cpt.afip.org:/reed/becker/duplicates_pol_thickness.
WARNING planner Last full dump of optimas3.cpt.afip.org:/reed on tape overwritten in
1 run.
INFO planner Adding new disk optimas3.cpt.afip.org:/smith.
INFO planner Adding new disk raleigh.cpt.afip.org://sylva/haltc.
INFO planner Adding new disk raleigh.cpt.afip.org://sylva/haltc_thickness.
START taper datestamp 20020604 label Daily002 tape 0
INFO planner Incremental of charlotte.cpt.afip.org:/coupal bumped to level 2.
INFO planner Incremental of charlotte.cpt.afip.org:/dev/root bumped to level 2.
FAIL planner optimas3.cpt.afip.org /reed 0 [disk /reed offline on
optimas3.cpt.afip.org?]
FAIL planner optimas3.cpt.afip.org /reed/becker/duplicates_pol_thickness 0 [disk
/reed/becker/duplicates_pol_thickness offline on optimas3.cpt.afip.org?]
FINISH planner date 20020604
[...lots of successful dumper/taper output, including various partitions on optimas3
as below...]
SUCCESS dumper optimas3.cpt.afip.org /dev/hda2 [snip]
SUCCESS dumper optimas3.cpt.afip.org /ash [snip]
SUCCESS taper optimas3.cpt.afip.org /dev/hda2 [snip]
SUCCESS taper optimas3.cpt.afip.org /ash [snip]
[...more success output...]
SUCCESS dumper optimas3.cpt.afip.org /reed/becker/duplicates_pol_thickness/dense [snip]
SUCCESS dumper optimas3.cpt.afip.org /smith [snip]
SUCCESS taper optimas3.cpt.afip.org /reed/becker/duplicates_pol_thickness/dense
SUCCESS taper optimas3.cpt.afip.org /smith
So the question is, (why) are the excludes in my disklist entries causing
planner to fail in estimating? Only the two entries with exclude fields
bounced. An amrecover test recovery from the subpart that did not have an
exlude list worked ok.
[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.
Robert L. Becker, Jr.
Col, USAF, MC
Department of Cellular Pathology
Armed Forces Institute of Pathology
Washington, DC 20306-6000
301-319-0300
