Snapshot Management

Snapshot Management

A snapshot is a point-in-time copy of a filesystem or volume created almost instantly by the storage layer. Unlike a full backup (which copies all data), snapshots use copy-on-write: they only record what changes after the snapshot is taken. This makes them extremely fast to create (seconds) and cheap to store when files change slowly. Snapshots are ideal before risky operations like system upgrades or database migrations — if something goes wrong, rollback is instant.

What are snapshots?

Copy-on-write snapshot mechanism:
  Time 0: Take snapshot of Volume (100GB of blocks)
  Snapshot created instantly — no data copied yet

  Time 1: A 5MB file is modified
    Original blocks copied to snapshot area (5MB)
    New data written to live volume
    Snapshot still references original blocks

  Space used by snapshot = only changed data (5MB, not 100GB)

  To restore: swap references back — instant regardless of volume size

LVM snapshots

# Check current LVM setup:
sudo lvdisplay
sudo vgdisplay    # Note free space in volume group (needed for snapshot)

# Create a snapshot of /dev/ubuntu-vg/ubuntu-lv (10GB snapshot space):
sudo lvcreate -L10G -s -n ubuntu-lv-snap /dev/ubuntu-vg/ubuntu-lv

lvcreate snapshot output

Logical volume "ubuntu-lv-snap" created.

# Mount the snapshot read-only to access point-in-time files:
sudo mkdir -p /mnt/snapshot
sudo mount -o ro /dev/ubuntu-vg/ubuntu-lv-snap /mnt/snapshot
ls /mnt/snapshot/etc/nginx/    # Browse pre-change state

# Take a backup from the snapshot (consistent filesystem state):
sudo rsync -avh /mnt/snapshot/var/www/ /backup/www-$(date +%Y%m%d)/

# Remove the snapshot when done:
sudo umount /mnt/snapshot
sudo lvremove /dev/ubuntu-vg/ubuntu-lv-snap

⚠️ WARNING: LVM snapshots consume space as the original volume changes. If the snapshot area fills up (100%), the snapshot becomes invalid. Use a snapshot size that covers expected changes for the duration you need the snapshot, and remove snapshots when done.

Btrfs snapshots

# Btrfs has native snapshot support — no separate snapshot area needed
# Check if filesystem is Btrfs:
df -T /

# Create a read-only snapshot:
sudo btrfs subvolume snapshot -r / /snapshots/root-$(date +%Y%m%d)

# List snapshots:
sudo btrfs subvolume list /

# Delete old snapshot:
sudo btrfs subvolume delete /snapshots/root-20250601

# Roll back by booting from a snapshot (modify /etc/fstab to mount snapshot as root)
# Or copy files from snapshot directly:
ls /snapshots/root-20250609/etc/nginx/

Cloud disk snapshots

# AWS EBS snapshots (incremental, stored in S3):
# Create snapshot via AWS CLI:
aws ec2 create-snapshot --volume-id vol-0abc123 --description "Pre-upgrade $(date +%Y-%m-%d)"

# List snapshots:
aws ec2 describe-snapshots --owner-ids self

# Restore: create volume from snapshot, detach original, attach new
# GCP disk snapshots:
gcloud compute disks snapshot my-disk --snapshot-names=my-disk-snap-$(date +%Y%m%d)

# Automate with lifecycle policies (AWS):
# DLM (Data Lifecycle Manager) can create and delete snapshots on a schedule

Conclusion

The key snapshot rule: take a snapshot before, not after, a risky operation. Before a major apt upgrade, a database migration, or any change you want the ability to roll back. LVM snapshots work well on physical servers and VMs; cloud disk snapshots are built into every major cloud provider and should be automated with lifecycle policies. Remember that a snapshot is not a substitute for an offsite backup — if the disk fails, the snapshot is lost with it.