Daniel Nashed's Blog

Extending Domino Backup Integrations with a second backup tier

Domino Backup can be used as a simple backup without any external backup solution.
But it can be also be part of a multi tier backup strategy.

The most simple backup enabled out of the box is to write to a local or remote storage location.
Usually this is de-duplicating storage like a ZFS.
ZFS can also be used to create a snapshot after the backup finishes. But you would need a trigger to invoke the snapshot.

For containers or with remote storage locations an in-sync trigger would be challenging.
In this case a trigger file to create a snapshot or a second tier backup on the remote storage would be helpful.
Here is an example how you could write in the Post Backup command instead of executing an inline action:

/local/backup/nsf/backup_moby.lab.dnug.eu_FULL_20260125113609.req

BackupNode: moby.lab.dnug.eu
BackupRefDate: 20260125113609
BackupRetentionDateTimeText=20260201113609
Directory=/local/backup/nsf/moby.lab.dnug.eu/FULL/20260125113609

---

What is important to know is that the formula is invoked on the draft backup log document.
Not all fields have been written at that point - for example the counters for processed backups are not written.
But all the meta information like:


BackupNode
BackupMode
BackupRefDate
BackupRetentionDateTimeText
BackupTargetDir


This helps to build all kind of integrations.
In my case I am looking into flows like this:

1. Standard Domino Backup to a ZFS deduplicating storage
2. Have the backend create a ZFS snapshot triggered by the tag file
3. In addition use a second tier for DR recovery using Restic Backup to backup to S3 or Borg Backup to backup to a backup repository via SSH

The standard restore process would be used against the ZFS file storage.

Only in a DR situation:

1. The local snapshot can be restored
2. Or if completely broken restore from Restic/Borg Backup

Restic Backup - would work well for a S3 based 2nd trier backup
Borg Backup - would be a good choice for a remote DR location like a Hetzner StorageBox because Borg Backup would only send the data once and is very good at deduplicating and meta data caching.

The key point here is that the primary backup and restore stays very simple.
This concept would also work with Domino in Docker/Podman and Kubernetes Containers where you would just assign another volume (like of a different storage class).

• Comments [0]