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....