Overview

ClusterControl provides comprehensive backup and restore capabilities to ensure the continued availability and integrity of your database systems. This overview outlines how ClusterControl simplifies the process of creating reliable backups, managing your backup strategy, and performing efficient data restoration for various database technologies.

What you can do

ClusterControl's backup and restore features fall into four broad areas, across its supported database engines:

Backup creation and scheduling

• Physical or logical backups, on demand or on a schedule, from any database node.
• Full, incremental, or partial (specific schema/table) backups.
• Backup encryption, and compression with an adjustable compression level.
• Automatic backup host selection based on role (replica or primary), with automatic failover to another node if the selected one is unavailable.
• Backup throttling to limit the impact on the source node.
• Configurable backup file naming and subdirectory format.
• Incremental and differential backup chaining, grouped by backup type.

Storage and retention

• Store backups locally, on the controller, or in cloud object storage (public or any S3-compatible private provider).
• Stream backups directly to cloud storage, skipping local storage entirely, for supported methods.
• Upload or download existing backups to and from the cloud.
• Rotation and retention policies for local and cloud backups, with automatic purging of expired backups.

Reliability and recovery

• Automatic backup verification.
• Point-in-time recovery for MySQL, MariaDB, PostgreSQL, MongoDB (via Percona Backup for MongoDB), and SQL Server.
• Restore to a temporary database server outside the cluster.
• Create a new cluster from an existing backup.
• Restore a backup taken outside ClusterControl (MySQL Replication and Galera clusters only). See Restore External Backup.
• Backup history.

Operations and management

• Centralized backup management for all your database clusters, from a unified ClusterControl GUI dashboard or the ClusterControl CLI.
• Email, PagerDuty, Slack, or custom webhook alerts on backup-related events.
• Scheduled or on-demand operational reports on backup status.

Backup jobs

The backup process performed by ClusterControl is running as a background thread (RUNNING3) which doesn't block any other non-backup jobs in the queue. If the backup job takes hours to complete, other non-backup jobs can still run simultaneously via the main thread (RUNNING). You can see the job progress at ClusterControl GUI → Activity center → Jobs.

Note that ClusterControl executes a single backup job per cluster at any given time. If multiple scheduled backups for a cluster overlap, the subsequent schedules will not start until the active backup job is finished. For instance, if a full daily backup is set for 7:00 AM, and incremental backups are scheduled hourly, the 7:00 AM incremental backup will likely wait for the full backup to complete before it begins. You may avoid this by excluding certain hours in the schedule by using the scheduler advanced editor, which follow the UNIX cron format, as shown in the following example:

Backup encryption and decryption

If the encryption option is enabled for a particular backup, ClusterControl will use OpenSSL to encrypt the backup using the AES-256 CBC algorithm. Encryption happens on the backup node. If you choose to store the backup on the controller node, the backup files are streamed over in encrypted format through socat or netcat.

If compression is enabled, the backup is first compressed and then encrypted resulting in smaller backup sizes. The encryption key will be generated automatically (if not exists) and stored inside the CMON configuration for the particular cluster under backup_encryption_key the option. This key is stored with base64 encoded and should be decoded first before using it as an argument to pass when decrypting the backup. The following command shows how to decode the key:

cat /etc/cmon.d/cmon_X.cnf | grep ^backup_encryption_key | cut -d"'" -f2 | base64 -d > keyfile.key

Where X is the cluster ID. The above command will read the backup_encryption_key value and decode the value to a binary output. Thus, it is important to redirect the output to a file, as in the example, we redirected the output to keyfile.key. The key file which stores the actual encryption key can be used in the OpenSSL command to decrypt the backup, for example:

$ cat {BACKUPFILE}.aes256 | openssl enc -d -aes-256-cbc -pass file:/path/to/keyfile.key > backup_file.xbstream.gz

Or, you can pass the stdin to the respective restore command chain, for example:

$ cat {BACKUPFILE}.aes256 | openssl enc -d -aes-256-cbc -pass file:/path/to/keyfile.key | gzip -dc | xbstream -x -C /var/lib/mysql

Backup retention

Backup retention can be configured at ClusterControl GUI → {cluster} → Backups → ... → Backup Settings → Default backups retention period (default is 31 days) to the number of days ClusterControl keeps the existing backups. Backups older than the value defined will be deleted. You can also customize the retention period per backup (default, custom or keep forever) under the Backup Retention field when creating or scheduling a backup.

