Backing up Domino





Domino backups in AWS

By default, Domino runs in a “High Availability” mode, replicating its core components across three or more nodes in the cluster. Data losses are rare and unlikely to happen. However, in the event of a service disruption which impacts the entire cluster, we recommend recovery point (RPO) targets of 0 to 12 hours depending on the service level requirements of your organization. For deployments in the cloud, we strongly recommend deployments across multiple availability zones (AZs). Deployments on multiple AZs can expect an RTO between 0 and 10 minutes in most cases.

The following systems are canonical stores of critical Domino data, and they are stored and backed up in AWS as described below.

System Purpose Store Backup
Projects store Stores the contents of users’ project files. Stored in S3 in the bucket specified in the installer configuration at blob_storage.projects.s3.bucket. Relies on the inherent durability and automated replication and backups of S3.
Log history Stores execution logs from Domino jobs and workspaces. Stored in S3 in the bucket specified in the installer configuration at blob_storage.logs.s3.bucket. Relies on the inherent durability and automated replication and backups of S3.
Docker registry Stores Docker images built by Domino to back users’ Domino environments and Model APIs. Stored in S3 in the bucket specified in the installer configuration at internal_docker_registry .s3_override.bucket. Relies on the inherent durability and automated replication and backups of S3.
Datasets Stores the contents of users’ Domino Datasets. Stored in EFS in the file system specified in the installer config at storage_classes.shared .efs.filesystem_id. Relies on the inherent durability and automated replication and backups of EFS
MongoDB Stores Domino application object data and metadata. Stored in EBS-backed Kubernetes persistent volumes attached to pods running the HA MongoDB service in the Domino cluster. Domino performs a daily backup that writes an archive containing all MongoDB data to S3 in the bucket specified in the installer configuration at blob_storage.backups.s3.bucket.
Domino Git Stores Domino project version history. Stored in EBS-backed Kubernetes persistent volumes attached to pod running the Domino Git service in the Domino cluster. Domino performs a daily backup that writes an archive containing all Git data to S3 in the bucket specified in the installer configuration at blob_storage.backups.s3.bucket.
Postgres Stores information on users managed by the Keycloak authentication service. Stored in EBS-backed Kubernetes persistent volumes attached to pods running the HA Postgres service in the Domino cluster. Domino performs a daily backup that writes an archive containing all Postgres data to S3 in the bucket specified in the installer configuration at blob_storage.backups.s3.bucket.

Recovery

If you choose to run “hot” backup instances or additional storage facilities for disaster recovery, you can request an increase in quota limits for one or more of the AWS services if needed. You can check the default service quotas on this page and manage your quotas by logging in to the AWS Service Quotas console.

If you need to restore a deployment from backups, submit a maximum severity support request and the Domino operations team will assist with the recovery procedure.

In the case of instance or service failure, submit a maximum severity support request and the Domino operations team will assist with restoring the cluster to normal operation.

In the case of critical application failure, submit a maximum severity support request and the Domino operations team will assist with restoring the cluster to normal operation.

By default, Domino runs in a “High Availability” mode, replicating its core components across three or more nodes in the cluster. Should a fault condition occur, submit an appropriate severity support request ticket and the Domino operations team will assist with restoring the cluster to normal operation.




Domino backups on-premises

The following systems are canonical stores of critical Domino data, and they are stored and backed on-premises as described below. These methods can also be applied to other clouds for which Domino does not have native storage integrations.

System Purpose Store Backup
Projects store Stores the contents of users’ project files. Stored in the shared storage class defined at storage_classes.shared and referenced at blob_storage.projects. The most common backing storage for this class is NFS. Domino does not automatically back up this data. Domino recommends configuring a separate backup process that saves or syncs the entire contents of the NFS mount path provided to Domino to another storage system. The volume of project data will grow linearly over time as users produce new projects, so you should account for the growing volume when setting backup frequency and retention policies.
Log history Stores execution logs from Domino jobs and workspaces. Stored in the shared storage class defined at storage_classes.shared and referenced at blob_storage.logs This is stored in the same volume as project data, and is therefore on the same filesystem path in the shared storage system. Any backups of the root path provided to Domino will include log data.
Docker registry Stores Docker images built by Domino to back users’ Domino environments and Model APIs. Stored in a block storage volume provisioned from the storage class defined at storage_classes.block and mounted in the Docker registry container. Domino does not automatically back up this data. Domino recommends configuring a separate backup process that saves or syncs the entire contents of the NFS mount path provided to Domino to another storage system. The volume of project data will grow linearly over time as users produce new projects, so you should account for the growing volume when setting backup frequency and retention policies.
Datasets Stores the contents of users’ Domino Datasets. Stored in the shared storage class defined at storage_classes.shared. This is stored in the same volume as project data, and is therefore on the same filesystem path in the shared storage system. Any backups of the root path provided to Domino will include log data.
MongoDB Stores Domino application object data and metadata. Stored in a block storage volume provisioned from the storage class defined at storage_classes.block and mounted in the Mongo containers. Domino performs a daily backup that writes an archive containing all MongoDB data to the shared storage class defined at storage_classes.shared and referenced at blob_storage.backups.
Domino Git Stores Domino project version history. Stored in a block storage volume provisioned from the storage class defined at storage_classes.block and mounted in the Git container.

System Message: INFO/1 (/home/docs/checkouts/readthedocs.org/user_builds/domino-admin-docs/checkouts/4.5.1/docs/source/backup-restore/backups.rst, line 2); backlink

Duplicate explicit target name: “blob_storage.backups”.

Domino performs a daily backup that writes an archive containing all Git data to the shared storage class defined at storage_classes.shared and referenced at blob_storage.backups.

Postgres Stores information on users managed by the Keycloak authentication service. Stored in a block storage volume provisioned from the storage class defined at storage_classes.block and mounted in the Postgres containers.

System Message: INFO/1 (/home/docs/checkouts/readthedocs.org/user_builds/domino-admin-docs/checkouts/4.5.1/docs/source/backup-restore/backups.rst, line 2); backlink

Duplicate explicit target name: “blob_storage.backups”.

Domino performs a daily backup that writes an archive containing all Postgres data to the shared storage class defined at storage_classes.shared and referenced at blob_storage.backups.




Support

Domino support coverage is outlined on our Scope of Support Coverage page. You can learn more about our support priority codes, ticket statuses, and business hours on our Support Definitions page.

In addition to the support tiers described above, some Domino customers may have unique contractual SLAs defined in the Master Service Agreement. All customers receive a standard service level agreement.