Recently my PGP Desktop encryption program suddenly lost its registration information. I don’t know why, although it may have had something to do with a series of driver updates, but when the system rebooted at one point, I noticed a registration request from the encryption product. I didn’t think much about it until I finished all the driver updates. At that point, I was ready to mount the PGP-encrypted volumes that contain confidential data such as Norwich University student records, client records, financial data and correspondence.
Now normally, if I need the registration information for a software product, I just open the licenses folder where I keep all of them neatly labeled and dated for easy access. Having a single place to go simplifies retrieval and updates.
Another aspect of my two tower computers – one (“MAIN”) for my home office and one (“SPARE”) for my university office – is that I am (or thought I was) compulsively careful about backups and business continuity:
• The system disk drives (C:) on both towers are RAID 1 arrays – mirrored drives.
• Every evening, towards midnight, an automatic backup procedure on MAIN creates a daily differential backup stored on its RAID.
• The next morning, that backup file is copied to an external 1 TB USB3 portable disk drive. In addition, all the disk volumes on the system are duplicated on the USB3 drive and synchronized using SyncToy. [Incidentally, I am currently evaluating ViceVersa PRO to replace SyncToy and plan to write about the products in a future column.]
• When I get to my university office, I immediately synchronize the USB3 drive with the corresponding volumes on SPARE using SyncToy.
• Thus at that point, there are three independent copies of all my user data: on MAIN, USB3, and SPARE.
• In the evening, I synchronize USB3 from SPARE and, when I reach home, MAIN from USB3.
• Again, at that point there are three identical copies of all the data.
• At the end of each month, I do a complete system backup using LapLink PCMover for C: drive from which I can reinstall the complete configuration, including all system data, program files and the registry. This process backs up MAIN but not SPARE because the hardware configurations of MAIN and SPARE are identical, so I can use (and actually have used) LapLink PCMover to recreate the operating system and files on SPARE starting from the MAIN PCMover backup.
• The full backup procedure then completes by copying all the files on the O: drive (a RAID 0 performance-striped pair) where non-sensitive data are stored as well as all the PGP volume files (*.PGD).
Sounds great, eh?
Yeah, well, I thought so too until I hit that PGP license snag.
It happens that a few days before the encryption program failed, so did one of the disks on the SPARE RAID 1 array. I shut the system down just before the July 4 weekend and disconnected all the cables. When the encryption program died on July 6, it suddenly dawned on me that all the license information is stored on my K: drive, which is a PGP-encrypted volume that lives as the file MK.PGD on my O: drive. Without a running, properly licensed instantiation of PGP, I could not retrieve the license information that would allow me to retrieve the license information.
Slapping my forehead in embarrassment, I had to
• Re-install all the cabling for SPARE,
• Boot SPARE,
• Copy the PGP license files from the encrypted K: drive on spare to an unencrypted directory on the USB3 drive,
• Copy the PGP license files from the unencrypted folder on the USB3 drive to the corresponding location on MAIN, and
• Fill in the PGP license information for MAIN.
It was pure luck that
• SPARE happened to be in my home office instead of at the university office or the repair shop that day and
• The remaining RAID 1 drive still worked on SPARE so I could load the encrypted volume to extract the license data.
I sure have learned a lesson. In addition to making you laugh, perhaps I can parlay the experience into lessons for all of us to think about to make up for my feeling like a complete idiot. Each of the following examples of avoiding a recursive trap should be greeted with loud “Duhhh” sounds. I’ll start with the issue described above.
• Don’t put license information for your encryption product solely on an encrypted volume that requires your encryption product to properly licensed to allow access to the license information that is needed to … oh phooey.
• Don’t put the only written copy of the combination for your fire safe into the fire safe.
• Don’t put your essential drivers on a storage device that is impossible to read without one of the drivers that is on that storage device.
• Don’t put your backup media next to the system they are supposed to back up in case of, say, total destruction of your facility by fire, flood, earthquake, tornados or any of the other lovely environmental disasters we’ve been suffering lately.
• Don’t put the safety ladder that is the only way of getting out of your bedroom in case of a fire somewhere other than your bedroom.
Well, that’s enough for today. I’ll just go off into a corner now and hit myself in the head repeatedly with an old portable disk drive.
