5 ms·

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 snapsho

by gralx 7y ago

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>

dddddaviddddd 7y ago
I've set up something similar on FreeBSD with just a shell function wrapping pkg and port, very handy.
isostatic 7y ago
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!
- GrayShade 7y ago
  > Are the snapshots instant? Yes. But you have to remember to delete the old ones at some point.
- masklinn 7y ago
  > 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.
- zenexer 7y ago
  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.)
  - isostatic 7y ago
    I thought that was the case, but in more recent times they only snapshotting I've done is on AWS instances which take forever
Wowfunhappy 7y ago
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.
- dpedu 7y ago
  This isn't really new. You've been able to do this with LVM for years, but it isn't quite as graceful.
  - zenexer 7y ago
    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.
rkeene2 7y ago
This is the whole concept of Solaris boot environments
paxswill 7y ago
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 https://github.com/paxswill/zfs-apt-snapshot

by gralx 7y ago

dddddaviddddd 7y ago

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

isostatic 7y ago

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!

GrayShade 7y ago
> Are the snapshots instant? Yes. But you have to remember to delete the old ones at some point.
masklinn 7y ago
> 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.
zenexer 7y ago
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.)
- isostatic 7y ago
  I thought that was the case, but in more recent times they only snapshotting I've done is on AWS instances which take forever

Wowfunhappy 7y ago

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.

dpedu 7y ago
This isn't really new. You've been able to do this with LVM for years, but it isn't quite as graceful.
- zenexer 7y ago
  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.

rkeene2 7y ago

This is the whole concept of Solaris boot environments

paxswill 7y ago

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 https://github.com/paxswill/zfs-apt-snapshot