I am planing to backup data via sending btrfs snapshots to an online storage. The storage is mounted as a LUKS encrypted container file on a cifs share.

Later transfers will be reasonably fast, but for the first one is 1,3TB, which, when I use tc to leave me with a reasonable amount of upstream, will take 23 days. Now, in theory, my connection could handle that, but reconnections are possible. As far as I understand, this would force me to start all over again, if I just use

 btrfs send ... | btrfs receive ...

Is there any save, that is, resumable way to do this? I found buttersink, but it only seems to allow resume for S3.

Any ideas?

Feel free to use the comments to suggest a completely different solution. It is a Hetzner Storagebox (https://www.hetzner.de/de/hosting/storagebox/bx40). I have FTP, FTPS, SFTP, SCP (but not SSH and paramiko also doesn't work), Samba/CIFS, HTTPS, WebDAV access. The storage is not to be trusted with the unencrypted data. Free space on both sites is not excessive. There will be lots of changing smaller files, so duplicity without a regular full backup (that would take a month again) does not seem to be feasible. For the same reason, rsync would most likely be slow when comparing the local version with the one locally mounted from remote. EncFS seems to be unsave, since the other side will potentially be able to gather multiple versions of a single file over time.


2 Answers 2


btrbk supports:

Resume of backups (if backup target was not reachable for a while)

buttersink supports:

local btrfs file systems, remote btrfs file systems over SSH, or S3 buckets.

Or you can do it manually:

  1. Instead of writing to a shell pipe via stdout, use the -f option to write send's data to a file:
    btrfs send -f outfile
  2. Use your favourite resumable tranfer method (eg rsync) to transfer the file
  3. Use btrfs receive -f outfile to read the data from outfile instead of from stdin
  • what if the scenario is as follows: unix.stackexchange.com/questions/362395/…
    – ceremcem
    Commented May 1, 2017 at 9:54
  • What about the raw target (man btrbk.conf) and rsync?
    – Tom Hale
    Commented May 2, 2017 at 5:31
  • 1
    That will use twice the snapshot size. Same problem.
    – ceremcem
    Commented May 3, 2017 at 22:31
  • btrbk's resume will first delete the subvol/snapshot and re-send it. It doesn't resume a partially-transferred snapshot.
    – Geremia
    Commented Apr 2 at 21:48

As I understand it, your remote storage is exposed as a filesystem. I don't use btrfs myself but I assume the snapshots are equivalent to one large "full backup" file followed by a number of smaller "incremental" files.

On that basis I'd still go with rsync because it's restartable. You can't use its snazzy delta differences algorithm unless there's an rsync server available on the remote host, but you can tell rsync to assume the source file hasn't changed and to continue after a break from the byte offset it had reached:

test -t 2 && progress=--progress
rsync -av $progress --partial --append --sparse /path/to/source.img /path/to/remote/storage/

If you can usefully gzip your source file before transferring it, do so. (Neither --rsyncable nor rsync -z is relevant for what rsync sees as a local to local file transfer.)

  • Thanks for the suggestion, but your idea von btrfs is not accurate. A snapshot is basically a (in this case) read-only copy of the current filesystem, that does not take any space initially. Only differences are later written to the disk. Because of that, it is very easy to determine what to transfer for an incremential update. Especially, all the information is cheaply available in the source FS, which is good because reading the target is very slow compared to the size of the data. This also more or less also rules out plain rsync, because it would take forever to figure out the differences.
    – mcandril
    Commented May 27, 2016 at 15:39
  • Also, any compression will not work, since a) i cannot run code on the target, so decompression happens on my machine again and b) the remote machine is not trustworthy and may only see encrypted data, which is not compressible.
    – mcandril
    Commented May 27, 2016 at 15:40
  • @mcandril so these btrfs snapshots are like lvm filesystem snapshots? (You get to see a snapshot of the filesystem from an instant in time.) I still don't see why plain rsync isn't sufficient then. Regarding compression, why not compress and then encrypt? (But if compression isn't useful, then don't compress. Just like I warned in the last paragraph of my answer.) Commented May 27, 2016 at 15:43
  • If you meant to do this just for the first transfer, then you are right. Technically, my question ruled that out, because one of the preconditions was low lokal space, so I could not have the img locally first, but I made that space by now. Actually I already wrote a comment about that, and about using rsync for the first transfer, but I got delete in the course of the discussion with someone who vastly misunderstood the question and got snappy.
    – mcandril
    Commented May 27, 2016 at 15:45
  • 2
    BTW, compression before encryption is already active as a feature of BTRFS. Didn't explicitly think of that until now, but it is good to keep in mind :)
    – mcandril
    Commented May 27, 2016 at 15:47

You must log in to answer this question.

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