Hi Marco, Can you try extracting the archive using the below command and then try PKZIP tool to extract the created .zip file.
dd if=00001.alu01.alumetal.local.D__Contract.0 of=recovery.zip bs=32k skip=1 ~Prashant On Sat, Apr 14, 2012 at 12:06 PM, Marco Carcano <[email protected]> wrote: > 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 >>>> >>> >>> >> >> >
