Send Btrfs Snapshots with btrfs send, Full or Incremental

Use btrfs send to turn a read-only snapshot into a stream you can save or pipe to another Btrfs filesystem. You can send the whole snapshot, or only what changed since an earlier one. Allow 10 to 30 minutes for a first test, plus however long the data takes to move.

The stream can go to a file or straight into btrfs receive on the destination. Either way, the source snapshot is only read, never changed.

1. Check the command and choose the snapshots

This guide uses the installed btrfs-progs 6.6.3 command. It assumes the source filesystem is mounted and you already have snapshots at paths such as /btrfs/snapshots/home-2026-09-22.

• The snapshot must be read-only. A read-only mount is not enough: Btrfs send needs the snapshot itself to stay read-only.
• No writable route in. The same subvolume must not be writable through another mount while the send runs.

$ btrfs --version
btrfs-progs v6.6.3
$ btrfs subvolume show /btrfs/snapshots/home-2026-09-22

The second command is an inspection step. Its output is host-specific, but it should identify a Btrfs subvolume. If it fails, stop and correct the path before attempting a send.

2. Make a full stream for the first transfer

A full send contains the entire snapshot data and metadata. Give the output a new name so an existing backup cannot be silently replaced. The -f option writes the stream to a file instead of standard output.

$ snapshot=/btrfs/snapshots/home-2026-09-22
$ stream=/var/backups/btrfs/home-2026-09-22.full.stream
$ test ! -e "$stream" || { printf 'refusing to overwrite %s\n' "$stream" >&2; exit 1; }
$ btrfs send -f "$stream" "$snapshot"
$ printf 'send exit status: %s\n' "$?"
send exit status: 0
$ test -s "$stream" && wc -c < "$stream"
1843200

The byte count is illustrative: your stream will differ with the snapshot contents. A successful command returns status 0 and creates a non-empty stream. The stream is binary, so do not inspect it in a text editor.

3. Receive the full stream on the destination

Copy the stream to a directory on the destination Btrfs filesystem, then pass it to btrfs receive. The destination argument is a mounted directory, not a device path. Receiving creates the sent subvolume, so pick a directory where that name is expected and where you have enough free space.

destination=/srv/btrfs-receive
test -d "$destination" && mountpoint -q "$destination"
btrfs receive "$destination" < /var/backups/btrfs/home-2026-09-22.full.stream
printf 'receive exit status: %s\n' "$?"
receive exit status: 0

The mountpoint check stops you feeding a stream into an ordinary directory on the wrong filesystem.

4. Send only the changes from a parent snapshot

Once the first snapshot has been received, an incremental send can use it as the parent. Three conditions:

• Both snapshots are read-only. That means the parent and the new one.
• The parent exists on both sides. It must be present on sender and receiver, in the corresponding state.

$ parent=/btrfs/snapshots/home-2026-09-22
$ current=/btrfs/snapshots/home-2026-09-23
$ stream=/var/backups/btrfs/home-2026-09-23.incremental.stream
$ test ! -e "$stream" || { printf 'refusing to overwrite %s\n' "$stream" >&2; exit 1; }
$ btrfs send -p "$parent" -f "$stream" "$current"
$ printf 'send exit status: %s\n' "$?"
send exit status: 0
$ test -s "$stream" && wc -c < "$stream"
245760

This stream describes the changes from parent to current. It is not a self-contained replacement for the full stream. Receive it on the destination where the matching parent snapshot already exists. If the parent is missing, was changed, or is not the same snapshot state, the incremental workflow cannot rebuild the intended result.

5. Use clone sources only when both sides match

The -c option supplies an additional snapshot that Btrfs can use as a clone source. It can shrink the data an incremental stream carries, and you can repeat it. It is also a sharp edge: every clone source must be in exactly the same state on sender and receiver.

$ btrfs send -p "$parent" -c /btrfs/snapshots/home-2026-09-15 \
    -f "$stream" "$current"

6. Choose protocol and diagnostic options deliberately

The default send protocol is version 1. Protocol 2 encodes file data more efficiently and is required for --compressed-data. It needs at least btrfs-progs 6.0 on both ends and Linux 6.0 on the sender. Passing --proto 0 asks for the highest version the running kernel supports, so use it only when you know the receiver can cope.

$ btrfs send --proto 2 -f "$stream" "$current"
$ btrfs send --compressed-data -f "$stream" "$current"
$ btrfs send --no-data "$current" > metadata-only.stream

• --compressed-data can keep filesystem-compressed data as it is in the stream, but still needs protocol 2 or higher.
• --no-data deliberately omits file data. It cannot transfer the snapshot; it is for inspecting metadata differences, not for a restorable backup.
• -v gives readable generated-command diagnostics.
• -q suppresses non-error messages, which suits scripts.

7. Diagnose failures without harming your source

A non-zero status means the send failed. Work through these checks:

• Paths and permissions. Check the snapshot paths and read permissions.
• Space. Check free space for a file output.
• Read-only flags. Confirm every involved snapshot is read-only.
• Parent. For an incremental send, verify the parent is the intended earlier snapshot.
• Clone sources. Verify exact identity on both sides rather than retrying with more options.

$ test -r "$parent" && echo parent-readable
parent-readable
$ test -r "$current" && echo current-readable
current-readable
$ btrfs subvolume show "$parent" | sed -n '1,12p'
$ btrfs subvolume show "$current" | sed -n '1,12p'