Sorry for answering so late. I compiled a more recent (v5.9) version of
btrfs-progs first.
The unpacking/receiving took about 2 days on the raspberry.
$ nohup btrfs receive -v -f splitter . &
$ tail -n1 nohup.out
ERROR: short read from stream: expected 49233 read 44997
thanks to your -v suggestions I got a little bit more information.
first I figured the files on the local and remote host are not the same,
by md5sum.
So I will solve this issue first. Is there any recommended way to
transfer btrfs subvolumes over an unstable connection?
Am 17.01.21 um 13:07 schrieb Chris Murphy:
On Sun, Jan 17, 2021 at 11:51 AM Anders Halman <[email protected]> wrote:
Hello,
I try to backup my laptop over an unreliable slow internet connection to
a even slower Raspberry Pi.
To bootstrap the backup I used the following:
# local
btrfs send root.send.ro | pigz | split --verbose -d -b 1G
rsync -aHAXxv --numeric-ids --partial --progress -e "ssh -T -o
Compression=no -x" x* remote-host:/mnt/backup/btrfs-backup/
# remote
cat x* > split.gz
pigz -d split.gz
btrfs receive -f split
worked nicely. But I don't understand why the "received uuid" on the
remote site in blank.
I tried it locally with smaller volumes and it worked.
I suggest using -v or -vv on the receive side to dig into why the
receive is failing. Setting the received uuid is one of the last
things performed on receive, so if it's not set it suggests the
receive isn't finished.