The purging is based on the following conditions:

1. When a new backup is successfully created, and if no verified backup is requested, the older backups will be checked and removed.
2. When the verified backup is successfully created, the older backups will be checked and removed.
3. The backup housekeeping job remains executed every 24 hours. Thus, if no backups are created and no backups are verified, the backup retention still will be done every 24 hours

For cloud-storage backups, they follow the Cloud backup retention period setting (default is 180 days).

Danger

Backups exceeding the retention period will be deleted. Once the backups are deleted, they can't be recovered.

Backup storage

Backup created and scheduled in ClusterControl can only be stored in the following location:

• ClusterControl controller host, where the backup file will be streamed over to the ClusterControl host on-the-fly.
• The database host that being backed up.
• Cloud storage, which you have the option to stream directly (physical backup only) or upload to cloud after the backup is successful.

If you have external backup storage host, you can use NFS and share the volume where your backup shall be stored on either of the ClusterControl controller host, or the database host itself. ClusterControl will respect the Storage directory as the base directory for all backups, suffixed by the Backup subdirectory as explained below.

Backup subdirectory

ClusterControl will create the backup directory on the destination host, relative to the Storage directory path if doesn't exist. The default value is BACKUP-%I, which produces BACKUP-151 for a backup with ID 151. This string may hold standard %X field separators. For example, BACKUP-%06I will be replaced by the numerical ID of the backup in 6 field-wide format that uses '0' as leading fill characters (e.g, BACKUP-000151).

The following table shows the supported variables:

Variable	Description
B	The date and time when the backup creation was beginning.
H	The name of the backup host, the host that created the backup.
i	The numerical ID of the cluster.
I	The numerical ID of the backup.
J	The numerical ID of the job that created the backup.
M	The backup method (e.g. "mysqldump").
O	The name of the user who initiated the backup job.
S	The name of the storage host, the host that stores the backup files.
%	The percent sign itself. Use two percent signs, %% the same way the standard printf() function interprets it as one percent sign.

You can combine multiple variables and field-width specifiers in a single format string to organize backups by cluster, method, and host while keeping the numeric ID sortable. For example:

c%i-%M-%H-job%J-BACKUP-%06I

For a xtrabackupfull backup with ID 151, taken by job 8831 on cluster 42 from host 192.168.40.60, this resolves to:

c42-xtrabackupfull-192.168.40.60-job8831-BACKUP-000151

The %06I zero-pads the backup ID to 6 digits, so directories continue to sort correctly by ID even once you have more than 999 backups, which the plain %I in the default format does not guarantee.

Backup settings

The default backup settings can be configured under ClusterControl GUI → {cluster} → Backups → ... → Backup Settings. These settings are bounded per database cluster. In this section, you can configure the following settings:

Setting	Description
Default directory	The default path for the backup directory. ClusterControl will create the backup directory on the destination host if doesn't exist.
Default subdirectory	The default subdirectory naming format. See Backup subdirectory.
Netcat port	Specify the port number or port number range that will be used by ClusterControl to stream backup created on the database node. This port must be opened on both source and destination hosts. Only used if you choose Store on Controller in the Storage Location configuration. Default is "9999,9990-9998", which means port 9999 will be preferred if available.
Enable hash check on created backup files	Toggle On (default) to have ClusterControl perform an MD5 checksum on the created backup. For large backups, this may consume significant resources during the process. If toggled Off, the MD5 checksum verification is disabled. Note that there is no built-in way to verify the integrity of backup files when they are streamed over the network.
Default backups retention period	The number of days ClusterControl retains existing backups. Backups older than the defined value will be automatically deleted. You can also customize the retention period per backup (default, custom, or keep forever) under Backup Retention when creating or scheduling a backup. See Backup retention for how and when purging runs.
Default cloud backups retention period	The number of days ClusterControl retains uploaded backups in the cloud. Backups older than the defined value will be automatically deleted.

Supported backup methods

ClusterControl offers support for various backup tools and methods, tailored to the specific database clusters in use. The table below details these options:

Cluster type	Supported backup methods
MySQL-based clusters	mysqldump Percona Xtrabackup (full, incremental) Binlog backup
MariaDB-based clusters	mariadb-dump MariaDB Backup (full, incremental) Binlog backup
PostgreSQL-based clusters	pg_dump pg_dumpall pg_basebackup (full, incremental - only for v17 and later) pgBackRest (full, incremental, differential)
MongoDB-based clusters	mongodump Percona Backup for MongoDB
Redis-based clusters	RDB (includes AOF file if AOF persistence is enabled)
SQL Server	Full Differential Transaction log
Elasticsearch	Elasticsearch snapshot

