2

I considered incremental btrfs send/receive as a fast possibility for incremental backups. However, btrfs-receive seems to take forever in my case, which is a small change in a singe HUGE (1.5TB) file, while btrfs-send seems to retrieve and send a small differential pretty quickly.

Is this expected, since e.g. btrfs-receive needs to read a big part of the older snapshot the differential is based on, or is there a problem that could be fixed to speed it up?

2
  • What is the btrfs command you're running? Dec 18, 2016 at 21:59
  • I tried both btrfs send (-p ...) /SnapShots/current-snap | ssh root@remote-server "btrfs receive /Backups/" and the buttersink option. But eventually, I don't sink it was a btrfs issue at all. Turns out the vserver was very unstable regarding a lot of kinds of loads, especially when that remote mount was involved. by now, I canceled that backupspace and moved to a harddrive at my second place of residence.
    – mcandril
    Dec 20, 2016 at 9:06

1 Answer 1

0

Try mounting the receiver with nodatasum I would expect btrfs-receive to be faster than rsync because like git the receiver is in a guaranteed state. But it's probably double checking the file.

5
  • Or it might be a bug (btrfs RAID code is buggy) Nov 29, 2016 at 19:10
  • 1
    Looked promising, unfortunately, I have already been staring at a 80kB update for 20min :( The whole idea of my rather complicated setup (remote BTRFS is in a loop container on a mounted CIFS storage) is to not have rsync calculate checksums of the whole 1.5TB file ...
    – mcandril
    Nov 29, 2016 at 20:05
  • Sidenote: If I interrupt the process, I will have the subvolume remotely.I haven't had time to chack if the checksum of the file matches, though
    – mcandril
    Nov 29, 2016 at 20:06
  • @mcandril at a normal HDD read rate of 128MB/s a 1.5TB file would take 3.255 hours to check. What is this file? there is likely a better way of speeding that up. (like if it's a file that only grows you can just cut off the end and send that or if it's a archive/volume then operating on the contents would be faster) Nov 30, 2016 at 17:26
  • Thanks for your interest. I asked the same question with all the background at superuser recently, but didn't get any feedback, so I looked for other btrfs answers and it seems this was the better place: superuser.com/questions/1150618/… Note that I am not using buttersink anymore but pure btrfs-send/receive. In short: Checksumming locally might be fine, but remote, a rather slow backupspace is involved, where it would probably take at least a day.
    – mcandril
    Dec 1, 2016 at 14:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.