openSUSE Btrfs Snapshot Rollback: Minimal Architecture Note

Requirements

Package updates can leave openSUSE unbootable or break critical services. The requirement is a fast recovery path for the root filesystem that can be triggered after a failed transaction, with point-in-time capture, minimal runtime overhead, and a verifiable restore.

Btrfs provides copy-on-write subvolumes that can be snapshotted without unmounting. The design must keep system and user data separable, keep snapshots inside a trusted storage boundary, and allow operators to confirm integrity after rollback.

Smallest Suitable Design

The smallest viable design uses two subvolumes on the same Btrfs pool: @ for root and @home for user data. A dedicated directory /var/snapshots holds read-only snapshots of @.

Snapshot creation is automated via a Zypper pre-transaction hook. The hook runs as root before a transaction that modifies the root subvolume and creates a timestamped read-only subvolume under /var/snapshots. This gives a recoverable state before each major package change.

Mounting is typically @ at / and @home at /home. /var/snapshots is a normal directory inside @, so snapshots are stored as subvolumes in the same pool. This avoids extra devices and keeps management simple.

Trust and Data Boundaries

Snapshots reside on the same Btrfs pool as the live subvolumes. This keeps snapshots inside the trusted storage boundary and prevents an attacker with access to untrusted media from replacing a snapshot.

@home is excluded from root snapshots. User data is kept in a separate subvolume to avoid unnecessary duplication and to maintain a clear boundary between system files and user files.

Only privileged users can create or delete snapshots. The hook and manual snapshot commands require root. Normal users cannot interfere with the rollback mechanism.

Operational Checks

Verify subvolume layout as root. Run btrfs subvolume list / . Expected check is entries for @ and @home.

Verify snapshot directory exists and is writable by root. Run ls -ld /var/snapshots . The directory should exist and be owned by root.

Validate hook-driven creation. Enable the pre-transaction hook, run a Zypper transaction that modifies root, then run btrfs subvolume list /var/snapshots . A new subvolume entry with a timestamp name should appear.

Validate integrity after restore. After restoring @ from a snapshot, run zypper verify as root. The command reports package consistency. Any errors indicate a failed restore.

Monitor space. Run btrfs filesystem df / as root. Check Data and Metadata usage against the device size. Snapshots consume space for new writes after the snapshot point.

Concrete Example

Manual snapshot creation as root:

mkdir -p /var/snapshots
btrfs subvolume snapshot -r / /var/snapshots/snap-$(date +%Y%m%d-%H%M%S)

The -r flag creates a read-only snapshot. Risk: the command requires root and sufficient free space. Do not run while a package transaction is in progress.

Restore from a snapshot requires an offline environment because the @ subvolume is in use. From a rescue shell or single-user boot:

btrfs subvolume delete /
 btrfs subvolume snapshot /var/snapshots/snap-TIMESTAMP /

Replace TIMESTAMP with the chosen snapshot name. Risk: deleting the current @ subvolume is destructive. Verify the snapshot name before deletion.

Hook example placed at /usr/lib/zypp/hooks/pre-transaction.d/99btrfs-snapshot and made executable by root:

#!/bin/sh
TIMESTAMP=$(date +%Y%m%d-%H%M%S)
btrfs subvolume snapshot -r / /var/snapshots/snap-$TIMESTAMP

The hook runs as root during Zypper transactions. Log output to a file for audit. Risk: hook failure can allow a transaction to proceed without a snapshot.

Failure Modes

Disk space exhaustion. Snapshots are copy-on-write, but new writes after the snapshot consume additional space. Mitigation is monitoring with btrfs filesystem df / and pruning old snapshots with a retention policy.

Concurrent writes during restore. Restoring rewrites the @ subvolume. Mitigation is performing restores from a boot environment where no processes write to root.

Metadata inconsistency after power loss. Btrfs can leave snapshot metadata inconsistent. Mitigation is scheduling offline btrfs check during maintenance windows.

Hook failure. If the hook script errors, no snapshot is created. Mitigation is testing the hook in staging, logging output, and alerting on non-zero exit.

Snapshot sprawl. Unbounded retention increases management overhead. Mitigation is a cron job that removes snapshots older than a configured age.

Conditions That Change the Design

Large root subvolume with costly retention. If root exceeds tens of gigabytes and snapshot retention becomes expensive, limit snapshots to critical updates or move snapshots to a separate storage pool.

Need for finer rollback granularity. If per-package rollback is required, replace the single snapshot directory with per-transaction naming and integrate with distribution upgrade workflows.

Strict security policy against same-pool snapshots. If policy requires isolation, move snapshots to an encrypted external pool and adjust the hook target path.

RAID or compression use. Adjust snapshot flags and pool configuration accordingly, and verify that restore procedures respect the pool layout.

By keeping the design to two subvolumes, a single snapshot directory, and a pre-transaction hook, operators get a minimal, auditable rollback capability with clear trust boundaries and operational checks.