3 ms·
Untested backups and DR/BCP procedures aren't backups. Snapshots aren't backups. Backups that aren't physically-isolated, typically offsite, aren't backups.
by failwhaleshark 5y ago
Untested backups and DR/BCP procedures aren't backups.
Snapshots aren't backups.
Backups that aren't physically-isolated, typically offsite, aren't backups.
- bottled_poe 5y agoWell then, It’s starting to sound like backups aren’t what a business needs.
- des1nderlase 5y agoBackups are there to provide a business continuity in wide range of disruptions. What you want to protect your business from is up to you, but typically you need protection from all things OP mentioned.
- VendorManager 5y agoBackups and disaster recovery sites are definitely important from business continuity perspective, but there is a bigger risk of leaking PII and other sensitive information such as SIN / Social security numbers if the software vendor has access to it. Your business might be able to recover from backup if the hacker has not encrypted it, but the hacker for sure will be maliciously using the PII information to send phishing emails.
- failwhaleshark 5y agoThese are somewhat orthogonal issues. 1. Test and encrypt backups. 2. Don't get hacked. Defense-in-depth philosophy and rigorous, routine social-engineering training/testing. If you get hacked, it's usually game over. Defend systems like the business depends on it because it does. 3. Limit exfil: extra security for PII, exfil detection, and [HN]I[DP]S.
- etherael 5y agoWhy are offsite write only continuously incremental snapshots from a full start not backups?
- des1nderlase 5y ago"Off-site write only continuously incremental snapshots from a full start", that can be interpreted as a backup strategy (i.e. a DB would do something like that with full/diff/log backups), but you just changed what snapshots means. What OP tried to demonstrate that backups need to protect from bad changes, on physical, logical, and business layer, from data corruptions to 'oops' scenarios (i.e. drop table). Standard snapshots for sure don't protect from all those. Also for a good backup strategy, you need - "a full start" once in a while, because corruption in "full backup" will invalid all incremental snapshots - regular restore of a backup for e2e validation
- etherael 5y agoAlright, was curious as this is how I have been handling my third layer of backups for quite a while now, regular incremental encrypted zfs snapshots to an offsite storage provider using API keys that only have write priveleges. Wanted to make sure it wasn't something about "snapshots" which made this a bad idea in a way I hadn't thought of. Doesn't seem that's the case.
- arendtio 5y agoPlease define snapshot. I suspect you mean filesystem snapshots and as long as the snapshot lives on the same physical media you are correct. But when you take the snapshot and transfer it to a physically separate location where it cannot be altered it sounds like a backup to me.
- failwhaleshark 5y agoPhysically-separate location or not snapshots that can be added, updated, culled, or deleted by local systems aren't backups, they're replication. Replication replicates problems. Vaulted offsite on at-rest storage media is the only valid way to store backups. Every other "convenient" "backup" service or snapshot replication process is a liability businesses must avoid. Lose all your data, 50%+ you're out of business, and The End.