btrfs send does not work for snapshots in subvolumes

[Jochen Schroeder]

If I create a snapshot, of a subvolume and try to use btrfs send it fails with "No such file or directory"

# sudo btrfs sub create /testvol
Create subvolume '//testvol'
# sudo btrfs
btrfs btrfsck btrfs-debug-tree btrfs-image btrfs-select-super btrfstune
btrfs-calc-size btrfs-convert btrfs-find-root btrfs-map-logical btrfs-show-super btrfs-zero-log
# sudo btrfs sub list /
ID 257 gen 16298 top level 5 path @
ID 276 gen 16298 top level 257 path testvol
# sudo btrfs sub snap -r /t
testvol/ tmp/
# sudo btrfs sub snap -r /testvol/ /test-snap
Create a readonly snapshot of '/testvol/' in '//test-snap'
# sudo btrfs sub list /
ID 257 gen 16299 top level 5 path @
ID 276 gen 16299 top level 257 path testvol
ID 277 gen 16299 top level 257 path test-snap
# sudo btrfs send /test-snap/ > /dev/null
At subvol /test-snap/
ERROR: open @/test-snap failed. No such file or directory

This error has been reported upstream:
https://bugzilla.kernel.org/show_bug.cgi?id=69401

Because ubuntu creates /home and / on subvolumes this currently prevents backup solutions based on btrfs send.

[KlausHoller (kholler)]

Current workaround until upstream bug is fixed (works for me):
 If you mount the btrfs root (without specifying subvol=@...) to e.g. /mnt then you can use btrfs send successfully
e.g.
btrfs subvolume snapshot -r /mnt/@ /mnt/snapshots/YYYYMMDD-HHMMSS-@
btrfs send /mnt/snapshots/YYYYMMDD-HHMMSS-@ | btrfs receive /backup
(/backup being the 2nd btrfs volume to which the snapshot shall be sent to)

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Alan Mimms (a-mimms)]

I had this problem as well, and my situation was a little more complicated to use the workaround.

My subvolume that was being snapshotted for 'btrfs send' to use was at the top of the hierarchy - there WAS no parent. But BTRFS always has a parent, so there is still a workaround.

My situation:

root@diskybiz:~# btrfs subv list /x
ID 258 gen 13525 top level 5 path home
ID 259 gen 13521 top level 5 path backups
ID 553 gen 1724 top level 5 path home/@snap-20140811-082041
ID 621 gen 13524 top level 5 path home/backup001

As you can see, the very top of the hierarchy is ID 258 or /home. I wanted to use that snapshot at ID 621 for my 'btrfs send' command. I had to determine the parent of the ID 258 subvolume, which I did by "btrfs subv show /home" and looking at the "Parent:" line. This happens to be the same as the "top level" number shown in teh "btrfs subv list", but I wasn't sure that was a subvolume ID, so I went this extra step.

Then I just mounted another mountpoint for my BTRFS filesystem like this:

root@diskybiz:~# mount -o subvolid=5 /dev/sdc1 /x

That made the root of the filesystem visible on /x. Then I could do my 'btrfs send' like so:

root@diskybiz:~# btrfs send /x/ > /root/home-backup-20141001.btrfs

I hope this helps someone.

[Goacid (goacid)]

I have the same bug, and working with btrfs and lxc containers, there is no workaround. Container can't send or reveive snapshot.

[Janne Savikko (jsavikko)]

For me Alan's workaround didn't work. But I found an another one that worked for me for sending @ and @home subvolumes (kernel bug tracker, comment 1 [0]):

1. Make directory for snapshots: "mkdir /.snapshots"
2. Take snapshot of subvolume, eg. @home: "btrfs subvolume snapshot -r /home /.snapshots/$(date -Is -u)@home"
3. Mount partition (not subvolume) with the btrfs FS: "mount /dev/sda1 /mnt/btrfs-data"
4. Send btrfs snapshot: "btrfs send /mnt/btrfs-data/.snapshots/2015-08-28T10:07:22+0000@home | btrfs receive /some-directory/"

Based on the comments of the above mentioned kernel bug tracker, this problem should have been fixed in btrfs-progs commit 8d68cb2bad0e8e7951811e0641188c447165141f [1].

References:
[0] https://bugzilla.kernel.org/show_bug.cgi?id=69401#c1
[1] http://git.kernel.org/cgit/linux/kernel/git/kdave/btrfs-progs.git/commit/?id=8d68cb2bad0e8e7951811e0641188c447165141f

[Rolf Leggewie (r0lf)]

This should be fixed in utopic and later.

Nominating for trusty SRU.