Andrew Rakowski
February 21st, 2007, 03:16 PM
We wanted to make sure we could recover a file from a backup, so I started a quick amrecover session to get back one small file as a test. Once the file was recovered (but before the entire backup tarball was processed) we hit Ctrl-C to abort the amrecover.
The system admin then went to the system in question, tried to do an amrecover, and got a cryptic error message (something about "can't read header" or whatever - the sysadmin of the system in question relayed the info generically). I found that the file /etc/amanda/XXXXset1/log/log was there, and had:
INFO amidxtaped amidxtaped
in it. Moving this file elsewhere (basically, removing it) allowed the amrecover to work correctly. When the real amrecover of about 90GB of data was complete, the file disappeared on its own.
So, the simple thought was to trap INT, QUIT and other signals and clean-up this log file (and/or stop the recovery in process.) An alternative strategy would be to add information on which host/client was doing the recover, and printing a less cryptic message like:
"Only one system may do an amrecover at a time. Please check with the
administrator on system yyyy to see if they are done. If you are sure that
no administrators are recovering data, please remove the file .../log/log on
the Amanda tape server to allow your amrecover to continue."
This was done while running Amanda-2.5.1p3-1 on a Linux Redhat AW4 system as the server, with Amanda-2.5.1p2 running on an SGI IRIX64-6.5.30 system as the amrecover client.
Cheers,
-Andrew
The system admin then went to the system in question, tried to do an amrecover, and got a cryptic error message (something about "can't read header" or whatever - the sysadmin of the system in question relayed the info generically). I found that the file /etc/amanda/XXXXset1/log/log was there, and had:
INFO amidxtaped amidxtaped
in it. Moving this file elsewhere (basically, removing it) allowed the amrecover to work correctly. When the real amrecover of about 90GB of data was complete, the file disappeared on its own.
So, the simple thought was to trap INT, QUIT and other signals and clean-up this log file (and/or stop the recovery in process.) An alternative strategy would be to add information on which host/client was doing the recover, and printing a less cryptic message like:
"Only one system may do an amrecover at a time. Please check with the
administrator on system yyyy to see if they are done. If you are sure that
no administrators are recovering data, please remove the file .../log/log on
the Amanda tape server to allow your amrecover to continue."
This was done while running Amanda-2.5.1p3-1 on a Linux Redhat AW4 system as the server, with Amanda-2.5.1p2 running on an SGI IRIX64-6.5.30 system as the amrecover client.
Cheers,
-Andrew