3

We store database backups encrypted with PGP Command Line 9.7.0. Files look like 2009.bak.pgp

Here's command line used to backup these files:

pgp --encrypt F:\2009.bak --recipient [email protected] --encrypt-to-self --input-cleanup off --temp-dir F:\TEMP\ -v    

All of these backups were restored just fine with this command

pgp --decrypt F:\2009.bak.pgp --passphrase "18_characters_password" --temp-dir F:\Temp -v --output F:\2009.bak

All of them, except one, which fails with this error:

Decoding file F:\2009.bak.pgp... 32% (2.1GB)   F:\2009.bak.pgp:decrypt (3090:operation failed, error decompressing data)
Wiping file F:\Temp\pgp-5532-0.tmp... 1%

I also tried to decrypt this file on Linux machine with this command:

gpg -v <2009.bak.pgp> 2009.bak

But it also fails with this error:

gpg: Fatal: zlib inflate problem: invalid block type

Is it somehow possible to recover this file? Maybe with HEX-editor or something like that? We really need to recover this file!

I appreciate any suggestions!

4
  • Life or death? I think you came to the wrong place...
    – EEAA
    Jan 29, 2013 at 5:47
  • Sorry. I removed this line about "life and death". Actually we've spent 36 sleepless hours trying to do something with this file, and Googled the Google In and Out...
    – user135199
    Jan 29, 2013 at 5:50
  • The file is obviously corrupted. Restore from backup. Jan 29, 2013 at 5:56
  • This file IS a backup that should be restored...
    – user135199
    Jan 29, 2013 at 5:59

2 Answers 2

4
+100

Decompression happens after decryption, so it's theoretically possible to get GPG to write out the compressed data stream. I'm not sure there's a stock option to do that-- you'll probably have to hack around in the source.

Once you've got the corrupt data stream, though, I'm not sure you're going to have much hope for getting the data back. I'm seeing that zlib output with full flush points can be partially recovered, but I'm not up on the technical details of how zlib compression is used in PGP. If I had to guess I'd say that you're out of luck.

Were this my data I'd try to hack GPG to write out the compressed stream, then get cozy with documentation for zlib and see what I could work out.

It sounds like you didn't verify your backup could be restored when you made the backup. If nothing else, you're learning a valuable lesson about testing restores before you actually need them.

3
  • I actually did verify the backup after compressing it with pgp. I decompressed it and restored just fine. But you are right about learning the lessons. I learned a lesson to always keep the text file with checksums for backups to verify them after copying to another location, I'm guessing that after copying the file got corrupted. It doesn't even matter that I have copied the file to two separate locations. The file could become corrupted after changing hard drives in RAID array on backup server. Now I know one thing, I had to copy these backups to a hard drive and keep it disconnected in safe
    – user135199
    Feb 1, 2013 at 11:57
  • Sorry if I sounded harsh. Being in a data-loss scenario is tough and I know what it feels like. W/ file formats that are particularly "brittle" (compressed, encrypted, etc) it pays to treat the copies carefully, making cryptographic checksums of the copies. With file sizes getting what they are today and single bit error statistics being what they are in RAM (especially non-ECC RAM), hard disk drives, and bus interconnect protocols, it's probably high time that the industry moves to archive formats with error-correcting functionality. We can certainly handle the tradeoff of space for safety. Feb 1, 2013 at 21:29
  • I am reminded of an Oracle dump file that wouldn't restore. Fortunately, the Customer had an independent copy that did work. When we compared them later on we found a single bit difference between the files. That one bit was enough to throw the whole process off the rails and, w/o access to the source code of the import utility, we would have been outta luck. Feb 1, 2013 at 21:31
0

Contact a data recovery company, I've had great success with www.ESSDataRecovery.com (1.800.237.4200) and they give free estimates. They may be able to either recover the backup file or the original data, if you still have the media it was on. They've probably worked with corrupt PGP files before.

Also get in touch with Symantec (they now own PGP), they may require you purchase an up to date license/support contract before helping at least decrypt the file.

You must log in to answer this question.