Is this a valid plan for second level backups?

Hello all,
i have some servers which backup their stuff with restic to a central storage ( a hetzner storage box in this case).
They all have different requirements ( Nextcloud e.g. goes in matenance mode and does a cold backup of its database before the backup and restarts the stuff afterwards).

So these servers work on their own schedule, do a daily backup and a weekly prune and forget on their restic repository and this works quite good in my opinion.

I want to do a backup of the backup centrally and i am fine with some lag of this 2nd level backup .At the moment I do the following with a simple script:

  • create a zfs snapshot in the storage box

  • sync the directory tree of the restic repositories to a local harddisk (without restrictions)
    rclone --transfers=2 --checkers=2 --stats-log-level NOTICE --stats 60m sync restic_primary:/home/.zfs/snapshot/${snapshot_name}/restic /storage/local/_restic_lvl2

  • delete the zfs snapshot

This process is NOT syncronized with the individual backup processes and I presume that a restic check would bark at the state of some repositories.

But I presume also that i get at least an older backup in useful stats and that would be sufficient.

Does ths make sense at all ? Am i missing something obvious ?

Many tankks for reading !

Norbert

Afaik it should be safe enough, since restic should do all write/delete operations in correct order.

But personally in such setup I’d like to quickly check if there is an exclusive lock on the repositories first (by just running restic snapshots or similar to see if a prune running) before getting the zfs snapshot.

Just to not get warnings about clutter data in case some prune was running and I cut the data flow in the middle of repacking/deletion.

Also worth noting is that in case there is corruption you will of course sync that along, compared to having two backup jobs to separate repositories.