Hacker News Reader

Comment by hijinks | Hacker News Reader

then they have learned an important messages.. raid or replication isn't a backup

Replication and Raid isn't a backup because what if i do this in mysql

mysql> drop database production;

No way raid/replication will save you then. Same thing for some rogue delete statement gets in the code that deletes too much data.

Raid isn't a good backup because groups of drives are known to die at once or around the same time.

You can't drop a database on postgres if anyone is connected to it, which is likely the case on production.

TRUNCATE TABLE users; should work and will have similar disastrous effects.

You can revoke truncate from public.

Oh, sure. I'll just do "DELETE FROM users" and forget about the WHERE clause. Same effect.

It's not a backup because it will happily propagate data corruption through making all drives worthless. The only backup-like protection is provides is for sudden drive failure.

Replication on Postgres can be the basis of a backup, IFF you store base base backups and WAL logs.

In normal life, your secondaries just chug along, consuming WAL logs.

Should you do something like drop/truncate a table, you can start with your base backup and replay the logs till just before your fat finger.

If it's disk failure -- then replication is best backup ever.

Can you further explain why raid/replication isn't a backup? Sure, you can't backup beyond what you've replicated (locally or across a network), but for most folks, that should be fine.

What happens if you accidentally run "delete from orders"? Or drop the database? Or need to access data that was updated in place last week?

Trolling, I assume? Just in case not: your own oh-shit moments (forgot that WHERE clause?), coding errors and oversights, bad luck, adversary SQL injection because the contractor who wrote some obscure admin page two years ago didn't know what he was doing, customer screw-ups (your web app customer fat-fingers their own critical data out of existence and begs you to roll them back to yesterday), etc.

If you have a real business you need a multi-generational backup scheme of some kind.

"Backup" means, more specifically, multiple backups at various points in time.

You're kidding right? RAID is only good for dealing with HW failures, there are many more kinds of SW failure that can screw you and leave you with nothing, while having a perfectly good raid. Replication isn't a backup because if you screw up your dataset, well that screwup just got replicated.

RAID and replication are good for protecting against hardware failure, but hardware failure actually accounts for only a handful of the reasons you want a backup. RAID, replication, and backups are all solutions to problems. Once you look at the problems instead of the solutions, your answer becomes clear.

Often, the need for a backup arises from the need to go "back in time". RAID and replication offer no solution for this. Ok, so depending upon your replication setup, it may offer some help, but the steps required to go back in time usually involve starting from a recent backup, and using files involved in the replication to "replay" recent changes to get you back to the moment in the past you wish to return to.

indeed, may don't realise that, and a mistake/error replicated is still a mistake/error.

Still least I hope they didn't have transaction logging onto the same discs, seen that in horror because somebody had large raid array and did not think they needed the expense of another.

Reply on news.ycombinator.com