Kahibaro
Discord Login Register ☰
☰
Previous
Up
Next

Using snapshot systems

Table of Contents

Why Snapshot Systems Matter

Snapshot systems let you capture the state of data at a point in time and revert to it later. Unlike traditional backups (which usually copy data elsewhere), snapshots are typically:

They are especially useful for:

This chapter focuses on practical use of snapshot-capable systems you’re likely to encounter: LVM, Btrfs, ZFS, and filesystem-integrated snapshot tools.

Core Concepts Specific to Snapshots

To use snapshot systems effectively, you should recognize a few snapshot-specific ideas:

Using LVM Snapshots

Logical Volume Manager (LVM) can create snapshots of logical volumes. This works at the block layer, below filesystems.

Common Use Case

Creating an LVM Snapshot

  1. Check free space in the volume group:
sudo vgs
sudo lvs

You need enough free space in the volume group to hold changes made after the snapshot is taken.

  1. Create a snapshot logical volume:

Example: 10G snapshot of vg0/root named root_snap: 

sudo lvcreate -L 10G -s -n root_snap /dev/vg0/root

Key options:

  1. Use the snapshot

Mount it read-only to inspect or export data: 

sudo mkdir -p /mnt/root_snap
sudo mount -o ro /dev/vg0/root_snap /mnt/root_snap

You can now copy files out, compare configs, etc.

Reverting to an LVM Snapshot

LVM snapshots are typically designed to be short-lived. If you want to revert the original LV to the snapshot’s state:

  1. Ensure the origin is not mounted (or mounted read-only in special cases):
    • Boot into rescue mode or a live environment.
    • Unmount the original filesystem, e.g.:
   sudo umount /dev/vg0/root
  1. Merge the snapshot back:
sudo lvconvert --merge /dev/vg0/root_snap

After merging, the snapshot LV disappears, and the origin LV returns to the snapshot state on next activation (e.g., reboot).

Removing LVM Snapshots

Snapshots consume space as changes occur. To remove them: 

sudo umount /mnt/root_snap
sudo lvremove /dev/vg0/root_snap

Monitoring usage: 

sudo lvs

Watch the Data% or Cpy%Sync fields for snapshot space usage. If the snapshot runs out of allocated space, it can become invalid.

Btrfs Snapshots

Btrfs is a COW filesystem with built-in snapshotting. You work with subvolumes and their snapshots.

Basic Workflow

Assume:

Listing Subvolumes and Snapshots

sudo btrfs subvolume list /

Snapshots are just subvolumes, but typically stored in a dedicated directory (e.g., /.snapshots or /@.snapshots).

Creating a Snapshot

Read-only snapshot of / subvolume @ into /.snapshots/@-preupdate: 

sudo mkdir -p /.snapshots
sudo btrfs subvolume snapshot -r /@ /.snapshots/@-preupdate

Key options:

Using a Snapshot

Mount a snapshot to inspect or recover files: 

sudo mkdir -p /mnt/btrfs_snap
sudo mount -o subvol=@-preupdate /.snapshots /mnt/btrfs_snap

(Exact mount command depends on how your root btrfs volume is laid out; sometimes you mount the main device, e.g. /dev/sdaX, with -o subvol=....)

Then: 

sudo cp /mnt/btrfs_snap/etc/important.conf /etc/

Deleting a Snapshot

sudo btrfs subvolume delete /.snapshots/@-preupdate

You should periodically prune snapshots to reclaim space and keep performance reasonable.

Rolling Back with Btrfs

For root filesystem snapshots, a typical rollback strategy is:

  1. Boot into:
    • a snapshot-aware boot entry (some distros create GRUB entries per snapshot), or
    • a live/rescue system.
  2. Change which subvolume is used as the default:

List subvolumes with their IDs: 

   sudo btrfs subvolume list /

Set default subvolume to a known-good snapshot: 

   sudo btrfs subvolume set-default <subvol_id_of_snapshot> /
  1. Reboot. The system will boot into that snapshot state.

Different distributions provide tooling around this (e.g., snapper, timeshift), covered further below.

ZFS Snapshots

ZFS integrates filesystem and volume management, and has a robust snapshot system.

Assume:

