Back Up System Data

A system data backup of a StarlingX system captures core system information needed to restore a fully operational StarlingX cluster.

System Data Backups include:

  • platform configuration details

  • system databases

  • patching and package repositories

  • home directory for the sysadmin user and all LDAP user accounts.

Warning

During a system backup, if the files contained in ‘sysadmin’ user’s home directory (/home/sysadmin) result in the overall size of the backup being larger than 2 Gbytes, the backup operation may fail.

Detailed contents of a system backup

The backup contains details as listed below:

  • Platform Configuration Data.

    All platform configuration data and files required to fully restore the system to a working state following the platform restore procedure.

  • (Optional) Any end user container images in registry.local; that is, any images other than StarlingX system and application images. StarlingX system and application images are repulled from their original source, external registries during the restore procedure.

  • Home directory ‘sysadmin’ user, and all LDAP user accounts (item=/etc)

  • Patching and package repositories:

    • item=/opt/patching

    • item=/var/www/pages/updates

Data not included in system backups

  • Application PVCs on Ceph clusters.

  • StarlingX application data. Use the command system application-list to display a list of installed applications.

  • Modifications manually made to the file systems, such as configuration changes on the /etc directory. After a restore operation has been completed, these modifications have to be reapplied.

  • Home directories and passwords of local user accounts. They must be backed up manually by the system administrator.

  • The /root directory. Use the sysadmin account instead when root access is needed.

Note

The system data backup can only be used to restore the cluster from which the backup was made. You cannot use the system data backup to restore the system to different hardware. Perform a system data backup for each cluster and label the backup accordingly.

To ensure recovery from the backup file during a restore procedure, containers must be in the active state when performing the backup. Containers that are in a shutdown or paused state at the time of the backup will not be recovered after a subsequent restore procedure.

When the system data backup is complete, the backup file must be kept in a secured location, probably holding multiple copies of them for redundancy purposes.

See also

Run Ansible Backup Playbook Locally on the Controller

Run Ansible Backup Playbook Remotely

Important

The following backup and retention policies are recommended:

  • All backups are done remotely and stored off the system.

  • All backups are done nightly (off-peak time).

  • Weekly backups should be the norm, i.e. under normal steady state conditions.

  • Nightly backups are the exception and should only be done in periods of high configuration changes to the system such as; during large/mass rollout (addition of subclouds), upgrade cycle of multiple sites, or disaster recovery rehoming of subclouds.

  • Retention period of backups should be approximately one (1) month.

    • Since Kubernetes is an intent-based system, the most recent backup is what is the most important.