Check the backup history#

MKE 4 records each backup attempt as an MkeBackup object in the mke namespace, provided that the backup history API is available. Use these objects to verify backup outcomes and to locate backup archives.

Note

A backup can complete successfully even if MKE 4 fails to write its MkeBackup record. A missing record does not indicate a failed backup.

The source value identifies what triggered the backup:

Source	Trigger
`Manual`	`mkectl backup` command, node addition, or node removal
`PreUpgrade`	MKE 4 upgrade
`Scheduled`	Backup schedule

Check conditions, not only the result

A record can report Completed even when the configuration bundled in the archive is not the current cluster configuration. Before you rely on a backup as current, review the record's conditions. For details, refer to Configuration snapshot fallback.

List the backup records:
```
kubectl -n mke get mkebackups
```

Optional. Filter the list by label:

To list failed backups:

kubectl -n mke get mkebackups -l mke.mirantis.com/backup-result=Failed

To list manual backups:

kubectl -n mke get mkebackups -l mke.mirantis.com/backup-source=Manual

Inspect a record to view its conditions and archive location:
```
kubectl -n mke describe mkebackup <backup_name>
```

Each record reports where the archive was written. The location depends on how the backup was taken:

Scheduled backup: The archive stays on the controller that took it, in the directory set by schedule.path.
Manual backup: The archive is written to the machine where you ran the mkectl backup command, not to a cluster node. mkectl operates on the cluster over SSH from outside it.

MKE 4 keeps up to 200 history records by default. To change this limit, set spec.backup.historyRetain. This limit is independent of schedule.retain, which limits the number of archives. Because records are much smaller than archives, MKE 4 typically keeps them longer, so the history can include records whose archives retention has already deleted.