Contact Us 1-800-596-4880
  1. Homepage
  2. Runtime Fabric (1.11)
  3. Manage Runtime Fabric

  4. Back Up and Restore Runtime Fabric

Back Up and Restore Runtime Fabric

Use the following procedures to back up and restore Runtime Fabric services and the required state necessary for all deployed applications and their configurations.

Data about the state of Runtime Fabric is distributed across the Kubernetes cluster. To preserve applications in the event of system failure, confirm that Runtime Fabric is automatically backed up. When scheduling backups, follow best practices by configuring hourly backups. Store your backup on external storage outside the Runtime Fabric cluster.

For Runtime Fabric on VMs / Bare Metal, the back up and restore process includes backing up and restoring appliance-related custom resources such as logforwarder and smtp. The back up and restore process does not include backing up metrics data stored in the InfluxDB that is generated by the applications.

Common scenarios for using the back up and restore process include:

  • Performing a major infrastructure upgrade, such as migrating nodes in a Runtime Fabric cluster to a new version of an operating system.

  • Upgrading Runtime Fabric for VMs / Bare Metal. In some cases, you may want to back up your cluster, install a new cluster using a new Runtime Fabric version on that same cluster, and then restore your backup on that cluster.

  • Migrating your Runtime Fabric cluster from on-premises to the cloud or migrating from one cloud provider to another.

  • Performing a failover to a standby cluster.

Do not use the back up and restore process to create concurrent running instances of Runtime Fabric. In other words, do not back up Runtime Fabric A, use that back up to create a new Runtime Fabric B while Runtime Fabric A is still active, and attempt to run them concurrently. This creates application deployment issues.

The Back Up and Restore Process Does Not Affect the Control Plane

The Runtime Fabric back up and restore process affects only the Runtime Fabric cluster, and it does not involve the control plane. Any changes you make after you perform a backup will not be present if you restore the cluster from that backup. For example, if you perform a backup, delete an application, and then restore from that backup, the application you deleted will be recreated in the cluster, but it will be marked as deleted in Runtime Manager. As a result the application’s status will show as applying in Runtime Manager.

You need to manually resolve such inconsistencies by reapplying the changes you made after performing the backup, as these changes can’t be reapplied from the control plane.

Before You Begin

Before performing a back up or restore operation:

  • Verify that Runtime Fabric is installed and running successfully.

  • Verify that rtfctl command-line tool is upgraded to version 0.3.102 or later. Verify the version by running rtfctl version on any Runtime Fabric node.

  • If you are using Runtime Fabric on VMs / Bare Metal, verify that Runtime Fabric is upgraded to version 1.1.1581474166 or later. See Anypoint Runtime Fabric Installer Release Notes.

  • Performing a back up per node, such as via a VM snapshot, is not supported.

  • Configuration changes you make to deployed applications and management services after a back up are not restored.

  • Application monitoring metrics are not restored after performing the back up and restore process.

Create a Backup

To create a backup run the following command:

./rtfctl backup <path_to_backup_file>

This command creates a backup of the current system state in <path_to_backup_file>, which can be any path in the file system that you have write access to, such as: /opt/anypoint/runtimefabric/backup.tar.gz.

  • For Runtime Fabric on VMs / Bare Metal, the rtfctl binary is in directory /opt/anypoint/runtimefabric/. Confirm that you run the backup command on a controller node in the cluster as a privileged user. To use the backup for restoring later, copy the backup file to secure storage on a different machine that is not part of Runtime Fabric.

    The following command, for example, uses scp to copy the backup to another drive:

    scp your_username@remotehost:/opt/anypoint/runtimefabric/backup.tar.gz /backup-path/to-restore.tar.gz

  • For Runtime Fabric on Self-Managed Kubernetes, confirm that the rtfctl binary is present in the current directory and kubectl is present in the user $PATH. Additionally, confirm that you’ve set the Kubernetes (kubectl) context to the intended backup cluster.

Restore a Cluster

Runtime Fabric provides two target options when restoring a cluster from a backup:

  • Use an existing Runtime Fabric cluster.

  • Create a new Kubernetes cluster with the same configuration as the backed-up cluster. This includes the same number of servers, disks, etc.

To create a new Kubernetes cluster on VMs / Bare Metal without Runtime Fabric being installed, run the Runtime Fabric installer script(s) without providing the Runtime Fabric activation data.

When restoring on an existing Runtime Fabric cluster, use the same version of the rftctl command-line utility that you used to create the backup.

  1. Copy the backup file and make sure it is available to rtfctl.

    • For Runtime Fabric on VMs / Bare Metal, copy the compressed backup file to a directory in a controller node of the environment to be restored. For example, you can transfer this file securely via the following command:

      scp /backup-path/to-restore.tar.gz your_username@remotehost:/opt/anypoint/runtimefabric/

  2. Confirm your Kubernetes (kubectl) context is set to the backed-up cluster, and scale down all Runtime Fabric components on the original backed-up cluster:

    kubectl scale --replicas=0 -n rtf deployment.apps/agent

  3. Restore the cluster from the backup:

    ./rtfctl restore <path_to_backup_file>

    This process may require several minutes to complete.

For Runtime Fabric on Self-Managed Kubernetes, confirm the rtfctl binary is present in the current directory and the Kubernetes (kubectl) context is set to the cluster you are restoring to.

See Also