Hacker News Reader

Comment by amelius | Hacker News Reader

I suppose that snapshotting will cause old versions of the data to be thrown away, once the old versions start taking up too much disk space. Then I suppose the ransomware can take advantage of this and simply perform so many writes that the unencrypted versions of the data are thrown away. And isn't this what happens anyway when a disk is nearly full and you start encrypting its contents?

View on HN

Typically these systems are set up to automatically snapshot on a periodic basis (say nightly) and automatically pruned after another period (say monthly) - if there was massive activity due to ransomware causing a full disk in most such systems it'd have to be manually investigated, it wouldn't just decide to delete snapshots to free space.

It certainly should help against ransomware in that an admin who was investigating an unexpectedly full disk, who's hopefully aware of such things, would probably notice that all the files on the drive were no longer readable and all had recent modification timestamps. And that's if a user doesn't happen to notice it first and report issues with their files to IT.

As long as those snapshots last more than a few days as to provide sufficient time to catch and investigate the issue, ransomware damage is usually revertable much faster than backups with simple snapshots.

That's not at all how ZFS snapshotting works. ZFS snapshots are manually managed. And totally awesome.

If there are no automatic snapshots by default then the snapshots are just like backups - i.e. an active measure the user has to take? Then it doesn't really protect against ransomware (Assume that we are talking about users who don't have backup - they wouldn't have zfs snapshot either?)

ZFS snapshots can be automated. I have ZFS periodic snapshots enabled on my FreeNAS system, where I can select when snapshots will occur (frequency and time) as well as how long the snapshots will be kept.

Backups can also be automated. I think that parent's point is that, like backup, if it isn't the default then users are probably not doing it. It is my experience that most people, even people who should know better like you or me, think of data loss risks as theoretical until they've experienced it first hand once or twice.

For better or worse, ZFS isn't really targeted at "average users" as of right now.

See also: There is no stable ZFS implementation for Windows as of right now, and the implementation for macOS (while surprisingly painless in general) requires at least some command line use to set up.

If anyone actually develops a ZFS implementation designed for average users, I would agree that it should include automated backups by default.

> so many writes that the unencrypted versions of the data are thrown away

I don't know about this specific system, but typical behaviour of NILFS (a continuously shapshotting log file system) is to report the filesystem as full, requiring manual intervention or waiting until the data ages-out and gets garbage collected.

It would be weird for a system to throw away its backups automatically at arbitrary times.

Apple's Time Machine does.

What would you have the software do when it runs out of space? IMO, not making new backups would be worse than deleting old ones.

It's actually not allowing you to write new data at all. So it prevents the user from assuming there is more space to store his data, as there is not sufficient space with his indicated/configured data retention wishes.

Reply on news.ycombinator.com