After doing so, if you still have issues, can you post the first teen bytes or so go the regular file please, and the output of "file recovery.zip" On Apr 14, 2012 4:02 AM, "Prashant Joshi" <[email protected]> wrote:
> 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 >>>>> >>>> >>>> >>> >>> >> >
