App Mobility

This section is for your information only. You can not execute this section on this lab environment because we are using a shared cluster for many users. Feel free to read through this section however to understand how you would set up Kasten to restore workloads to a different cluster from the one they were backed up from.

The demo environment on the Red Hat Demo Platform does not have that restriction. Feel free to use that environment after Red Hat One.

1. Introduction

In this exercise you will restore an OpenShift Virtual Machine to an alternate cluster from a Kasten backup.

This exercise should be completed by the cluster-1 user ONLY.

2. Creating an Import Policy

Unlike the "Snapshot" policy created in a previous exercise, an "Import" policy is used to import Kasten RestorePoints to a different cluster.

  1. In the Kasten Dashboard, select cluster-1 from the multi-cluster dropdown menu and select Policies → Policies from the sidebar.

  2. Under your kasten-lab-backup Policy, click Show import details…​.

    1

  3. Click Copy to Clipboard to copy the migration token. Save this value to be used in an upcoming step.

    2

  4. Select cluster-2 from the multi-cluster dropdown menu and select Policies → Policies from the sidebar.

  5. Click + New Policy and fill out the following fields:

    Name

    kasten-lab-import

    Action

    Select Import

    Restore After Import

    Click to enable

    Import Frequency

    Select On-Demand

    Config Data for Import

    Paste the migration token

    Profile for Import

    Select global-profile-example
    3
    3b
    Ensure global-profile-example is selected, not ceph-rgw-immutable - this is because global-profile-example points to the backup repository on cluster-1, whereas the ceph-rgw-immutable profile on cluster-2 points to its own, local Ceph bucket.

  6. Click Create Policy.

  7. Under the new kasten-lab-import Policy, click Run Once → Yes to initiate importing kasten-lab RestorePoints.

    4

  8. Return to Dashboard in the sidebar and select the kasten-lab-import Policy Run under Actions to monitor status.

    5

    Once the Import completes, you should observe the Restore action start immediately, using the most recent kasten-lab RestorePoint.

  9. Once the restore completes, open OpenShift Console → Virtualization → Virtual Machines on cluster-2.

    6

    You should observe the fedora-k10 VM from cluster-1 running in the kasten-lab namespace (in addition to the fedora-k10 VM cloned in a previous lab exercise).

3. Advanced Options

What if you want to automate restoring the most recent backup to a standby cluster for DR or test/dev purposes?

Simply update the kasten-lab-import Policy’s frequency from On-Demand to the desired frequency (e.g. Hourly, Daily, etc.).

What if you need to make changes such as targeting an alternate StorageClass for restore or modifying the Route hostname?

Kasten provides a robust transformation engine, allowing you to test, add, delete, copy, or replace key value pairs in a resource’s manifest.

Check out the video below to see an example of creating and applying transforms to an application migrating from an on-premises OpenShift cluster to a ROSA cluster:

4. Takeaways

  • Kasten backups can be restored to different clusters using Import policies

  • Import policies can automate restore from the latest backup for use in DR or test/dev environments

  • Transforms can be used to alter manifest specifications to aide in moving workloads between different clusters, storage, or clouds