Schedule cluster backupsNew#

Configure MKE 4 to take backups on a recurring schedule. The controllers run scheduled backups themselves, without mkectl.

Configure the backup schedule#

Use node-local storage for the backup path

With replication: AllControllers, set schedule.path to storage that is local to each controller. Do not use a shared or network filesystem. Controllers that write to the same shared path interfere with each other's retention and in-progress archives. MKE 4 does not detect this misconfiguration, so verify the path before you apply the configuration.

Add the schedule block to the backup section of your mke4.yaml configuration file:
```
spec:
  backup:
    schedule:
      enabled: true
      cronExpression: "0 2 * * *"
```
cronExpression accepts any of the following formats:
- A standard 5-field crontab expression
- A 6-field expression that includes seconds
- A descriptor, such as @daily
Calendar schedules use UTC. For example, 0 2 * * * runs daily at 02:00 UTC, regardless of the controllers' local timezones. Relative schedules such as @every 24h require replication: LeaderOnly; they are rejected with AllControllers, the default.

Space scheduled runs at least 5 minutes apart. MKE 4 rejects a schedule with closer runs when you apply the configuration.

Optional. Adjust the schedule settings:

Setting	Default	Description
`schedule.replication`	`AllControllers`	Controls which controllers take a backup on each run. `AllControllers` writes one archive on each controller. `LeaderOnly` writes a single archive on the current etcd leader.
`schedule.path`	`/var/lib/mke/backups`	Sets the directory on each controller that stores that controller's archives. Must be node-local storage.
`schedule.retain`	`30`	Sets the number of archives to keep on each controller. `0` keeps all archives.
`schedule.includeLogs`	`false`	Writes the operation log to a sibling file with `.tar` replaced by `.log`; for example, `backup.tar` has `backup.log`. MKE 4 never encrypts this log, even when it encrypts the archive.

Apply the configuration:
```
mkectl apply -f <config_file_path>
```

Skipping backup runs

MKE 4 skips a scheduled backup run when either of the following conditions occurs:

Another etcd maintenance operation holds the node lock and does not release it within the 10-minute attempt window.
No usable configuration is available to back up. For details, refer to Configuration snapshot fallback.

A skipped run produces no archive. MKE 4 does not retry the run immediately; the next attempt occurs at the next scheduled time.

For each skipped run, MKE 4 sets the following on the backup resource:

status.result: Skipped
The label mke.mirantis.com/backup-result=Skipped
The cause of the skip in status.error

MKE 4 also emits a Kubernetes event with the reason BackupSkipped. To determine why a run was skipped, inspect status.error.

Encrypt scheduled backups#

Scheduled backups run unattended, so MKE 4 reads the passphrase from a Kubernetes Secret rather than from a prompt. Without an encryption block, MKE 4 writes scheduled backups unencrypted.

Retain superseded passphrases

Changing the passphrase in the Secret affects only backups taken after the change. Existing archives remain encrypted with the passphrase that was in effect when MKE 4 wrote them. Replacing the Secret value discards the old passphrase, and MKE 4 cannot recover it. Store each superseded passphrase for as long as you retain the archives that depend on it.

Each encrypted scheduled archive and its MkeBackup history record carry a key identifier and the name of the Secret that holds the passphrase. The key identifier remains with the archive if you copy the archive to another location or if MKE 4 prunes the history record. Use the key identifier to determine which retained passphrase decrypts the archive; the identifier does not contain the passphrase itself. Manual backups that you create with mkectl backup indicate that they are encrypted, but they do not record a key identifier.

Create a Secret from a passphrase file that only your user account can read. The passphrase must be at least 12 bytes long, which equals 12 characters if you use only ASCII characters. MKE 4 strips trailing carriage returns and newlines from the passphrase, so these characters do not count toward the minimum length::
```
kubectl create secret generic mke-backup-passphrase -n mke --from-file=passphrase=/path/to/passphrase-file
kubectl label secret mke-backup-passphrase -n mke mke.mirantis.com/backup-passphrase=true
```
MKE 4 uses the label to assign a key identifier to the passphrase. If the Secret is missing, lacks the label, or contains an invalid passphrase, MKE 4 marks the backup attempt as Failed and writes no archive. MKE 4 does not fall back to an unencrypted backup.

Reference the Secret in the schedule block of your mke4.yaml configuration file:

spec:
  backup:
    schedule:
      enabled: true
      cronExpression: "0 2 * * *"
      encryption:
        passphraseSecretRef:
          name: mke-backup-passphrase

Apply the configuration:
```
mkectl apply -f <config_file_path>
```

The Secret encrypts only scheduled backups. It has no effect on mkectl backup, which requires either --passphrase or --no-passphrase on each run. For restore requirements that apply to all encrypted archives, refer to Encrypt backups.

Scheduled backups and the etcd maintenance lock

Scheduled backups share a per-controller lock with the automated operations of the etcd maintenance service: defragmentation, event cleanup, and storage-quota recovery. If one of these operations holds the lock when a backup starts, the backup waits up to 10 minutes for the lock to release. If the lock is still held after 10 minutes, MKE 4 skips that backup and runs the next one at its scheduled time.