Estimated reading time: 2 minutes

In the previous post we saw how to make our system resilient “on site” using RAID and snapshot. But if the PC explodes or the server is stolen, local snapshots are useless. Today we make the leap in quality: let's learn to use Btrfs Send e Receive.

Forget rsync and its endless file scans. Con Btrfs, the backup becomes a pure data stream, transferring only the blocks that have actually changed since the last time.

1. The logic: because send/receive is better

The limitation of rsync is that it has to compare dates and sizes (o i checksum) of every single file between source and destination. If you have millions of files, you waste minutes just figuring out what to transfer. Btrfs, being a file system copy-on-write, already keeps track of every modified block. The command send extracts these differences and the “save” towards the command receive, who writes them to the destination.

Fundamental requirement: Both supports (source and destination) they must be formatted in Btrfs.

2. Practice: backup to external disk

Suppose we want to back up ours /home its a usb disk. First let's create a read-only snapshot (essential for sending):

# Crea lo snapshot di sola lettura
sudo btrfs subvolume snapshot -r /home /home/backup_temp

Now we send everything to the external disk mounted in /mnt/backup_disk:

# Il primo invio (Full Backup)
sudo btrfs send /home/backup_temp | sudo btrfs receive /mnt/backup_disk/

From next time, we can send it incremental, specifying the previous snapshot as the base. It will be a matter of milliseconds.

3. Backup remoti via SSH: maximum efficiency

This is my favorite part. We can send the data stream through an SSH tunnel. Ideal for those with fiber connections with not excessive upload, because you will only send the few MB changed during the day.

# Invia lo snapshot a un server remoto
sudo btrfs send /home/backup_oggi | ssh utente@server "sudo btrfs receive /backup/remoto"

The data arrives at its destination exactly as it left, with the integrity guaranteed by the file system's native checksums.

4. Automation: Don't do it by hand (one Btrbk)

Let's be honest: no one remembers to issue these commands every day. This is why it exists Btrbk. It's a Perl script, very light, which is configured with a simple text file in /etc/btrbk.conf.

You tell it which subvolume to monitor, how many copies to keep (this is. 7 daily, 4 Weekly) and where to send them. He takes care of creating the snapshots, do the send/receive and delete the old ones.

Quick btrbk config example:

volume /mnt/data
  subvolume home
    target send-receive /mnt/backup_esterno
    snapshot_preserve_min 2d
    snapshot_preserve 7d

5. Disaster recovery: The “boot” from the backup

What happens if the main disk dies? If you used Send/Receive on another internal or external drive, your data is already in subvolume format. You don't have to “extract” a .tar or .zip archive. Just mount the backup and, if necessary, use it like new /home simply editing /etc/fstab. It's the fastest recovery in the world.

Caution: Remember that snapshots used as the basis for incremental (the parameter -p nel send) they must exist on both sides. If you delete the snapshot “father” from the backup disk, the next incremental will fail and you will have to redo a complete send.

Conclusion

Btrfs Send/Receive transforms backup from a tedious task to an invisible, instant process. If you followed the previous guide and already have your subvolumes ready, get an old record, format it Btrfs and start to “shoot” your data. The peace of mind of knowing that your backup is a verified mirror image of your data is priceless.

You have doubts about how to configure Btrbk or how to manage SSH permissions? Write it in the comments!