Hi John,
thank you for your quick response. This night the backup was finished
successfully but it tells a lot of overwriting backups on previous tapes.
I've attached just the NOTES section from tonights mail:
NOTES:
planner: Last full dump of neuroserver:/home2 on tape
NEURO001 overwritten in 1 run.
planner: Last full dump of neuroserver:/home3 on tape
NEURO003 overwritten in 1 run.
planner: Last full dump of neuroserver:/var/spool/mail on
tape NEURO002 overwritten in 1 run.
planner: Last full dump of neuro021:/var/lib/pgsql on tape
NEURO002 overwritten in 1 run.
planner: Last full dump of neuro034:/home on tape NEURO002
overwritten in 1 run.
planner: Last full dump of neuro057:/home on tape NEURO002
overwritten in 1 run.
planner: Last full dump of neuro057:/usr on tape NEURO001
overwritten in 1 run.
planner: Last full dump of neuroserver://neuro068/HeineT on
tape NEURO002 overwritten in 1 run.
planner: Last full dump of neuroserver://neuro031/docu on
tape NEURO002 overwritten in 1 run.
planner: Last full dump of neuroserver://neuro040/dbase on
tape NEURO002 overwritten in 1 run.
planner: Last full dump of neuroserver://neuro040/liquid on
tape NEURO002 overwritten in 1 run.
planner: Last full dump of neuroserver://neuro040/texte on
tape NEURO002 overwritten in 1 run.
planner: Last full dump of neuroserver://neuro040/priv2000 on
tape NEURO002 overwritten in 1 run.
planner: Last full dump of neuroserver://neuro065/epilepsie
on tape NEURO002 overwritten in 1 run.
planner: Last full dump of neuroserver://neuro035/user$ on
tape NEURO001 overwritten in 1 run.
planner: Last full dump of neuroserver://neuro027/schneider$
on tape NEURO002 overwritten in 1 run.
planner: Last full dump of neuroserver://neuro055/genetic on
tape NEURO002 overwritten in 1 run.
taper: tape NEURO007 kb 11427200 fm 23 [OK]
And for recovering a file from tonights backup I can use amrecover:
This is what amrecover tells me after start up and changing to the disk in
question:
neuroserver# ~backup/sbin/amrecover
AMRECOVER Version 2.4.2p1. Contacting server on neuroserver ...
220 neuroserver AMANDA index server (2.4.2p1) ready.
200 Access OK
Setting restore date to today (2001-07-25)
200 Working date set to 2001-07-25.
200 Config set to NEURO.
200 Dump host set to neuroserver.
Can't determine disk and mount point from $CWD
amrecover> setdisk /opt/samba2.1
Scanning /opt/dumps...
200 Disk set to /opt/samba2.1.
BUT: setting the date to something earlier gives:
amrecover> setdate 2001-07-12
200 Working date set to 2001-07-12.
No index records for cwd on new date
Setting cwd to mount point
"John R. Jackson" wrote:
> >I'd like to recover a file from the backup using amrecover.
> >Unfortunately amrecover tells me, that there is no index available for
> >the given disk/date/host. BUT: As fas as I can see, there are all index
> >files in the index directory /usr/adm/amanda...
>
> OK, let's tackle this problem first.
>
> It would help to see the actual amrecover messages (all of them), as
> well as know what version of Amanda you're using.
This is included in the amrecover message above...
> First, let's make sure the index files are where they should be. Run:
>
> amgetconf <config> indexdir
$ amgetconf NEURO indexdir
/usr/adm/amanda/NEURO/index
> That points to the top level of the index directory. Within there should
> be a directory for each of your clients. The name will be the same as
> (or very close to -- '/' and whitespace are converted to '_' and '_'
> is converted to '__', but that's rare in a host name) the disklist entry.
>
> Within each client directory will be a directory for each disk. Those
> names will be similar (see above) to the disk name, e.g. "/dev/hda5"
> would be "_dev_hda5".
>
> Within a disk directory will be the gzip'ed index files. They have
> a datestamp and level in the name, and you must have all of them back
> through the full dump preceeding the date you're requesting.
The directory content of indexdir/neuroserver/_opt_samba2.1 is
20010614_0.gz 20010622_1.gz 20010630_2.gz 20010710_0.gz 20010718_0.gz
20010615_1.gz 20010623_1.gz 20010703_0.gz 20010711_1.gz 20010719_1.gz
20010616_1.gz 20010626_0.gz 20010704_1.gz 20010712_0.gz 20010720_2.gz
20010619_2.gz 20010627_1.gz 20010705_1.gz 20010713_1.gz 20010721_2.gz
20010620_0.gz 20010628_1.gz 20010706_2.gz 20010714_1.gz 20010725_0.gz
20010621_1.gz 20010629_2.gz 20010707_2.gz 20010717_1.gz
Backups on Monday and Tuesday failed -> index files from 2001-07-23 and
2001-07-24 are missing. If I understand you right, setting the date to
2001-07-19 should be successful, because the last full dump is from 07-18.
But this fails with the same error message as setting the date to 07-12
(amrecover message above).
> Also, if you're using GNU tar, make sure the files are formatted properly.
> If you look at the first few lines and they start with a large number, it
> means you're using a broken version of GNU tar. You'll need to upgrade
> to 1.13.19 (alpha.gnu.org), and those index files are pretty much junk
> (unless you want to strip the leading number off of each line).
I've already recovered files earlier successfully. That was a few months ago,
when we started with amanda. Thus I think it should not be a tar problem. And
tar wasn't exchanged since then. The content of 20010719_1.gz looks like the
following lines and I think they are ok?!?
/
/bin/
/lib/
/lib/Netlogon/
/lib/Netlogon/Win95/
/lib/Netlogon/WinNT/
/lib/Profiles/
/lib/Profiles/ahipke/
/lib/Profiles/ahipke/WinNT/
> Make sure all the directories and files are readable by the Amanda user
> (the one that runs amindexd from inetd/xinetd).
This is ok.
> Next, run "amadmin <config> find <client> <disk>" and make sure it finds
> backups from the date you're interested in back through a full dump.
>
> >The backups were flushed to the tape NEURO006 and I would have expected
> >that amanda requests tape NEURO007 next, but it tells me that it would
> >like a new tape. ...
>
> If Amanda asks for a new tape, it means the number of tapes in your
> tapelist file is less than your tapecycle value.
>
> >Am I right that I would have been informed if one tape
> >were not enough for amflush?!?
>
> One way or another. If you have a tape changer configured, amflush
> would have automatically advanced to another tape (up to runtapes),
> just like amdump.
>
> If you don't and amflush ran into end of tape, it would have reported
> an error and told you it left some images in the holding disk.
>
> If your holding disk is now empty, then the amflush probably worked.
Yes it is empty so this should be fine...
> Exactly what happened should have been documented in the amflush E-mail.
It just told me that everything was fine and that it expects a new tape what
sound strange for me :-(
> >Something else is strange: after amflush I tried amcheck still having
> >tape NEURO006 in the tape drive. And amcheck was happy. It was happy
> >with NEURO007 as well.
>
> That seems very wrong.
>
> Are you sure amflush did anything to NEURO006? If you run:
>
> amadmin <config> find <some-client>
>
> (where "some-client" is a client you know was flushed) does it show
> that tape? Were any errors reported in the amflush E-mail?
>
> >Could the problems accessing the tape drive during the last days have
> >left some corrupt info files?!?
>
> Not likely.
>
> >I would really be glad to get some advice where to look and what to do!
>
> Take a very close look at your tapelist file and at your tapecycle value.
This is the content of our tapelist file. I think it should have more than
one line?!?
20010725 NEURO007 reuse
And we have set tapecycle to 25 tapes.
> Also, "amadmin <config> tape" is a handy way to see what tape(s) Amanda
> expects to use next.
It tells me: The next Amanda run should go onto a new tape.
We are using amanda since March. Sometimes amcheck had problems accessing the
tape drive but it never had influence on the nightly backup. Until this week
:-(
I hope that I have answered all questions detailed enough...
Even if the index should be lost I should be able to restore old files using
amrestore?!?
Christina Rossmanith
