How to snapshot everything important with ZFS, and destroy the snapshots later

One of the coolest features of ZFS is that you can create snapshots of filesystems before making changes, and revert them later if those changes cause problems. This is great for major updates, especially involving experimental software. If you had your whole system on a single filesystem this would be very easy, but you probably don't, especially if you are using ZFS. Luckily, it is pretty simple to make and destroy these snapshots.

I say destroy because this is what ZFS calls it when you remove a snapshot, freeing up any storage that was related to data which has since been changed. But before we get to destruction, let's talk about creation. The first question to answer is, what filesystems do I need to snapshot? The probable answer for a basic user is everything, but what if you have some other filesystems which aren't going to be involved in whatever you're doing?

For most users, the "operating system" is going to be stored on two pools in particular: bpool, or boot pool, which contains only the files needed to boot the system, and rpool, or root pool, which contains all of the other parts of the system itself. This usually includes the home directory, where your files are stored. There is no reason not to snapshot all of these directories when doing anything major. I have another pool for other data ("spool") that I don't want to take a snapshot of when I'm doing an OS update, as it won't be affected by changes to the system. Assuming that you have used the usual bpool/rpool convention when creating your system, this little script will make a snapshot of every single filesystem stored in those two pools, then list all of the created snapshots for you:

#!/bin/bash
# snapshot all the important pools
DATETIME=`date +'%Y%m%d-%H%M'`
for POOL in rpool bpool
do
  for FS in `mount|grep ^${POOL}\/ | cut -f1 -d' '`
  do
    sudo zfs snapshot ${FS}@${DATETIME}
  done
done
sudo zfs list -t snapshot | grep ${DATETIME} | cut -d' ' -f1

Booting into a recovery system and reverting to the snapshot is going to have to be a separate article, because it covers a lot of ground, but the short form is that once you get booted up and can make changes, you need to use zfs rollback snapshot to restore partitions to their former selves. But what if everything goes great, you've been testing for a few days, and there's no reason to revert? First, use zfs list -t snapshot to get a list of snapshots on your system. Figure out what label was used (for the example script above, it will be pretty much all numbers; for a real example, 20250330-0814) and then do this:

sudo zfs list -t snapshot | grep 20250330-0814 | cut -d' ' -f1

This will print a list of the filesystems you are about to affect. Look at this carefully, do not just assume that you know what you're doing and all will be well if you pull the trigger! Because you're using zfs list with -t snapshot, you should be looking only at snapshots, and it should be safe to remove them, but we're talking about a major irrevocable act here, and you do not want to get this wrong — especially if you have not tested your backups.

Have you tested your backups? If you are backing up SSDs in your system, it should be cost effective to get one or two external disks (for redundancy, another thing easily done with ZFS) which you can make a bootable backup on. This both allows you to prove immediately that it works, and to use it to rescue your system if you mess it up.

If the list does somehow have things in it that you don't want to remove, probably the easiest way to handle that is to either manually remove each snapshot you do want destroyed (especially if they are few) or to redirect the output of the above line into a file and edit it out; then use cat filename between the backticks (the `` marks) in the following for loop:

for i in `sudo zfs list -t snapshot | grep 20250330-0814 | cut -d' ' -f1`
do sudo zfs destroy $i
done

Varieties of this strategy can be used for general system checkpointing; you could just fire the snapshot script off on a schedule, e.g. by making a link to the script in /etc/cron.monthly (assuming you've installed cron, which amazingly is somehow not part of the default install, and I did manually. What a weird world where a Unixlike can come without cron.)