Note

Binlog backup is only available for scheduled backups, not for on-demand backups. See Schedule Backup → Supported backup methods.

Each database backup method is explained in the following sections.

mysqldump

ClusterControl performs mysqldump against all or selected databases by using the --single-transaction option. It automatically performs mysqldump with --master-data=2 if it detects binary logging is enabled on the particular node to generate a binary log file and position statement in the dump file. ClusterControl generates a set of 4 mysqldump files with the following suffixes:

• _data.sql.gz - Schemas' data.
• _schema.sql.gz - Schemas' structure.
• _mysqldb.sql.gz - MySQL system database.
• _triggerseventroutines.sql.gz - MySQL triggers, events, and routines.

Percona Xtrabackup

Percona Xtrabackup is an open-source MySQL hot backup utility from Percona that can back up data from InnoDB, XtraDB, and MyISAM tables. Xtrabackup does not lock your database during the backup process. For large databases (100+ GB), it provides a much better restoration time as compared to mysqldump. The restoration process involves preparing MySQL data from the backup files before replacing or switching it with the current data directory on the target node.

Since its ability to create full and incremental MySQL backups, ClusterControl manages incremental backups, and groups the combination of full and incremental backups in a backup set. A backup set has an ID based on the latest full backup ID. All incremental backups after a full backup will be part of the same backup set. The backup set can then be restored as one single unit using the Restore Backup feature.

Attention

Without a full backup to start from, the incremental backups are useless.

mariadb-dump

The mariadb-dump is a logical backup utility included with MariaDB Server. It's essentially MariaDB's fork of the original MySQL mysqldump tool and is a replacement to mysqldump since MariaDB 10.4. It supports MariaDB system-versioned tables, sequence, virtual columns and MariaDB-specific privilege grants which are different than the MySQL implementation.

On all supported versions for MariaDB, ClusterControl will default to mariadb-dump as the preferred logical backup method.

MariaDB Backup

MariaDB Backup is a fork of Percona XtraBackup with added support for compression and data-at-rest encryption available in MariaDB, included in MariaDB 10.1.23 and later. It is an open-source tool provided by MariaDB for performing physical online backups of InnoDB, Aria, and MyISAM tables. MariaDB Backup is available on Linux and Windows.

On all supported versions for MariaDB, ClusterControl will default to MariaDB Backup as the preferred backup method and snapshot state transfer (SST) method.

Binlog backup

Attention

This backup method is available only when scheduling a MySQL or MariaDB backup (not supported for on-demand backups) and requires a supported object storage destination. Successful binlog backups are not listed in the backup list, as they are designed to work in conjunction with PITR-compatible full backups. To restore, select a PITR-compatible backup and enable Point-in-Time Recovery (PITR) to apply the binary logs.

Binlog backup involves backing up MySQL or MariaDB binary logs, which record all data-changing events. These logs are used together with a full backup to enable point-in-time recovery (PITR). Binlog backups are not a replacement for full backups. Instead, they serve as an incremental layer that captures changes occurring after the last full backup.

Binlog backups are particularly useful for:

• Recovering from accidental DELETE, UPDATE, or DROP operations.
• Restoring the database to a specific point in time.
• Minimizing data loss between full backups.

Follow these steps to configure and use binlog backups effectively:

1. Perform or schedule a full PITR-compatible backup method such as:
   • mysqldump (must be PITR-compatible)
   • xtrabackup (full or incremental)
   • mariabackup (full or incremental)
2. Configure a cloud storage credential for binlog backups under ClusterControl GUI → Settings → Cloud storage credentials.
3. Schedule regular binlog backups at an interval aligned with your recovery objectives (RPO/RTO), for example:
   • Every hour
   • Every 12 hours
   • Daily
4. When restoring via ClusterControl, choose a PITR-compatible backup and enable Point-in-Time Recovery.
5. ClusterControl will perform the following automatic restoration process:
   • Retrieve the required binary logs from object storage
   • Restore the selected full backup
   • Replay binary logs up to the specified time or position

When performing a binlog backup operation, ClusterControl performs the following actions in particular order:

