Am 25.11.20 um 19:32 schrieb Charles Curley: > I vaguely recall that the problems I had with pigz were at compression > time. If so, and if your problem was also at compression time, you may > be SOL.
I assume no: my current recovery *test* (fortunately no emergency) tries to restore a level 1 backup: so it has to read 2 dumps in a row, both done with the same dumptype using pigz. The first part (the level 0) restores immediately and correct, but either it doesn't find an end in the archive or ... whatever It just never gets to the part where it requests the next tape (in my case both dumps are on the same tape: the lev0 was flushed on monday, the lev1 created in the same amdump run). > However, you started a thread on the list on January 27, 2014, that may > have some good ideas. One of them was: > >> Use the '-r' argument of amrestore and manually uncompress the file >> with pigz or gzip >> >> Jean-Louis > > You may have to use dd to pull the archive from the tape. > > Anyway, that thread may give you some ideas. Or bring back some > memories. Oh, sure ;-) All these years with Amanda! ;-) amrestore, sure ... amrecover *should* work, right? Side note: I use the changer name "robot" to restore from, that changer definition is used at dump time as well. I wonder if that works. But I tried the same recovery and used "/dev/nst0" directly. Same failure. So maybe pigz needs some additional option at decompression, or some fix, or amanda needs some patch to correctly handle the behavior or pigz in the process. I *know* I could use amrestore. But amrecover should work, and the very junior admin at the customer should be able to follow that howto I wrote for him ... And one more: As far as I remember I already did successful "amrecoverys" of DLEs compressed with pigz.
