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 >
