Dear Debra
thank for your reply
I'm trying to do what you suggested - I'll tell you how it will end
(it will take a while since the file size is 35 GB and we are coping
at 32K blocks)
however before doing what you suggested I also tried the following
command
dd if=backup of=recovery.txt bs=32k count=1
just to extract the first page to see if it contains recovery
instructions, ... I only got binary garbage - so I think that
amfetchdump will automatically remove the first page from any part of
the backup (I defined part-size of 1500 mbyte in order to have 10% of
the virtual tape size)
by the way, if I issue the same command on a part I can get the
recovery instructions:
dd if=00001.alu01.alumetal.local.D__Contract.0 of=recovery.txt bs=32k
count=1
cat recovery.txt
AMANDA: SPLIT_FILE 20120407112059 alu01.alumetal.local "D:/Contract"
part 31/-1 lev 0 comp .gz program pkzip
ORIGSIZE=74650885
DLE=<<ENDDLE
<dle>
<program>DUMP</program>
<disk>D:/Contract</disk>
<level>0</level>
<auth>bsdtcp</auth>
<compress>SERVER-FAST</compress>
<record>YES</record>
<index>YES</index>
</dle>
ENDDLE
To restore, position tape at start of file and run:
dd if=<tape> bs=32k skip=1 | /usr/bin/gzip -dc | Extract with zmanda
windows client or unzip program
I'd also like to point out that I specified to use server side
compression (not client side)
define dumptype comp-user-zwc-span {
user-zwc-span
compress server fast
}
I previously tried with client side compression, but got the same error
thanks
Marco Carcano
Il giorno 13/apr/12, alle ore 21:48, Debra S Baddorf ha scritto:
For starters, the file that Windows 7zip doesn't like --- it
probably contains a first page which is the instructions for
doing the restore. Try just typing out the file (NOT to paper).
If you can read the first part, then
you need to take that part OFF before handing the result to your
unzipper.
On unix, that would be
dd if=wholeFile of=LessFirstStuff bs=32k skip=1
That might make that zip file more usable, if you take the
instructions part of it.
Deb Baddorf
On Apr 13, 2012, at 2:20 PM, Marco Carcano wrote:
Hello
nobody want to help this poor man ;O) ?
Data: 11 aprile 2012 13:12:23 GMT+02:00
A: [email protected]
Oggetto: Really strange issues in recovering (maybe due to tape
spanning??)
Dear list
I hope I can find here someone who can explain what are the errors
I got
I never had issues with amanda (I installed several systems, and
always got data succesfully saved and restored). However I never
had to use tape spanning (maybe it is tape spanning causing the
issues I'm about to tell you)
I love amanda, but recently I faced a series of issues that make
me doubt
before posting any config I'd like to explain what I found:
a) recently I had to recover one directory and several files:
amanda server was on a 32 bit CentOS 5.5 system, the files were on
a 64bit CentOS 5.5 system
I've not been able to restore them - I can get them listed in
amrecover, but when I tried to extract I got varius messages like
Archive octal value is out of range;
Archive contains obsolescent base-64 headers
and at the end (some where translated in Italian - I tried to
translate back to english)
Error writing to fd 8: Broken pipe
/usr/bin/gzip exited with status 1
tar: Read 6144 bytes from -
tar: unexpected EOF in archive
tar: Unrecoverable error: quitting
Extractor child exited with status 2
fortunately enough I can got them from another backup (done by a
simple tar) that I did a few days before
the error was not of that run only: I do backups with 2 dailysets
that runs on different days and saves data onto 2 separate USB
Hard Disk, and I've not been able to restore from any of the runs
anyone that have an idea of what was going wrong? It may be tape
spanning related? As for the "Archive contains obsolescent base-64
headers" I think it could be related to the different
architectures (32 and 64 bit), but I tried also recovering from
the 64 bit system itself unsuccesfully
b) I had to backup a Windows 2003 SBS server by zmanda client for
Windows community edition - Amanda reported that everything went
well,
but I tried (just for testing) to extract the backup and here is
what I got:
amfetchdump DailySet1 alu01.alumetal.local D:/Contract
20120407112059
4 volume(s) needed for restoration
The following volumes are needed: DailySet1-08 DailySet1-09
DailySet1-010 DailySet1-011
Press enter when ready
amfetchdump: 1: restoring split dumpfile: date 20120407112059 host
alu01.alumetal.local disk "D:/Contract" part 1/UNKNOWN lev 0
comp .gz program pkzip
amfetchdump: 2: restoring split dumpfile: date 20120407112059 host
alu01.alumetal.local disk "D:/Contract" part 2/UNKNOWN lev 0
comp .gz program pkzip
... varius line like the above ones
amfetchdump: 4: restoring split dumpfile: date 20120407112059 host
alu01.alumetal.local disk "D:/Contract" part 34/UNKNOWN lev 0
comp .gz program pkzip
amfetchdump: 5: restoring split dumpfile: date 20120407112059 host
alu01.alumetal.local disk "D:/Contract" part 35/UNKNOWN lev 0
comp .gz program pkzip
ERROR: /usr/bin/gzip exited with status 1
I copied the dumped file (35GB) to a Windows system and tried to
open it with 7zip, but it complained that it was not a zipped file
I really do not know where I'm wrong (and the thing that scares me
most of all is that amanda reports said that backups were right)
is anyone that could help me please?
Marco Carcano
