How to copy a btrfs filesystem

backupbtrfs

How can make a full copy of the contents of a btrfs filesystem?
By full copy I mean not only the current data, but also different subvolumes with their snapshots, ideally preserving their CoW structures (i.e.: not duplicating blocks with the same content.

It seems a block-level copy (such as with dd) is not a good idea, since it duplicates the UUID, and there isn't a way to easily change it, apparently.

Best Answer

Option 1 - Dumb data copy then change UUID

Ensure that source partition is unmounted and will not be automounted.

Use either dd (slow, dumb) or partclone.btrfs -b -s /dev/src -o /dev/target

Use btrfstune -u to change UUID after copy and before mounting.

Data loss warning: Do NOT try to (auto)mount either original or copy until the UUID has changed

Option 2 - `btrfs-clone`

I have not personally tried btrfs-clone, but it purports to clone an existing BTRFS file system to a new one, cloning each subvolume in order.

Related Solutions

Linux – partitioning and subvol strategy with btrfs

If you don’t have specific needs, use btrfs as you would use another filesystem. Separating /home is a good practice.

Personally, on home servers my only subvolume is /etc, so I can make snapshots of the configurations. This can be automated with tools like snapper.

Usually, there is little interest of restoring just a previous version of /var, because of the need to also restore /lib/stuff. It is an all-or-nothing situation.

Snapshots of /home can be VERY big, so the disk size management is soon a problem. It can be done without any problem, but keep an eye on the remaining space. Also, as snapshots can only be made on the same disk, they are not a solution for backups in case of disk failure. Think of them as something for the situations like "oups, I deleted this file two hours ago, but I still need it".

Bonus 1 : none. In fact, btrfs was designed in order to simplify the stack mdadm+lvm+fs. So it is really better to avoid it.

Bonus 2 : No, but make a RAID 1! Simple and efficient, your data will love you :)

Ninja bonus : you really probably want to have a good look at the btrfs wiki.

Linux – Mirror / backup laptop btrfs drive to sometimes connected external USB disk

Maybe using Btrfs send / receive could be made to work, but it is not so simple, because to send a filesystem, a read only snapshot must first be made, and then the name of this snapshot is used on the external disk. I don't think there is a way to receive the root filesystem, at /

This is the best solution. I use snapshots to make fast incremental backups of my servers. You can back up the root subvolume just like any other, but I don't think you can receive at the root. More to the point, you shouldn't do so, because that prevents you from enjoying one of the benefits of snapshotting: incremental backups. Done properly, it will only send the data that has changed and consume only the disk space for the changed data.

This script runs as a cron job and takes a daily snapshot of my root partition, then uses btrfs send to send an incremental copy to my backup partition. The script as written uses pv, but if for some reason you don't want to install it, you can simply remove pv from the middle of the pipes.

#!/bin/bash
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
date=$(date +%Y-%m-%d)

# the path to the partition mount point that we are backing up
source_partition=/

# where backup snapshots will be stored on the local partition
# this is needed for incremental backups
source_snapshot_dir=/snapshots

# where backups will be stored on the backup drive
target_snapshot_dir=/mnt/media/backups/root

if [ ! -d $source_snapshot_dir ]; then
    echo 'Creating initial snapshot...'
    mkdir --parents $source_snapshot_dir $target_snapshot_dir

    # create a read-only snapshot on the local disk
    btrfs subvolume snapshot -r $source_partition $source_snapshot_dir/$date

    # clone the snapshot as a new subvolume on the backup drive
    # you could also pipe this through ssh to back up to a remote machine
    btrfs send $source_snapshot_dir/$date | pv | \
        btrfs receive $target_snapshot_dir
elif [ ! -d $source_snapshot_dir/$date ]; then
    echo 'Creating root volume snapshot...'

    # create a read-only snapshot on the local disk
    btrfs subvolume snapshot -r $source_partition $source_snapshot_dir/$date

    # get the most recent snapshot
    previous=$(ls --directory $source_snapshot_dir/* | tail -n 1)

    # send (and store) only the changes since the last snapshot
    btrfs send -p $previous $source_snapshot_dir/$date | pv | \
        btrfs receive $target_snapshot_dir
fi

echo 'Cleaning up...'

# keep the 3 most recent snapshots on the source partition
ls --directory $source_snapshot_dir/* | \
    head --lines=-3 | \
    xargs --no-run-if-empty --verbose \
    btrfs subvolume delete --commit-after

# keep the 28 most recent snapshots on the backup partition
ls --directory $target_snapshot_dir/* | \
    head --lines=-28 | \
    xargs --no-run-if-empty --verbose \
    btrfs subvolume delete --commit-after

(Note: I've adapted the script somewhat to make it into a general solution, and haven't tested it as written. Please feel free to submit revisions if necessary.)