Using mbuffer to speed up slow zfs send | zfs receive – EveryCity | Managed Hosting Services

This is an awesome bit of advice! I just sped up a zfs send that was crawling along at 60Mbps to over 600Mbps … I’m so stoked!

zfs send -i data/filesystem@1 data/filesystem@2 | mbuffer -s 128k -m 1G -O 10.0.0.1:9090

via Using mbuffer to speed up slow zfs send | zfs receive – EveryCity | Managed Hosting Services.

Advertisements

2 thoughts on “Using mbuffer to speed up slow zfs send | zfs receive – EveryCity | Managed Hosting Services

  1. Hi again :), For the sake of learning I set up 2 VBox FreeBSD 8.2 with ZFSonRooT (hostname “primary” and “backup”). The idea is to simulate a full hardware failure and recovery using ZFS. Machine “primary” has 1 pool called “zroot” (OS) and machine “backup has “zroot” (OS) and “primary”. The idea is to send all data to the “primary” pool on machine “backup” from machine “primary”. After the machines are up, I populate the “primary” machine with some data, create a snapshot with zfs snapshot -r zroot@1 and send it to the “backup” machine (“primary” pool) via zfs send -R zroot@1 | ssh root@backup.local zfs receive -dF primary. The problem is that after transferring the snapshot, the datasets get mounted automatically and because the snapshot is of the “zroot” pool from machine “primary” it overwrites the “zroot” pool from machine “backup”. I guess I’m missing something and I need a hand in finding out what.

    • Please try experimenting with the ‘-n’ switch to get your recv command correct.

      Well, at first glance your commands appear reasonable for a first snapshot. For my first snapshot of a volume, this seems to work well for me:
      root@primary# zfs send -R -i zroot@1 | ssh root@backup zfs recv -n -vF primary

      I am not interested in mounting my filesystem root. You might have better luck making your machine primary actually boot from a volume and not the root of the filesystem. So if you created zroot/root and set ‘mountpoint=/’ that would make your commands a bit more deterministic:
      root@primary# zfs send -R -i zroot/root@1 | ssh root@backup zfs recv -n vFe primary

      …and also allow you to have separate volumes in zroot for other possible purposes.

      For subsequent shapshots, this works better, as I should not need to use the -F switch:
      root@primary# zfs send -I @1 zroot/root@2 | ssh root@backup zfs recv -ve primary

      Also, destination volumes for zfs snapshots should be marked ‘readonly=yes’, and possibly even ‘exec=no’ and ‘canmount=no’ to prevent accidents on the backup node. If your snapshots are more than a few megs worth, consider tuning the backup volume with ‘logbias=throughput’ to encourage streaming right to storage.

Comments are closed.