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?

Improve this question
2
  • 1
    What is the btrfs command you're running?
    – Emmanuel Rosa
    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

Reset to default
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.

Improve this answer
5
  • Or it might be a bug (btrfs RAID code is buggy)
    – user1133275
    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)
    – user1133275
    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

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .