On Mon, Apr 20, 2009 at 10:49:15AM -0600, Dan Brown wrote:
> Has anyone encountered this before?
>
> # amrecover Daily
> could not open conf file "/etc//amanda/amanda-client.conf": No such file
> or directory
> AMRECOVER Version 2.6.0p1. Contacting server on ministryofinformation ...
> 220 ministryofinformation AMANDA index server (2.5.2p1) ready.
> Setting restore date to today (2009-04-17)
> 200 Working date set to 2009-04-17.
Was a dump done on April 17, or was it still pending.
If not, then there would be no index for that working date.
Use setdate to an earlier time for which dumps are available.
> 200 Config set to Daily.
> 200 Dump host set to ministryofinformation.
> Use the setdisk command to choose dump disk to recover
> amrecover> sethost gimp
> 200 Dump host set to gimp.
> amrecover> setdisk /incoming
> 200 Disk set to /incoming.
> 599 System error index file not found
> amrecover>
>
>
> The index file is there however and is decompressed during this
> operation (until I type quit). It appears there is some problem with
> amrecover however. I'm not sure if it is a permissions issue or a
> corrupt file issue. The debug log for amindex shows the following:
>
>
> # cat amindexd.20090420100121.debug
> 1240243281.893128: amindexd: pid 25904 ruid 500 euid 500 version
> 2.6.1p1: start at Mon Apr 20 10:01:21 2009
> 1240243281.893166: amindexd: version 2.6.1p1
> 1240243281.893262: amindexd: < 220 ministryofinformation AMANDA index
> server (2.6.1p1) ready.
> 1240243281.893592: amindexd: > FEATURES ffffffff9ffeffffffff7f
> 1240243281.893612: amindexd: < 200 FEATURES ffffffff9ffeffffffff7f
> 1240243281.893690: amindexd: > DATE 2009-04-20
> 1240243281.893698: amindexd: < 200 Working date set to 2009-04-20.
> 1240243281.893757: amindexd: > SCNF Daily
> 1240243281.899257: amindexd: pid 25904 ruid 500 euid 500 version
> 2.6.1p1: rename at Mon Apr 20 10:01:21 2009
> 1240243282.729823: amindexd: < 200 Config set to Daily.
> 1240243282.729841: amindexd: > HOST ministryofinformation
> 1240243282.730843: amindexd: < 200 Dump host set to ministryofinformation.
> 1240243287.714857: amindexd: > HOST gimp
> 1240243287.714885: amindexd: < 200 Dump host set to gimp.
> 1240243308.240077: amindexd: > DISK /incoming
> 1240243308.240154: amindexd: append_to_tapelist(tapelist=(nil),
> label='/dumps/holding-servers/20090419232002/gimp._incoming.2', file=0,
> partnum=-1, isafile=1)
> 1240243308.240162: amindexd: - 2009-04-19-23-20-02 2
> /dumps/holding-servers/20090419232002/gimp._incoming.2 0 -1 -1
> ...
> 240243308.241245: amindexd: append_to_tapelist(tapelist=(nil),
> label='Daily-012', file=31, partnum=-1, isafile=0)
> 1240243308.241250: amindexd: - 2009-01-16-23-20-01 1 Zu-012 31 -1 -1
> 1240243308.241263: amindexd: < 200 Disk set to /incoming.
> 1240243308.241358: amindexd: > OISD /
> 1240243308.241462: amindexd: pipespawnv: stdoutfd is 0
> 1240243308.241496: amindexd: Spawning "/bin/gzip /bin/gzip -dc
> /etc/amanda/Daily/index/gimp/_incoming/20090419232002_2.gz" in pipeline
> 1240243308.242099: amindexd: pipespawnv: stdoutfd is 1
> 1240243308.242134: amindexd: Spawning "/bin/sort /bin/sort" in pipeline
> 1240243308.276843: amindexd: f
> /etc/amanda/Daily/index/gimp/_incoming/20090419232002_2
> 1240243308.276930: amindexd: < 200 "/" is a valid directory
> 1240243308.277082: amindexd: > OLSD /
> 1240243308.280853: amindexd: pipespawnv: stdoutfd is 0
> 1240243308.280893: amindexd: Spawning "/bin/gzip /bin/gzip -dc
> /etc/amanda/Zu/index/gimp/_incoming/20090417232001_1.gz" in pipeline
> 1240243308.281411: amindexd: pipespawnv: stdoutfd is 1
> 1240243308.281451: amindexd: Spawning "/bin/sort /bin/sort" in pipeline
> 1240243308.404305: amindexd: < 599 System error index file not found
> 1240243308.404497: amindexd: > DLE
>
>
> I had thought maybe the problem had to do with permissions as the index
> directory had been setgid on this backup set but not on a different
> backup set. The removal of setgid has no effect however.
>
> I should also note that the problem occurs across a number of hosts in
> the backup set, but not for all disks on each host. So I can go through
> all of the hosts and find only a couple which are having this problem,
> but again not through all dates. Both the backups and the indexes are
> there however so I can manually extract the files should I need to do a
> recovery from the periods of time affected.
>
> I'd like to figure out if this is something weird I did to cause this,
> or whether it's a corruption issue or what exactly to prevent this
> problem in the future.
>
>
>
> ---
> Dan Brown
> monkeypants AT shaw DOT ca
>
>>> End of included message <<<
--
Jon H. LaBadie jon AT jgcomp DOT com
JG Computing
12027 Creekbend Drive (703) 787-0884
Reston, VA 20194 (703) 787-0922 (fax)
|
