Okay, this makes no sense whatsoever. This is only occuring on one
filesystem, and it is sporadic in occurances there. When ever I
attempt to do a amrecover of the directory on /var/mail I get the
following:
But I can dd the file from tape and extract it doing a straight
ufsrestore from that archived file, so it is on the volume. At first I
thought that index file was corrupted (since that is was amrecover
refers off of initially). And the files (or directories) are there in
my "dd'd" version. Amverify shows no issues whatsoever with the
filesystem in question:
Checked chg._var.20020313.0
And the sendbackup doesn't have any complaints either:
sendbackup: debug 1 pid 11165 ruid 9732 euid 9732 start time Wed Mar 13
22:10:45
2002
/var/adm/amanda/libexec/sendbackup: version 2.4.2p2
sendbackup: got input request: DUMP /var 0 1970:1:1:0:0:0 OPTIONS
|;bsd-auth;ind
ex;
parsed request as: program `DUMP'
disk `/var'
lev 0
since 1970:1:1:0:0:0
opt `|;bsd-auth;index;'
sendbackup: try_socksize: send buffer size is 65536
sendbackup: stream_server: waiting for connection: 0.0.0.0.48393
sendbackup: stream_server: waiting for connection: 0.0.0.0.48394
sendbackup: stream_server: waiting for connection: 0.0.0.0.48395
waiting for connect on 48393, then 48394, then 48395
sendbackup: stream_accept: connection from 152.3.165.105.47225
sendbackup: stream_accept: connection from 152.3.165.105.47226
sendbackup: stream_accept: connection from 152.3.165.105.47227
got all connections
sendbackup: started index creator: "/usr/sbin/ufsrestore -tvf - 2>&1 |
sed -e '
s/^leaf[ ]*[0-9]*[ ]*\.//
t
/^dir[ ]/ {
s/^dir[ ]*[0-9]*[ ]*\.//
s%$%/%
t
}
d
'"
sendbackup: spawning /usr/sbin/ufsdump in pipeline
sendbackup: argument list: dump 0usf 1048576 - /dev/rdsk/c0t0d0s3
sendbackup: index created successfully
sendbackup: pid 11165 finish time Wed Mar 13 23:04:32 2002
What is leading amrecover to believe that the file inquestion isn't on
the volume? I am out of ideas.
Don
