Hacker News new | past | comments | ask | show | jobs | submit login

I've been using zfs on Debian for over half a year now. I've been really happy with the stability, going through a handful of power outages and the addition of another drive.



ZFS lets me back up every `apt-get` action, which is useful on Debian Testing:

    /etc/apt/apt.conf.d/71backup

    DPkg::Pre-Install-Pkgs {"/sbin/zfs snapshot rpool/ROOT/debian@apt-get_$(date '+%Y-%m-%d-%H%M%S')";};
When I inevitably break Debian with no time to troubleshoot, I do

    # zfs list -t snapshot | grep apt\-get
    ...
    # zfs rollback -r rpool/ROOT/debian@apt-get_<insert time stamp here>


Oh my god.

This is such a simple thing, and yet it somehow didn't occur to me until now... if ZFS is your OS's root filesystem, you can use ZFS snapshots to capture and roll back the complete state of your system. Just like that, no other special tools needed. Wow.


This isn't really new. You've been able to do this with LVM for years, but it isn't quite as graceful.


It’s fairly graceful with btrfs, and Ubuntu has been doing that by default if the root fs is btrfs for quite a while. The only trouble is that you’re liable to run out of space in /boot/ eventually.


Nice.

I haven't touched ZFS since it first came out on Solaris around 2008ish (we had a 48 drive "x4500", great hardware, but solaris :/ )

Are the snapshots instant? I'd be tempted to replace "sudo" with something that snapshotted them too!


> Are the snapshots instant?

Yes, it just copies & stores the block at the top of the filesystem[0], in the same way naming a git tree will keep its content recursively alive.

However all the data in the snapshot is retained as-is until the snapshot is destroyed, so as the system keeps being used and diverges from the snapshot the snapshot is slowly going to "increase in size" compared to the live FS.

[0] there's also a more recent "checkpoint" concept which "saves" the entire pool by copying the uberblock.


The actual act of snapshotting doesn’t do a whole lot. I believe ZFS uses CoW for that purpose. If you modify a file after a snapshot, the file (or block) will be copied first. Normally, with CoW, the original would then be marked as free space available for writing, but if a snapshot exists, it will be preserved. (This is a general concept; I don’t know the nuances of ZFS’ approach.)


I thought that was the case, but in more recent times they only snapshotting I've done is on AWS instances which take forever


> Are the snapshots instant?

Yes. But you have to remember to delete the old ones at some point.


Plugging a small script I wrote that is a bit more targeted than this by only snapshotting the datasets that are going to be changed. Haven't written a readme for it yet (or packaged it :) ) but both files have some header comments explaining how they're used and where they're put.

https://github.com/paxswill/zfs-apt-snapshot


I've set up something similar on FreeBSD with just a shell function wrapping pkg and port, very handy.


This is the whole concept of Solaris boot environments


Me too. I’ve been really surprised at how easy it is. Even migrating to a fresh OS was a breeze and didn’t require me backing up any configs.


Do you mean ZFS as root or as a data partition? and when you say migrating to a fresh OS do you mean the Stretch to Buster upgrade? If so, it is great to hear it is working so well now.


ZFS data volume. Haven't tried root yet (wasn't easily available when I created the volume). Still, a data volume in ZFS is so much better than the traditional md raid. Won't go back.


Not the grandparent, but I've moved a running system from one ZFS pool to another without physically touching the computer. The OS was running off a ZFS root.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: