Learn Linux Filesystem - Snapshots, Backup & Replication

#Introduction

Data corruption and deletion can happen at any time — from bugs, human error, or ransomware attacks. The main shield isn't the filesystem, it's snapshots and backups. Snapshots give you a recovery timeline; backups ensure that timeline survives the physical loss of a disk.

Episode 9 covers snapshots on all four filesystems. For ext4 and XFS, which write in place, snapshots need help from LVM or fs-freeze. For btrfs and ZFS, which are Copy-on-Write, snapshots are nearly instant and cheap. Then we cover replication with btrfs send/receive and zfs send/receive to an offsite location.

The golden rule to remember throughout this episode: a snapshot is not a backup. A snapshot shares physical blocks with the original data — if the disk fails, both are lost together.

#Snapshots on Non-COW Filesystems

#LVM Snapshots for ext4 and XFS

LVM (Logical Volume Manager) provides snapshots at the block level: when a snapshot is taken, LVM copies the old blocks before they're overwritten. This is the standard way to photograph ext4 or XFS:

sudo lvcreate -L 1G -s -n snap-data /dev/vg0/lv-data
sudo mount /dev/vg0/snap-data /mnt/snap

An LVM snapshot needs extra space to hold the changes since it was taken — if it fills up, the snapshot becomes invalid. Give it a sufficient size and monitor it with lvs.

#fs-freeze for Consistency

For a snapshot to be consistent, the filesystem must be quiescent. fsfreeze temporarily freezes writes:

sudo fsfreeze --freeze /mnt/data
sudo lvcreate -L 1G -s -n snap-frozen /dev/vg0/lv-data
sudo fsfreeze --unfreeze /mnt/data

The fsfreeze --freeze command forces the journal and buffers to finish before the snapshot is taken — mandatory for consistency-sensitive databases. Without a freeze, a snapshot can contain half-written files.

#COW Snapshots: btrfs and ZFS

#btrfs Snapshots

On btrfs, a snapshot doesn't copy anything — it just points to the same blocks:

sudo btrfs subvolume snapshot -r /mnt/lab/data /mnt/lab/@backups/data-$(date +%F)
sudo btrfs subvolume list /mnt/lab

The -r option creates a read-only snapshot that's safe as a restore point. Because of COW, creating it takes zero space — space only grows when the original blocks change.

#ZFS Snapshots

ZFS snapshots follow the pool/dataset@label pattern:

sudo zfs snapshot labpool/data@hari-$(date +%F)
zfs list -t snapshot

ZFS and btrfs snapshots give you much tighter backup frequency — even every hour is no problem. This power is why COW filesystems outperform ext4/XFS for data protection.

#Incremental Replication

#Incremental btrfs send/receive

btrfs send produces a stream of changes. For incremental, give a baseline snapshot with -p:

sudo btrfs send -p /mnt/lab/@backups/data-minggu1 \
  /mnt/lab/@backups/data-minggu2 | ssh remote \
  "sudo btrfs receive /mnt/backup"

-p means parent snapshot — only the differences since the parent are sent. After receive, verify on the remote side with btrfs subvolume list.

#zfs send/receive Replication Streams

ZFS uses zfs send -i for incremental and zfs receive on the receiving side:

sudo zfs snapshot -r labpool@penuh
sudo zfs send -R labpool@penuh | ssh remote "sudo zfs receive backup"
sudo zfs snapshot labpool@inkremental
sudo zfs send -R -i labpool@penuh labpool@inkremental | ssh remote "sudo zfs receive backup"

-R sends all descendant datasets, -i states the difference from a previous snapshot. The -R -i combination is the truly production-grade full replication pattern.

#An Alternative Without SSH: Netcat

For trusted networks and maximum throughput, streams can be sent directly via nc without encryption:

sudo zfs send labpool/data@snap | nc -q 0 backup-host 9000

An important note: netcat streams are not encrypted — only use them on private networks or over VPN. For public paths, stick with SSH.

#A Healthy Backup Strategy

#The 3-2-1 Combination and Local Snapshots

A healthy backup combines local snapshots, a remote replica, and removable media:

• 3 copies of the data: production, local snapshot, and remote replica.
• 2 different media: local disk and offsite storage.
• 1 copy off-site to survive a building-level disaster.

Local snapshots handle small mistakes (deleted files, failed updates). Remote replicas handle big scenarios (dead disks, fire). Both have different roles and can't replace each other.

#Automation and Verification

Manual replication is bound to be forgotten. Schedule it in cron or a systemd timer, and verify periodically with test restores:

0 2 * * * sudo zfs snapshot labpool/data@auto-$(date +\%F)
15 2 * * * sudo zfs send -R -i labpool/data@auto-$(date +\%F --date=yesterday) \
  labpool/data@auto-$(date +\%F) | ssh remote "sudo zfs receive backup"

A backup that's never been tested isn't a backup — test a restore at least once a month.

#Conclusion

Snapshots and replication are two sides of the same data protection coin. Snapshots give recovery speed; replication gives geographic resilience. For ext4/XFS, both require LVM and discipline; for btrfs and ZFS, both are nearly free thanks to COW.

Key takeaways:

• A snapshot is not a backup — they share physical blocks.
• ext4/XFS need LVM snapshots and fsfreeze for consistency.
• btrfs and ZFS make COW snapshots nearly instant with no data copy.
• btrfs send -p and zfs send -R -i are the official incremental patterns.
• Replication streams can be sent via ssh (secure) or netcat (fast, unencrypted).
• Schedule automation and test restores regularly.

In the next episode, episode 10, we cover filesystems for special workloads — how to choose a filesystem for databases, containers and VM images, media file servers, and root filesystems. You'll see why no single filesystem is perfect for every workload.