Application migration between two clusters using import policies

This article explains the prerequisites and best practices that need to be considered for successful import during application migration.

K10 platform is built to support application migration across clusters which is an extremely powerful feature that enables a variety of use cases including Disaster Recovery (DR), Test/Dev  with realistic data sets, and performance testing in isolated environments.

Easiest way to migrate an application is to export the application from the source cluster and import it into the destination cluster.

Export can be easily configured and run by following this documentation.

Following recommendations should be considered before running an import policy.

Prerequisites for a successful import

• Ensure K10 installation is identical(same K10 version, installation namespace etc.) in both the source and target clusters.

While we continuously make improvements how we generate the encryption keys in each version of K10, having same version of K10 in the source and destination clusters will reduce the possibility of import failure due to mismatch between K10 versions in source and target clusters.

Also, if the K10 installation namespace is different between the source and target cluster, import action will fail with the error `No kopia manifests found in the repository`

{
  "cause": {
    "file": "kasten.io/k10/kio/collections/kopia/operations.go:144",
    "function": "kasten.io/k10/kio/collections/kopia.GetLatestSnapshot",
    "linenumber": 144,
    "message": "No kopia manifests found in the repository"
  },
  "file": "kasten.io/k10/kio/exec/phases/phase/migrate.go:359",
  "function": "kasten.io/k10/kio/exec/phases/phase.(*migrateReceivePhase).Run",
  "linenumber": 359,
  "message": "Failed to import latest collection"
}

Currently, the datamover server user is created based on the name of the K10 namespace. If the secondary cluster where the application is to be imported has K10 installed in a namespace with a different name, then a wrong datamover server user will be set causing the error `No kopia manifests found in the repository`. This means that K10 couldn’t find the data from the export location profile with the current user. 

• Ensure that external storage target(location profile S3/NFS/VBR), where the backups are exported from source cluster is accessible and registered as a location profile in the target cluster.
• Ensure correct `Config data for Import`i.e., migrationToken, is used while creating the import policy. This encoded string has all the metadata that K10 needs to access, decrypt and restore the data from the repository. So it is important to get the correct config string for a successful import.
  
  Example - Manual exports are stored in a different repository when compared to the policy based exports. It is important to validate if the export is manual or policy based and copy the string accordingly.