We had this debate a couple of weeks ago: always clone your DB to a staging or local server and practice on that, and never do your delete-fu in a REPL!

But as we all hated that bloody website anyway I doubt anyone will shed a tear.

Maybe it was a relational-algebra-based freudian slip...

If you have a good setup, you shouldn't need to backup the database before every destructive operation. If I went in and accidentally deleted every user record in my database right now -- the site would crash -- but I would be able to restore the site to the point judt before I screwed it up. This recovery would come from the last full backup and the transaction logs.

If my server crashes, the hot replicated backup server will take over. If a hacker destroys both servers and all local backups then I have my last full offsite backup and my nightly off-site transaction log backups so, at most, I'd lose one day.

And I'm not much of a sysadmin -- I've a sole developer and I usually sysadmin by Googling everything and using some common sense and yet I still managed to throw this setup together. You would think a site as big and important as jQuery would put have some common-sense backup procedures in place.

Definitely. And after you back up, do a SELECT, confirm you're seeing the correct records, and only then change the SELECT to a DELETE.

There are two periods in your career when you are most likely to this: when you very little experience or a whole lot of experience. The former because you have no idea what you are doing, the latter because goddamnit I know what I'm doing.