1. Executes FLUSH BINARY LOGS to rotate the current binary log and records the new log file.
2. Uploads all completed binary logs to object storage, excluding the active (latest) log file.
3. Stores metadata about the uploaded logs in the cmon.backup_binlog table.

pg_dump/pg_dumpall

Depending on the database backup target configuration, ClusterControl will automatically choose the suitable method to create the logical backup using either pg_dump or pg_dumpall backup tool. Commonly, pg_dump will be chosen for a partial logical backup, while pg_dumpall for a full logical backup.

ClusterControl performs pg_dumpall against all databases together with --clean the option, which includes SQL commands to clean (drop) databases before recreating them. DROP commands for roles and tablespaces are added as well. The output will be .sql.gz extension and the file name contains the timestamp of the backup.

pg_basebackup

pg_basebackup is used to take base backups of a running PostgreSQL database cluster. These are taken without affecting other clients to the database and can be used both for point-in-time recovery and as the starting point for a log shipping or streaming replication standby server. It makes a binary copy of the database cluster files while making sure the system is put in and out of backup mode automatically. Backups are always taken of the entire database cluster; it is not possible to back up individual databases or database objects.

ClusterControl connects to the replication stream using the replication user (default is cmon_replication) with --wal-method=fetch option when creating the backup. The output will be base.tar.gz inside the backup directory.

Starting with ClusterControl 2.4.0 (June 2026), incremental backups using pg_basebackup are supported. This feature requires the PostgreSQL summarize_wal parameter, which is available only in PostgreSQL 17 and later. When enabled, summarize_wal starts a background process that continuously analyzes the Write-Ahead Log (WAL) and tracks which database blocks have changed. This information allows pg_basebackup to perform incremental backups by copying only modified blocks, significantly reducing backup time, storage requirements, and network usage.

To enable this feature, run the Configure WAL job from the node menu (see Configuring WAL). Before creating an incremental backup, ensure that a full pg_basebackup backup has been successfully completed with summarize_wal enabled, as incremental backups rely on this base backup.

pgBackRest

pgBackRest is an open-source software developed to perform efficient backup on PostgreSQL databases that measure in tens of terabytes and greater. It supports per-file checksums, compression, partial/failed backup resume, high-performance parallel transfer, asynchronous archiving, tablespaces, expiration, full/differential/incremental, local/remote operation via SSH, hard-linking, restore, and more. The tool is written in Perl and does not depend on rsync or tar but instead performs its own deltas which give it maximum flexibility.

Installing pgBackRest

Starting from ClusterControl 1.9.0, pgBackRest can be configured as follows:

1. Primary: Install on the current primary node only (not on replicas). The backup repository will be hosted on the primary node. No SSH configuration is required for PgBackRest.
2. All database nodes: Install on all database nodes. The backup repository will be hosted on the current primary node, while backups are performed from a standby node. PgBackRest uses SSH for inter-node communication, and key-based authentication is automatically configured by ClusterControl.
3. All database nodes and a dedicated repository host: Install PgBackRest on all PostgreSQL nodes. The backup repository will be hosted on a separate, dedicated server (not part of the database cluster). Backups are performed from a standby node. PgBackRest uses SSH for communication, with key-based authentication automatically configured by ClusterControl.

Note

The pgBackRest backup directory cannot be reused or shared with other backup methods.

During the first attempt of making pgBackRest backup, ClusterControl will re-configure the node to install and configure pgBackRest. Take note that this operation requires a database restart and might introduce downtime to your database. A configuration file will be created at /etc/pgbackrest.conf and will be configured according to the version used and location of the PostgreSQL data. The pgBackRest default repository path is located at /var/lib/pgbackrest. Additionally, ClusterControl will configure the following lines inside postgresql.conf (which explains why it requires restart during the first run):

archive_mode = on
archive_command = 'pgbackrest --stanza=clustercontrol-stanza archive-push %p'

Attention

PITR using pg_basebackup will no longer be possible if switching the WAL archiving method from "local WAL archiving" to "pgBackRest".

Info

In the ClusterControl GUI, pgBackRest nodes are listed with a fake port number (200000 + cluster ID), due to the internal CmonHost object requirement for a host:port combination. As a matter of fact, the pgBackRest process does not listen, nor need a port number.

Full backup

Full backup of pgBackRest copies the entire contents of the database cluster to the backup. The first backup of the database cluster is always a Full Backup. pgBackRest is always able to restore a full backup directly. The full backup does not depend on any files outside of the full backup for consistency.

Differential backup

