You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, btrbk supports backups only to btrfs receive targets or raw stream files. There is no built-in option for performing file-level backups to non-btrfs destinations. While one could use rsyncon the latest snapshot, this requires a full filesystem scan each time and does not fully leverage the incremental capabilities of btrfs snapshots.
To address this, I propose enhancing btrbk with the following:
Use the output of btrbk diff to drive rsync, so that only changed files are scanned and transferred. This would enable true incremental file-level backups to remote or non-btrfs storage.
These changes would allow efficient, snapshot-aware file-level backups without requiring a btrfs-compatible target. Other issues that may be related: #495, #630, #474
Backgroud
I manage several Ubuntu servers and back up their root filesystems to a TrueNAS server with ZFS. Previously, with ext4 rootfs, I used rsnapshot with hard links and rsync. However, this method lacks true atomic snapshots and requires scanning all files on every run.
After migrating to btrfs for atomic snapshots, I began using btrbk. The local snapshot feature works well, but remote backup is challenging in my setup:
I cannot use btrfs send ... | zfs receive ... (hope we can one day?)
TrueNAS does not include btrfs-progs, so a btrfs receive target is not feasible.
Raw stream files stored via NFS are not directly readable and may not benefit from ZFS deduplication.
A simple rsync from the latest snapshot remains a suboptimal workaround due to full scans.
While the proposed workflow could be scripted externally, e.g. by some pipelining like ls ... | sort ... | btrfs send --no-data ... | btrfs receive --dump | grep ... | cut ... | sort ... | uniq ... | rsync ..., integrating it into btrbk would offer a more streamlined and maintainable solution. Any other suggestions or solutions are welcomed.
Currently, btrbk supports backups only to btrfs receive targets or raw stream files. There is no built-in option for performing file-level backups to non-btrfs destinations. While one could use rsyncon the latest snapshot, this requires a full filesystem scan each time and does not fully leverage the incremental capabilities of btrfs snapshots.
To address this, I propose enhancing btrbk with the following:
btrbk diffto include deleted files, potentially using an approach similar to:btrfs send --no-data -p PARENT CHILD | btrfs receive --dump(as discussed in Getting btrbk diff to show files that were moved/renamed #423).btrbk diffto driversync, so that only changed files are scanned and transferred. This would enable true incremental file-level backups to remote or non-btrfs storage.These changes would allow efficient, snapshot-aware file-level backups without requiring a btrfs-compatible target. Other issues that may be related: #495, #630, #474
Backgroud
I manage several Ubuntu servers and back up their root filesystems to a TrueNAS server with ZFS. Previously, with ext4 rootfs, I used
rsnapshotwith hard links and rsync. However, this method lacks true atomic snapshots and requires scanning all files on every run.After migrating to btrfs for atomic snapshots, I began using
btrbk. The local snapshot feature works well, but remote backup is challenging in my setup:btrfs send ... | zfs receive ...(hope we can one day?)btrfs-progs, so abtrfs receivetarget is not feasible.rsyncfrom the latest snapshot remains a suboptimal workaround due to full scans.While the proposed workflow could be scripted externally, e.g. by some pipelining like
ls ... | sort ... | btrfs send --no-data ... | btrfs receive --dump | grep ... | cut ... | sort ... | uniq ... | rsync ..., integrating it into btrbk would offer a more streamlined and maintainable solution. Any other suggestions or solutions are welcomed.