Multiple targets with different run frequencies

[mfr-itr]

I have two volumes, btr_pool on a ssd and backup on a hdd. The server is in a living room so I want to keep the HDD usage as low as possible, which means a backup at 3am only. I also want to keep local hourly snapshots on the SSD. I run this config with an hourly cron:

timestamp_format        long-iso
preserve_hour_of_day    3
preserve_day_of_week    monday

snapshot_create         onchange
snapshot_preserve       30h 15d
snapshot_preserve_min   24h

target_preserve         35d 5w *m
target_preserve_min     no

lockfile                /run/btrbk.lock

volume /mnt/btr_pool
  snapshot_dir snapshots

  subvolume @
    target send-receive /mnt/backup/snapshots

  subvolume @home
    target send-receive /mnt/backup/snapshots

I thought the backup would only run daily, but the HDD wakes up hourly. My current workaround is to have an hourly btrbk snapshot and a daily btrbk. I added the lockfile by fear of a race condition. It seems to work correctly, but is there a better way?

[ghost]

That is how I do it too; separate snapshot and backup config files. One advantage is that snapshots keep going even if backup target is not reachable .

[digint]

Sorry for the late reply, I missed that one...

I thought the backup would only run daily, but the HDD wakes up hourly.

Every time you run btrbk, it checks the target if the target_preserve conditions are met. So even if there is no send/receive to the target (which is done daily with your setup), it will still wake up.

My current workaround is to have an hourly btrbk snapshot and a daily btrbk.

Sounds correct, although I would suggest to run a daily btrbk resume (which skips the snapshotting step, in order to logically split "hourly snapshot" and "daily backup").

As @Gatak noted you could also have separate config files (a common setup used for remote servers when pulling backups), but for your use case this might be overkill.

I added the lockfile by fear of a race condition.

In this case a lockfile is not really needed, as snapshotting is atomic. If btrbk resume is started while btrbk snapshot is running, the difference would be:

• with lockfile: no backups transferred because lockfile is taken.
• without lockfile: transfer of already snapshotted subvolumes (the ones seen when starting btrbk resume, while not-yet-snapshotted subvolumes will be transferred on next run.

If btrbk snapshot is started while btrbk resume is running (more probable, as btrbk resume is much longer task), the difference would be:

• with lockfile: no snapshots are created because lockfile is taken.
• without lockfile: snapshots are always created.

[mfr-itr]

Nice answer, I will try btrbk resume without a lockfile! I ended up running the daily backup at 3:30 instead of 3:00, so the lockfile should not be needed anyway. Maybe update the README with this usecase, maybe in a FAQ? BTW, maybe rename resume into backup to match btrbk snapshot? It would describe more accurately what the command does. Anyway, great utility, much easier to setup than snapper!

[digint]

BTW, maybe rename resume into backup to match btrbk snapshot? It would describe more accurately what the command does.

Yeah, well, you're not the first mentioning this. It's called resume because it does more than just backups: without any arguments it also deletes snapshots (see table in btrbk(1)). Furthermore, if all backups are already present, it does nothing.

So I rather stick with the "technically correct" naming btrbk resume, rather than (probably more intuitive) btrbk backup. Maybe I could add btrbk backup as an alias for btrbk resume --preserve-snapshots, but I think this would be more confusing than useful. See also discussions in #150.

[mfr-itr]

Fair!