For differential backup, pgBackRest copies only those database cluster files that have changed since the last full backup. pgBackRest restores a differential backup by copying all of the files in the chosen differential backup and the appropriate unchanged files from the previous full backup. The advantage of a differential backup is that it requires less disk space than a full backup, however, the differential backup and the full backup must both be valid to restore the differential backup.

For example, if a full backup is taken on Sunday and the following daily differential backups are scheduled, the data that is backed up will be:

• Monday - data from Sunday to Monday
• Tuesday - data from Sunday to Tuesday
• Wednesday - data from Sunday to Wednesday
• Thursday - data from Sunday to Thursday

Incremental backup

For incremental backup, pgBackRest copies only those database cluster files that have changed since the last backup (which can be another incremental backup, a differential backup, or a full backup). As an incremental backup only includes those files changed since the prior backup, they are generally much smaller than full or differential backups. As with the differential backup, the incremental backup depends on other backups to be valid to restore the incremental backup. Since the incremental backup includes only those files since the last backup, all prior incremental backups back to the prior differential, the prior differential backup, and the prior full backup must all be valid to perform a restore of the incremental backup. If no differential backup exists then all prior incremental backups back to the prior full backup, which must exist, and the full backup itself must be valid to restore the incremental backup.

For example, if a full backup is taken on Sunday and the following daily incremental backups are scheduled, the data that is backed up will be:

• Monday - data from Sunday to Monday
• Tuesday - data from Monday to Tuesday
• Wednesday - data from Tuesday to Wednesday
• Thursday - data from Wednesday to Thursday

Write-Ahead Logging (WAL) Archiving

WAL archiving stores transaction logs continuously, allowing recovery to a specific point in time when combined with a base backup. ClusterControl provides a built-in interface to configure PostgreSQL WAL (Write-Ahead Logging) archiving for Point-in-Time Recovery (PITR) with pg_basebackup. For pgBackRest, WAL archiving is automatically configured when installing the backup tool for the first time.

Configuring WAL

To configure WAL archiving, go to ClusterControl GUI → {cluster} → Backups → ... → Configure WAL. The Configure WAL dialog appears, where you can configure the following options:

• Apply to: Select which PostgreSQL nodes should receive the WAL archiving configuration. You can configure WAL archiving on all PostgreSQL nodes or on selected individual nodes. In most deployments, WAL archiving is configured on all PostgreSQL nodes.

• Archive mode: Controls the PostgreSQL archive_mode setting. Choose Off to disable WAL archiving. Choose On to enable WAL archiving during normal operation. This is the recommended setting for most environments. Choose Always to force WAL archiving even during recovery or standby mode.

• Compress WAL archive: When enabled, ClusterControl compresses archived WAL files to reduce storage usage. This option is recommended for environments with high transaction volume, long retention periods, or limited archive storage capacity.

• Summarize WAL: Toggle On to enable the PostgreSQL summarize_wal parameter, which starts a background process that tracks which database blocks have changed since the last backup. PostgreSQL 17 or later only. This is required before you can create an incremental pg_basebackup; see pg_basebackup for details.

• Custom WAL archive directory: Specify a custom directory where WAL archive files will be stored. If left empty, ClusterControl uses the default archive location configured for the cluster. Ensure that the PostgreSQL user has permission to write to the selected directory.

Click Configure to apply the changes. ClusterControl will:

1. Update the PostgreSQL WAL archiving settings.
2. Configure the required archive commands.
3. Reload or restart PostgreSQL if required.
4. Begin archiving WAL files automatically.

The following is an example configuration loaded into a PostgreSQL instance after the "Configure WAL" job finishes:

archive_mode=always
archive_command='test -f /data_volume/postgres/data/../wal_archive/%f.gz || gzip -c < %p > /data_volume/postgres/data/../wal_archive/%f.gz'
archive_cleanup_command='pg_archivecleanup -x .gz /data_volume/postgres/data/../wal_archive %r'

The archived WAL files can then be used for Point-in-Time Recovery (PITR). See Restore Backup.

Note

• Changing the WAL archive configuration may invalidate previously collected WAL archives and reduce the available PITR recovery window.
• WAL archiving should be used together with regular full backups.
• Sufficient storage space should be allocated for WAL retention.

Local archiving vs pgBackRest archiving

The main difference is that local WAL archiving (like using the cp command) is a basic, single-threaded copy process, while pgBackRest archiving is a professional-grade, multi-featured pipeline designed for reliability and speed.

