backup best practise?

backup best practise?

[Ulli Horlacher]

What is the best practise for backup of a local btrfs file system?

In my case, I have 2 disks: disk one contains a /home btrfs filesystem,
disk two contins a /backup btrfs filesystem.
So far I use:
rsync -a --delete /home /backup

The drawback of this methode is: In /home there are also *big* VMs which
will be copied every time even if they have changed only a few bytes,
because rsync works file based.

Using RAID1 is not a backup. When I inadvertently delete a file it has
gone on the mirror side, too.

I have snapshots of /home, but they will not help me if disk one has a
hardware failure.


-- 
Ullrich Horlacher              Server und Virtualisierung
Rechenzentrum TIK
Universitaet Stuttgart         E-Mail: horlacher@tik.uni-stuttgart.de
Allmandring 30a                Tel:    ++49-711-68565868
70569 Stuttgart (Germany)      WWW:    https://www.tik.uni-stuttgart.de/
REF:<20260101234624.GA1955478@tik.uni-stuttgart.de>

Re: backup best practise?

[Nicholas D Steeves]

[-- Attachment #1: Type: text/plain, Size: 3117 bytes --]

Happy New Year Ulli!

Ulli Horlacher <framstag@rus.uni-stuttgart.de> writes:

> What is the best practise for backup of a local btrfs file system?

This problem was solved pre-btrfs and it's called the "3-2-1 backup
rule".  Yes, it also applies to btrfs; however, there is some debate
about whether a snapshot counts as a "copy" when it shares extents.  My
view is that it doesn't count, because "accidental partial deletion" is
only one class of disaster.

> In my case, I have 2 disks: disk one contains a /home btrfs filesystem,
> disk two contins a /backup btrfs filesystem.
> So far I use:
> rsync -a --delete /home /backup
>
> The drawback of this methode is: In /home there are also *big* VMs which
> will be copied every time even if they have changed only a few bytes,
> because rsync works file based.
>
> Using RAID1 is not a backup. When I inadvertently delete a file it has
> gone on the mirror side, too.
>
> I have snapshots of /home, but they will not help me if disk one has a
> hardware failure.

Agreed!  It sounds like you want fast and space-efficient backups.
There's an out of date project called "backup-bench" that compares them:

  https://github.com/deajan/backup-bench

I chose borgbackup, and it is the only backup system that I've been
happy enough with to use for more than a decade.  Here is how I apply
the 3-2-1 target to my system (adapted to use your paths).  In every
case I assume a snapshot of /home is the source.

  1. Cron-automated daily backup of /home to /backup/borg-repo (where I
     return 12 days of daily snapshots).  This has saved me from a
     PSU+SSD failure once, and an SSD failure another time.
  2. Weekly backup of /home to /mnt/external-usb-on-ext4/borg-repo, that
     is a separate target.  I have 12 years of backups here, and I
     travel with this drive.  This one is unfortunately a
     prompt+clicking a button or pluging in an external disk and letting
     a udev rule initiate the backup.
  3. I use Syncthing to maintain a live mirror of my user files
     off-site, with a data-retention policy that sacrifices a bit of
     space for a margin of error in case of accidental deletion combined
     with physical disaster affecting the primary copy.  This mesh keeps
     my laptop, desktop, and an offsite server in sync.

I'm anxious about using the cloud in the impending post-quantum era so I
don't yet have quantum-computing-safe encrypted offsite cloud backup.

If you don't know about 3-2-1, here are two references:

  https://www.backblaze.com/blog/the-3-2-1-backup-strategy/
  https://www.reddit.com/r/DataHoarder/comments/1agd73m/the_321_rule_seems_to_have_multiple/

and a possible argument against 3-2-1:

  https://www.reddit.com/r/DataHoarder/comments/11bls7l/the_321_backup_recommendation_is_flawed/

I hope this is enough to upgrade your backup strategy!  I use custom
scripts for #1 and #2, but I've started working the borgmatic maintainer
about evolving borgmatic's btrfs support to the point where I can
recommend it wholeheartedly, and you can count on me to advocate for
btrfs-related borgmatic issues.

Best,
Nicholas

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 861 bytes --]

Re: backup best practise?

[Andrei Borzenkov]

02.01.2026 02:46, Ulli Horlacher wrote:
> What is the best practise for backup of a local btrfs file system?
> 
> In my case, I have 2 disks: disk one contains a /home btrfs filesystem,
> disk two contins a /backup btrfs filesystem.
> So far I use:
> rsync -a --delete /home /backup
> 
> The drawback of this methode is: In /home there are also *big* VMs which
> will be copied every time even if they have changed only a few bytes,
> because rsync works file based.
> 

The obvious answer for the btrfs is btrfs send/receive. Any reason you 
do not consider it?

> Using RAID1 is not a backup. When I inadvertently delete a file it has
> gone on the mirror side, too.
> 
> I have snapshots of /home, but they will not help me if disk one has a
> hardware failure.
> 
> 

Re: backup best practise?

[Christoph Biedl]

Heya,

Ulli Horlacher wrote...

> What is the best practise for backup of a local btrfs file system?

send/receive was already mentioned, and despite a higher cost of setting
things up I'd never want to miss the efficiency of incremental syncs.
And of course it allows remote replication as well.

> In my case, I have 2 disks: disk one contains a /home btrfs filesystem,
> disk two contins a /backup btrfs filesystem.
> So far I use:
> rsync -a --delete /home /backup
> 
> The drawback of this methode is: In /home there are also *big* VMs which
> will be copied every time even if they have changed only a few bytes,
> because rsync works file based.

A bit offtopic here, check --inplace, rsync's support for this has
improved a lot over the past years. Still, check the manpage for various
caveats.

    Christoph