As far as I can see, this scheme gives you one backup copied to three places, on two different media.
What if the source for the backup was already corrupt or broken in some way? If you only have one backup, then your backup is corrupt too.
I was taught grandfather-father-son back in the 80s; still three levels of backup, but they're different generations. That fitted the kinds of media available then, but it doesn't really map to modern equipment. I've struggled to work out a backup scheme that is equally adaptable to the needs of a small business, a home network or an individual.
Ironically, it's hardest for the individual; a modern business is finished if it loses all its data. For an individual (or even a hobby network), total data-loss is painful, but not usually an existential risk. So it's harder to justify keeping everything in triplicate.
Reminds me a story here on HN, when they had plenty of backups, all encrypted with an in-memory key which was accidentally never saved to disk even on their primary server.
Doesn't the use of snapshots (and their backup) help with this ?
I am assuming here that you mean that the source got corrupted some time after it was created (and anyway, if it is not the case, it is a issue unrelated to backup, in my opinion).
A proper backup tool should help you keep several versions of your data without using a proportional amount of space, by using some form of deduplication. I use borg backup for my backup, and I can go back to any day in the past three years and get an old copy of any document (as long as I saved it on my disk for more than one day, since I do daily backups)
You can also setup "append only" backups, if you are worried that somebody may willingly try to destroy your old copies
I use Apple's TimeMachine backups as my sources, and BackInTime on the Linux boxes I care about, so I'm backing up an archive which preserves previous versions of files. I push 12 rolling monthly archival copies of them into AWS Glacier, and keep one of those as an annual archive. That's costing me around $200/year in Glacier costs. I've only ever done a restore once from there as a test, from memory it cost me ~$30 in retrieval charges.
Those are checks of binary integrity. They can't confirm that data hasn't been deliberately or accidentally replaced, added or deleted.
I would like to have a grandfather, a week old; a father, a day old; and a son, being last night's backup. All on different media, amd ideally not connected to the source machine.
Ransomware is the #1 thing an enterprise will use a Backup to recover from, the second most common is accidentally deletion.
Binary corruption is very very very very very rare and with all the systems in place to prevent it, is not even something I even think about anymore. I worry about Ransomware, and users doing stupid things
I think the parent is suggesting you've moved out of "backup" territory, into archive and/or disaster recovery territory.
I agree with you problem description and approach. I'm less sure I agree with your terminology choice.
I use a software raid 1 pair of external usb drives on a wifi powerpoint to take a once a week snapshot of my backups, and the drives are only powered up for ~1 hour a week. Not guaranteed protection agains ransomware, or me fat fingering a "sudo rm -rf / tmp", but "good enough" for my home/personal stuff. I also have monthly and yearly snapshots of my backups in AWS Glacier. I sometimes colloquially refer to all that as "backups", but I can see your parent posters point that I've gone way beyond what "backups" covers in this paragraph.
In my head at least, backups are a subset of disaster recovery.
They are linked, but you can do backups without doing disaster recovery (for example, just turning on TimeMachine backups to a usb drive on your Mac is “backups” without being “disaster recovery”), but you can’t do disaster recovery without backups. But you also need archives, and retention policies, and recovery procedures and test plans, and training and practice for the people responsible for DR, and hardware/site/network disaster recovery plans and resources, and recovery time objectives and recovery point objectives, and a whole bunch of other “not directly backup” related stuff.
But I admit that colloquially that might all be assumed in certain contexts to be “backups”, but that’s a probably dangerous assumption unless everybody in that discussion is totally on the same page about just how much of that related disaster recovery stuff is actually in place and ready.
Which is why you have immutable backups, and you do not simply over write everything. this is not a new concept, or a new thing. To believe ransomeware protection is not a function of proper backups is just ignorant. Anyone working in Enterprise IT, managing backups for any company, that is the #1 thing we talk about, that is the number 1 thing we are focused on in our backup strategy. We spend significant resources on it.
That doesn't matter. If you create a new backup, then your ransomwared files will be in that backup. Immutable just means that after the creation, the backup can't be modified anymore.
So, how do you detect if you have ransomwared data? My take is that a backup can't help with that. It can help with restoring obviously.
What if the source for the backup was already corrupt or broken in some way? If you only have one backup, then your backup is corrupt too.
I was taught grandfather-father-son back in the 80s; still three levels of backup, but they're different generations. That fitted the kinds of media available then, but it doesn't really map to modern equipment. I've struggled to work out a backup scheme that is equally adaptable to the needs of a small business, a home network or an individual.
Ironically, it's hardest for the individual; a modern business is finished if it loses all its data. For an individual (or even a hobby network), total data-loss is painful, but not usually an existential risk. So it's harder to justify keeping everything in triplicate.