Btrfs Snapshot Recovery

What It Is

Using Btrfs filesystem snapshots to instantly roll back system state to a previous point in time. Snapshots are copy-on-write, space-efficient, and can be made bootable.

Why It Matters

Traditional backups require:

• Time to restore (hours)
• External storage
• Complex recovery procedures
• Possible data loss

Btrfs snapshots provide:

• Instant rollback (minutes)
• No external storage needed
• Simple mount and chroot
• Zero data loss

Critical for experimental systems, package updates, and configuration changes.

Real-World Example

System became unbootable after a binhost sync attempt - audio broken, cloud sync failed, sudo authentication failed. Rather than spend hours debugging a broken system, snapshot rollback restored a working state in 10 minutes:

1. Booted recovery environment
2. Mounted snapshot from the previous day
3. Verified functionality in chroot
4. Made snapshot the default subvolume
5. Rebooted into working system
6. Investigated root cause with time and a working system

Recovery Procedure

Step 1: Boot Recovery Environment

Boot from USB, live CD, or another installation on the same system.

Step 2: Mount and List Snapshots

# Mount root filesystem
mount /dev/sdXn /mnt

# List snapshots
btrfs subvolume list /mnt | grep snapshot

Step 3: Mount Specific Snapshot

# Unmount and remount with snapshot
umount /mnt
mount /dev/sdXn /mnt -o subvol=@snapshots/171/snapshot

Step 4: Prepare Chroot

# Bind mount critical filesystems
mount --bind /dev /mnt/dev
mount --bind /proc /mnt/proc
mount --bind /sys /mnt/sys

# Enter snapshot
arch-chroot /mnt

Step 5: Test Functionality

# Test basic functionality
rc-status         # Check services (OpenRC)
ping 8.8.8.8      # Check network
emerge --info     # Check Portage

Step 6: Make Snapshot Default

# If everything works, make this snapshot the default
btrfs subvolume list / | grep "171/snapshot"  # Get ID
btrfs subvolume set-default <ID> /

Step 7: Reboot

exit
umount /mnt/{dev,proc,sys}
umount /mnt
reboot

Snapshot Strategy

When to Snapshot

• Before system updates - Always
• Before configuration changes - Always
• Before package installations - Automatic with hooks
• After achieving stable state - Manual milestone
• Daily automated snapshots - Background safety net

Snapshot Retention with Snapper

# /etc/snapper/configs/root
TIMELINE_MIN_AGE="1800"
TIMELINE_LIMIT_HOURLY="10"
TIMELINE_LIMIT_DAILY="10"
TIMELINE_LIMIT_WEEKLY="0"
TIMELINE_LIMIT_MONTHLY="10"
TIMELINE_LIMIT_YEARLY="0"

Pre-Update Snapshot Hook

#!/bin/bash
# Always snapshot before updates

snapper create --description "Before $(date +%Y-%m-%d) update"
echo "Snapshot created: #$(snapper list | tail -1 | awk '{print $1}')"

# Proceed with update
emerge -avuDN @world

# If update fails, boot rescue and rollback to snapshot

Key Points

• Snapshots are space-efficient (only store changes)
• Can snapshot any subvolume instantly
• Bootable - can be made default subvolume
• Multiple snapshots maintained simultaneously
• Fast - no data copying needed for creation

Comparison to Traditional Backup

Feature	Snapshot	Traditional Backup
Speed	Instant	Hours
Storage	Same disk	External
Restore Time	Minutes	Hours
Granularity	Per-second	Per-day
Space Overhead	Minimal	Full copy

Snapper Commands

# List all snapshots
snapper list

# Create manual snapshot
snapper create --description "Before risky change"

# Compare snapshots
snapper status 50..51

# Show changes between snapshots
snapper diff 50..51

# Rollback to snapshot
snapper rollback 50

# Delete old snapshots
snapper delete 42

Btrfs Subvolume Layout

A typical Argo OS installation uses this layout:

/dev/nvme0n1p7 (Gentoo root)
├─ @              → /
├─ @home          → /home
├─ @snapshots     → /.snapshots
├─ @var-cache     → /var/cache (excluded from snapshots)
└─ @var-log       → /var/log (excluded from snapshots)

Mount options: compress=zstd:3,noatime,subvol=@

GRUB Integration

With snapper’s grub-btrfs helper, snapshots appear in the GRUB boot menu:

• Boot → Advanced Options → Select any snapshot
• System boots read-only into that snapshot
• Can then make it writable and permanent

Limitations

• Snapshots are on the same disk - don’t protect against hardware failure
• Need external backups for disaster recovery
• Large file changes (VMs, databases) can bloat snapshot storage
• Not a replacement for backups - complements them

Related Concepts

• Btrfs - The underlying filesystem technology
• Snapper - Snapshot management tool
• System Recovery - General recovery strategies