I finally have some more clarifying(?) details of my problem(s) that some of you
were asking for!
The amrecover error I am writing about in this email is slightly different from
the problem in my original post, but perhaps they are related? When I try and
add/extract a file in amrecover (which I can see with "ls" in amrecover), I
sometimes get:
------------
EOF, check amidxtaped.<timestamp>.debug file on localhost.
amrecover: short block 0 bytes
UNKNOWN file
amrecover: Can't read file header
extract_list - child returned non-zero status: 1
------------
I've checked the index files for that backup dump date, and the file I'm trying
to extract is listed in the index (which makes sense, I suppose, seeing as "ls"
gives me the file, and I assume "ls" in amrecover is based on these index
files). I've made sure I've loaded the right virtual tape as well.
In my emailed amanda reports, I get these messages from the host (pc1) I'm
trying to recover the files for:
===========
FAILURE AND STRANGE DUMP SUMMARY:
pc1 /home_USERS lev 0 FAILED ["data write: Connection reset by peer"]
pc1 /home_USERS lev 0 FAILED [dump to tape failed]
------ snip -----
NOTES:
taper: retrying pc1:/home_USERS.0 on new tape: [writing file: No space left on
device]
taper: tape groupBK-3 kb 83698080 fm 2 [OK]
------ snip ----
DUMP SUMMARY:
pc1 /home_USERS 0 6816972847067264 69.0 130:276013.1 130:286012.8
================
The thing is, I also have another machine listed in the "FAILURE..." as "dump to
tape failed" as well as a retrying attempt in the "NOTES" section, but I can
still recover the files off this machine!! So I'm not sure exactly how I
interpret these reports and where things may be going wrong. Is this related to
the 1.13.93 gnutar version I have?
Sorry for the persistent questions!
Thanks for the help!
g
----- Forwarded message from gj <joueg AT tcd DOT ie> -----
Date: Tue, 26 Apr 2005 21:23:59 +0100
From: gj <joueg AT tcd DOT ie>
Reply-To: gj <joueg AT tcd DOT ie>
Subject: Re: q: amrecover, directories okay but no files
To: amanda-users AT amanda DOT org
Sorry for the delay...I could not get access to the backup machine last week...
> > [...] sometimes although I get a "finished"
> > report on all DLEs using amcheck, the automatically mailed report would
> still
> > indicate errors of backing up some of the disk entries.
>
> Are you by any chance running into data timeout issues? Citing the
I think you are right -- a full dump of our machines takes over 20 hours!
> relevant lines for a failed DLE from one of your amanda report mails
> would be helpful. That would essentially mean that your GNU tar dump
> breaks off at a certain point, and would give rise more or less to the
> symptoms you describe.
Here is an excerpt (I hope I have included the helpful lines).
So from the following backup run, I had difficulties accessing *some* of the
files on the first two DLEs on mac1, and all of mac2 (which is more obvious
why)....
=========================
----- snip ----
planner: Adding new disk mac1:/home/DATA/macGoNoGo/.
planner: Adding new disk mac1:/home/DATA/VisualSearch/.
planner: Adding new disk mac1:/mnt/winData_fMRI.
-----snip---
driver: mac2 /home_USERS 0 [dump to tape failed, will try again]
driver: mac2 /home_BACKUP 0 [dump to tape failed, will try again]
-----snip---
DUMP SUMMARY:
DUMPER STATS TAPER STATS
HOSTNAME DISK L ORIG-KB OUT-KB COMP% MMM:SS KB/s MMM:SS KB/s
-------------------------- --------------------------------- ------------
mac1 -macGoNoGo/ 0 2523264017034706 67.5 31:478935.0 31:478934.1
mac1 -ualSearch/ 0 1908398011549525 60.5 22:088695.5 22:088695.3
mac1 -nData_fMRI 0 475000 121747 25.6 0:313938.0 0:313935.5
mac2 -ome_BACKUP 0 9549831293783744 98.2 203:137691.3 203:157690.6
mac2 /home_USERS 0 FAILED ---------------------------------------
------snip--
===============
> Actually, indexes are files on Amanda server, in a directory specified
> by 'indexdir' parameter in amanda.conf. Look into these index files to
> see if they list all the files that they should.
Ah, okay. Yes, it seems like sometimes the files that I can't recover are
listed, but they may be files that I can see during amrecover, but when I try
to extract them I get the message:
========
EOF, check amidxtaped.<timestamp>.debug file on localhost.
amrecover: short block 0 bytes
UNKNOWN file
amrecover: Can't read file header
extract_list - child returned non-zero status: 1
========
I'm sorry I am not certain about whether the files are listed in indexdir for
the case when I can't see files during amrecover that should be there (I don't
seem to be able to pinpoint the same problem I had earlier, and I've run a few
more backups since). I assume this usually corresponds to the case when the
files are also missing from the index files?
> The 'quite recent' version of tar may very well be a culprit. There was
> a discussion on this topic on the list recently and it was found that
> several versions of tar, such as 1.13.9x and 1.14.x are not very well
> compatible with Amanda. Versions 1.13.19 and 1.13.25 are the ones that
> are traditionally recommended on this list, also no problems have been
> found with version 1.15.1.
eek...I just checked...the version I have installed is GNU tar 1.13.93.
It seems to work half the time, though...so you suggest I downgrade?
Thanks so much for all you guys' help!!
----- End forwarded message -----
|
