3 ms·

it absolutely is a backup problem Ransomware is the #1 thing an enterprise will use a Backup to recover from, the second most common is accidentally deletion.

by syshum 5y ago

it absolutely is a backup problem 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

gsich 5y ago
It's not. You can backup ransomwared files all the same.
- syshum 5y ago
  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.
  - gsich 5y ago
    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.
- pnutjam 5y ago
  My backup drive would fill up and alert me since it's btrfs formatted and all the encrypted data would be new data not in an existing snapshot.
bigiain 5y ago
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.
- syshum 5y ago
  I don't view backups and DR as wholely distict things. DR is a set of policies and procedures that cover backups. That are inextricably linked You use backups to perform a diaster recovery. I personally dont believe you can talk about backups with out including DR nor can you talk about DR with out talking about backups
  - bigiain 5y ago
    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.

by syshum 5y ago

gsich 5y ago

It's not. You can backup ransomwared files all the same.

syshum 5y ago
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.
- gsich 5y ago
  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.
pnutjam 5y ago
My backup drive would fill up and alert me since it's btrfs formatted and all the encrypted data would be new data not in an existing snapshot.

bigiain 5y ago

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.

syshum 5y ago
I don't view backups and DR as wholely distict things. DR is a set of policies and procedures that cover backups. That are inextricably linked You use backups to perform a diaster recovery. I personally dont believe you can talk about backups with out including DR nor can you talk about DR with out talking about backups
- bigiain 5y ago
  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.