Listing ZFS Snapshots

sudo zfs list -t snapshot

Snapshots are named as dataset@snapname, e.g., tank/root@preupdate.

Creating a Snapshot

sudo zfs snapshot tank/root@preupdate

For multiple related datasets: 

sudo zfs snapshot -r tank@preupdate

-r creates snapshots recursively for children.

Accessing Snapshot Data

Many systems auto-mount .zfs/snapshot under the mountpoint. For example: 

ls /@.zfs/snapshot
ls /@.zfs/snapshot/preupdate

If root is on tank/root, you might see:

You can copy files from there: 

sudo cp /tank/.zfs/snapshot/preupdate/etc/important.conf /etc/

Rolling Back with ZFS

Rollback discards all changes made since the snapshot: 

sudo zfs rollback tank/root@preupdate

You can also roll back recursively if using recursive snapshots: 

sudo zfs rollback -r tank@preupdate

Note that rollback is destructive: newer snapshots may be affected depending on flags used. Read the zfs-rollback man page carefully on production systems.

Deleting ZFS Snapshots

To free space: 

sudo zfs destroy tank/root@preupdate

You can use zfs list -t snapshot to see which snapshots consume the most space (REFER and USED columns).

Snapshot Management Tools (Snapper, Timeshift)

Several tools provide friendlier, policy-based management on top of Btrfs or rsync-like snapshots. These don’t replace understanding the underlying mechanisms, but they simplify daily use.

Snapper (Primarily Btrfs)

Snapper manages Btrfs snapshots, including:

Basic Operations

Create a snapshot: 

sudo snapper create --description "before upgrade"

List snapshots: 

sudo snapper list

Compare snapshots (diff): 

sudo snapper diff <id1> <id2>

Undo changes between snapshots: 

sudo snapper undochange <id1>..<id2> /path

Exact integration and configuration differ by distribution (often in /etc/snapper/configs/), but the pattern is:

Timeshift (Desktop-Focused)

Timeshift primarily targets desktop systems, offering snapshot-based system restore using:

Typical workflow:

  1. Configure Timeshift:
    • select snapshot type (Btrfs/rsync),
    • set location and schedule,
    • choose inclusion rules (usually system files, not user data).
  2. Timeshift automatically makes:
    • hourly/daily/weekly snapshots,
    • “before package upgrade” snapshots (on some systems).
  3. To restore:
    • run Timeshift,
    • pick a snapshot,
    • choose “Restore” to revert system files to that state.

Timeshift focuses on system-level state, not user home data (you use separate backup tools for /home).

Snapshot Strategies and Best Practices

When to Use Snapshots vs Traditional Backups

Snapshots are:

Good pattern:

Typical Snapshot Policies

Examples (adjust for your needs and space):

Space Management

Keep an eye on:

Tools:

Automated cleanup using tools like Snapper or custom scripts is often necessary.

Consistency Considerations

Snapshots capture an instantaneous view of the filesystem or block device. For application-consistent snapshots:

On small personal systems, this level of rigor is often skipped, but on important servers, it matters.

Integrating Snapshots with Backup Workflows

A common pattern:

  1. Create a snapshot of the dataset/filesystem.
  2. Back up from the snapshot, not the live filesystem:
    • ensures a consistent view;
    • avoids locking files for long.
  3. Delete the snapshot when the backup completes.

Example with Btrfs: 

SNAP_NAME="backup-$(date +%F-%H%M)"
sudo btrfs subvolume snapshot -r /@ /.snapshots/@-$SNAP_NAME
# Backup the snapshot (to remote host, for example)
sudo rsync -aHAX /.snapshots/@-$SNAP_NAME/ user@backup:/backups/host/root/$SNAP_NAME/
# Remove snapshot
sudo btrfs subvolume delete /.snapshots/@-$SNAP_NAME

This pattern works similarly with ZFS (zfs snapshot then zfs send | zfs receive or rsync) and LVM (snapshot LV, then mount and back it up).

Summary

Previous
Up
Next

Views: 28

Comments

Please login to add a comment.

Don't have an account? Register now!

© 2025 Kahibaro

Visitors: 1499 / 24h

Impressum / Imprint

Datenschutz / Data Policy