Computer Hardware failures

I lost a lot of data that I had intended to keep.

Confound and blast that infernal computing device! (And the User who deleted a file that he wanted to keep...wait a minute, that is myself.)

To explain, from the beginning:

I've been kind of paranoid about keeping backups of important files. This was made much easier when I discovered that Linux made this fairly easy. As long as I had a place to keep backup files, I could create a cron-job and a script that would generate backup copies.

And the "place to keep backup files" was, usually, a second (or third) hard-disk on my main machine.

Much later, when I decided I wanted to use an older computer as a print-server, it also took on the role of backup-server. Thus, the backup script used the local extra-hard-disk for backups, and copied the backups out to an external machine.

Even later, I discovered the fun and joy of version-management software. This is a custom database for data files. Usually, tools like SubVersion or Git are used by software teams to manage and document the history of changes to software projects.

But I realized that SubVersion could also track a bunch of document files. (Like the spreadsheet I use to manage my finances, or electronic copies of receipts for online purchases, or the other files cluttering the local "Documents" folder on my "/home" partition.)

While I was doing this, I also learned about and purchased a portable, external Hard Disk. So I configured the external drive as the local Backup-plus-home-of-SubVersion repository. And I tweaked a couple of scripts on the aforementioned cron jobs to handle things.

Except I got lazy, and mangled one of the path names. And one script, intended to create a backup "dump" of the history of the SubVersion repository, never worked properly.

Thus, when I began hearing odd noises from the external backup drive, I investigated.

I discovered that the backup "dump" of the SubVersion repository wasn't useful. And I discovered that the partially-failed drive left the SubVersion repository in a state that could not be updated, modified, or fixed.

So I manually pulled the dump. Which was successful at bringing out 90-something-percent of repository history.

And then I tested rebuilding the SubVersion repository from the dump. It appeared to succeed, so I deleted the dump, and attempted to re-create it.

Which was the wrong order of operations...I should have attempted to create another dump file from the restored repository before I deleted a known-mostly-good dump. Because the restored repository failed much earlier in the dump process.

And by deleting the older dump file, I lost most of the history that I had intended to keep.

My backups are still in good order, but I lost a lot of history.

One other thought: if I had used Git instead of SubVersion, the local file system would contain the entire history, as would the repository on the remote drive. Maybe I should switch to Git....