The worst one I had to recover from was actually from a customer. Hundreds of thousands of dollars daily transfers depended on the system. It went like this:

RECEIPE FOR DISASTER
Ingredients:
1 Power cable going accross the floor in the middle of a path where people walk constantly back and forth
1 Old/slow PC with insufficient HD space
2 Unexperienced PC operators
1 Limited budget
1 Dusty environment

Preparation
1. Define procedures to purge backup and purge DB to avoid the *disk full* syndrome. Make sure backup procedure is fool proof, for example, use Hanoi Tower rotation of disk sets always storing and extra blank formatted disk. This way if you don't have today's backup, you'll have yesterdays, or 4 days ago, or a week ago and so on. The Hanoi Tower rotation avoids using the same disks over and over again until you can see through them. For performance reasons the purge is done with no transactions, hence the recomendation to make a backup before doing it.
2. Due to budget restrictions, there weren't always disks available to complete the sets, so the users would use the disks of set C to complete the backup of set A among other transpositions Not necessarily registering the order of the disks.
3. Here you have 2 alternatives:
a. Since the operator is in a rush, skips the backup and goes on with the purge. Since the purge is taking some time, decides to reboot the PC before it ends.
b. Kick the power cord while the purge is running.
4. The oeperators are in a rush, so they don't report the error messages until the system doesn't work anymore.
5. The backups are performed every morning on the corrupted databases, with the disk permutations, effectively ruining any chance of getting reliable data.
6. Did I mention that the disks where often lying around in a dusty environment?

Presentation
Call the programmer to fix the problem telling him that due to budget restrictions they don't really have the money to pay full fare.

Note from the consultant: They were in wine country, so the location had other perks