If you use simple local archiving, you have to manually ensure those files get copied to all standbys or a shared drive. With pgBackRest, the archive-push command automatically ships WALs to a central repository that all your nodes (primary and standbys) can access instantly. This is what makes failover possible. When a standby is promoted, it just starts "pushing" to the same central location the old master was using, keeping your backup stream unbroken.

flowchart LR
    subgraph Local["<b>Local WAL archiving</b>"]
        direction TB
        lp[(<b>Primary</b>)] -->|"archive_command:<br>cp"| lw[/"Local archive<br>directory"/]
        lw -.->|"you copy<br>manually"| ls1[(<b>Standby A</b>)]
        lw -.->|"you copy<br>manually"| ls2[(<b>Standby B</b>)]
    end

    subgraph PBR["<b>pgBackRest archiving</b>"]
        direction TB
        pp[(<b>Primary</b>)] -->|"archive-push"| repo[["<b>Central<br>repository</b>"]]
        repo -->|"accessible<br>instantly"| ps1[(<b>Standby A</b>)]
        repo -->|"accessible<br>instantly"| ps2[(<b>Standby B</b>)]
        ps1 -.->|"on promotion,<br>keeps pushing here"| repo
    end

mongodump

ClusterControl uses the standard command to perform mongodump with --journal, which allows mongodump operations to use the durability journal to ensure that the export is in a consistent state against shards.

Info

mongodump (and mongorestore) is not available for MongoDB Sharded Cluster 4 and later that have sharded transactions in progress, as backups created with mongodump do not maintain the atomicity guarantees of transactions across shards.

Percona Backup for MongoDB

Percona Backup for MongoDB (PBM) is an open-source backup solution designed for MongoDB replica sets and sharded clusters. It provides distributed, consistent, and low-impact backup operations with support for physical backups, logical backups, point-in-time recovery (PITR), and oplog-based recovery.

PBM supports Percona Server for MongoDB and MongoDB Community Edition deployments running with replication enabled. Since PBM relies on MongoDB replication and oplog synchronization, standalone MongoDB instances are not supported.

Info

ClusterControl only supports Percona Backup for MongoDB for MongoDB sharded clusters. For MongoDB replica sets, use mongodump.

Percona Backup for MongoDB is the successor to the older "mongodb-consistent-backup" project, which is no longer maintained. PBM is now the recommended backup solution for modern MongoDB environments.

