@sgallagh and I briefly discussed how to provide "a properly-integrated and easy to configure backup solution".

• Fedora Workstation (source) to Fedora Server (destination)
  • Btrfs on the source can be a prerequisite so long as the solution is broadly useful, easy to configure, reliable, and likely to be used.
  • Configuration is likely to be limited to enabled/disabled, choosing the destination to hold the backups, backup frequency and timing, and error handling/notifications.
  • Advantage of destination having Btrfs is, it's easy to restore single files from the backup: sshfs, NFS, SMB, rsync.
  • Bonus: it can be any Fedora to any Fedora. e.g. either one way, or mutual backups.
• Fedora to any block device
  • Straightforward to depend on Btrfs for both source and destination.
  • Many other solutions in this space, how does this one compete?
  • Unquestionably makes it more "likely to be used" than requiring a 2nd Fedora system.

Summary of btrfs send/receive function:

• smallest granular unit is the subvolume snapshot (must be a read-only snapshot)
• btrfs send creates a metadata+data stream of a subvolume snapshot, or the difference between two snapshots
• btrfs send -p used to produce an incremental stream of the difference between two snapshots.
• btrfs receive accepts a stream and creates a subvolume snapshot from it; if it's an incremental send, the parent subvolume snapshot must already yexist on the source and destination
  • cheap to compute incremental stream: requires no deep traversal on either the source or destination; e.g. change a single 1MiB file in a 20T filesystem, the stream will be at most 1MiB and take a few seconds to compute without needing to first communicate with the destination.
  • when moving or renaming large numbers of files, the incremental stream functionally contains just 'mv' commands to move/rename them upon being received
• source file system must be btrfs
• destination file system needs to be btrfs to receive and create subvolume snapshots; but a non-btrfs file system can accept and store the send stream as a file; a few changes to the backup/restore strategy are indicated. i.e. an incremental send file can't stand alone, whereas a received incremental send processed by btrfs receive creates a complete stand alone subvolume snapshot.

Btrfs send/receive is going to get an overhaul to support btrfs/fscrypt work that's in progress (native encryption using the kernel's fs/crypto API). Possible changes:

• support both compressed and encrypted streams
• add checksumming to the data stream
• bonus: authentication won't be required to backup encrypted subvolumes

Various questions:

• Is there a role for systemd-homed? User-level backup preferences/configuration isn't accessible in an encrypted /home or ~/ - but the sd-homed might be able to contain this information in the unencrypted user record?
• Is there a tie in with snapper? Are there possible conflicts? The plus side of cheap snapshots is, they can each create and manage their own snapshots, and put them wherever they want.
• Rentention policy default? Configurable?
• What to backup?
  • Just /home or ~/ ?
  • Option to backup everything?
  • Option that shows subvolumes, and make them user selectable?
• Server side option could include a deduplication agent; e.g. bees.

Project references:

man btrfs subvolume
man btrfs send
man btrfs receive

btrbk - backup tool for btrfs subvolumes

bees - deduplication agent