Since ClusterControl only supports PBM for sharded clusters, a pbm-agent runs on every mongod in the cluster (every shard's replica set members, plus the Config Server Replica Set), so the whole cluster can be backed up as one consistent unit. mongos routers don't hold data, so they don't need one. Every agent must write to the same shared remote storage, mounted at an identical local path on every node; see the warning under Installing Percona Backup for MongoDB below.

flowchart TB
    mongos[["<b>mongos router(s)</b><br><i>no pbm-agent needed</i>"]]

    subgraph Shard1["<b>Shard 1</b> (Replica Set)"]
        direction LR
        s1p[("<b>Primary</b><br>+ pbm-agent")]
        s1s[("<b>Secondary</b><br>+ pbm-agent")]
    end

    subgraph Shard2["<b>Shard 2</b> (Replica Set)"]
        direction LR
        s2p[("<b>Primary</b><br>+ pbm-agent")]
        s2s[("<b>Secondary</b><br>+ pbm-agent")]
    end

    subgraph CSRS["<b>Config Server Replica Set</b>"]
        direction LR
        csp[("<b>Config Primary</b><br>+ pbm-agent")]
        css[("<b>Config Secondary</b><br>+ pbm-agent")]
    end

    mongos -.->|routes queries| Shard1
    mongos -.->|routes queries| Shard2
    mongos -.->|routes queries| CSRS

    Shard1 <-.->|"pbm-agents coordinate a<br>cluster-wide consistent backup"| CSRS
    Shard2 <-.->|"pbm-agents coordinate a<br>cluster-wide consistent backup"| CSRS

    s1p & s1s & s2p & s2s & csp & css -->|writes backup data| storage[/"<b>Shared remote storage</b><br>mounted at the same<br>local path on every node"/]

Installing Percona Backup for MongoDB

Percona Backup for MongoDB requires an extra step for installation and configuration, and it is not enabled by default. You can use ClusterControl to install this tool by going to ClusterControl GUI → Clusters → {cluster} → Action → Install Percona Backup, or simply choose the backup method percona-backup-mongodb from the dropdown list when configuring a backup method for the first time. If the tool is not installed, ClusterControl will advise on installing the backup tool first before moving forward to the next step.

1. Click Continue button to proceed on installing the percona-backup-mongodb backup tool.
2. Specify the Backup directory. Make sure that the backup directory path exists.
3. Click Install button.

Attention

Percona Backup for MongoDB requires a remote file server mounted to a local directory. It is the responsibility of the server administrators to guarantee that the same remote directory is mounted at exactly the same local path on all servers in the MongoDB cluster or non-sharded replica set. If the path is accidentally a normal local directory, errors will eventually occur, most likely during a restore attempt.

Redis/Valkey RDB & AOF

RDB (Redis Database Backup) is a snapshot-based persistence format used by Redis and Valkey. It stores the dataset in a compact binary file at a specific point in time and is commonly used for backups and recovery.

AOF (Append Only File) is a persistence mechanism that records every write operation received by the server. This allows the database state to be reconstructed by replaying the logged operations.

When backing up Redis or Valkey, ClusterControl backs up the RDB file and, if AOF persistence is enabled, the corresponding AOF files from the selected database node.

MSSQL Backup

For Microsoft SQL Server (MSSQL), ClusterControl uses the native backup capabilities provided by SQL Server and does not rely on external backup tools. Backup operations are executed through the sqlcmd client, which connects to the SQL Server instance and performs the requested backup tasks.

ClusterControl supports the following MSSQL backup types:

• Full Backup - Creates a complete backup of all selected databases. A full backup captures the entire database state at the time the backup operation completes.
• Differential Backup - Backs up only the data changed since the last full backup. Differential backups are smaller and faster than full backups and are grouped under their associated full backup on the Backup page.
• Transaction Log Backup - Backs up transaction logs to support point-in-time recovery and reduce transaction log growth. At least one full backup must exist before transaction log backups can be created.

Attention

Differential backups typically grow larger over time because they include all changes made since the last full backup. For example, in a write-intensive workload, the first hourly differential backup after a full backup may be relatively small, while the last differential backup before the next scheduled full backup can become significantly larger due to the accumulated changes throughout the day.

Take note of the following operational behavior performed by ClusterControl for MSSQL backups:

• Backups are always performed on the primary node, regardless of the selected backup type.
• Backup files are stored in the /var/lib/backups directory.
• Backup data is stored only on the primary node.
• Backup files are always encrypted. ClusterControl always adds ENCRYPTION (ALGORITHM = AES_256, SERVER CERTIFICATE = ...) to the generated BACKUP DATABASE statement, using a certificate it manages. This is SQL Server's own native backup encryption, separate from the OpenSSL-based encryption used for other backup methods, and is not a configurable option.
• Backups cannot run if the primary node is unavailable, since ClusterControl cannot identify a valid backup candidate.
• If the selected backup type is not Full (e.g, Differential or Transaction Log) and no existing full backup is found in the backup directory, ClusterControl automatically performs a full backup instead. This full backup becomes the base backup for subsequent differential or transaction log backups.

For example, a full backup runs a statement equivalent to:

BACKUP DATABASE [myexampledb] TO DISK = '/var/lib/backups/BACKUP-838222/myexampledb_full.bak'
WITH CHECKSUM, COMPRESSION, ENCRYPTION (ALGORITHM = AES_256, SERVER CERTIFICATE = S9sDbmEncryptCert)

A common backup strategy is to perform full backups periodically (for example, weekly), differential backups more frequently (such as daily), and transaction log backups at shorter intervals throughout the day.

One limitation of MSSQL backups is version compatibility. Backups created on newer versions of SQL Server cannot be restored on older SQL Server versions.

Elasticsearch Snapshot

An Elasticsearch snapshot is a way to back up your Elasticsearch indices and data. The process involves creating a snapshot of one or more indices and storing it in a designated repository. This snapshot can then be used to restore the indices to their previous state in case of data loss or other issues. The snapshot process is incremental, meaning that only changes made since the last snapshot are stored. Snapshots can be taken manually or automatically on a schedule, and can also be used to migrate data between clusters or to create new indices.

Note that during cluster deployment, ClusterControl configures Elasticsearch snapshot storage by requiring the specification of the repository name, storage location, and file system path early in the process. The snapshot repository will then be available under the Backups section of the Elascticsearch cluster.