Restore and validate the application on HPC

Both clusters have been appropriately configured to allow for a smooth transition of data, so now we’re able to migrate our application onto the newer hosted architecture. 

Prerequisites:

• Backup must be in Completed state.
• OADP is installed and configured on the hosted cluster.
• Backup is visible in oc get backups -n openshift-adp.
• Cluster-scoped, role-based access controls (RBAC) have been applied or included in backup via alternative approach.

In this lesson, you will:

• Restore your application to the hosted cluster.
• Verify the application once on the hosted control planes cluster.
• Clean up your source cluster. 

Restoring your application to the hosted cluster

Following the role-based access controls being placed, it’s time to restore the application. The pods will start with the correct permissions already configured.

1. Create a Restore custom resource to restore the application.

   export KUBECONFIG=~/kubeconfig-bm-hosted-cluster
   cat <<EOF | oc apply -f -
   apiVersion: velero.io/v1
   kind: Restore
   metadata:
     name: cert-discovery-app-restore
     namespace: openshift-adp
   spec:
     backupName: cert-discovery-app-backup
     includedNamespaces:
       - cert-discovery-app
     restorePVs: true
     existingResourcePolicy: update
   EOF

   Each field speaks to specific needs for the custom resource:

3. Wait for the restore to complete (up to 10 minutes).

   oc wait --for=jsonpath='{.status.phase}'=Completed \
     restore/cert-discovery-app-restore -n openshift-adp --timeout=10m

   Expected output:

   restore.velero.io/cert-discovery-app-restore condition met

5. Verify PVC is bound. 

   oc get pvc -n cert-discovery-app

   Expected output:

   NAME                  STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
   cert-discovery-data   Bound    pvc-yyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy      10Gi       RWO            lvms-vg1       3m

6. Check pod logs to ensure they return success messages.

   oc logs -n cert-discovery-app -l app=cert-discovery --tail=50 | grep -i database

   Expected output:

   2026-03-30 12:15:23,940 - __main__ - INFO - Database initialized successfully at /data/certificates.db
   2026-03-30 12:15:23,944 - __main__ - INFO - Database initialized and available for historical tracking

If the above posted reflects a success message, then it means the application was moved without issue. Next, we can validate that all relevant info exists within the hosted control planes cluster as expected.

Validating restored data

1. To cover all of our bases, we’ll go ahead and verify that the database was restored with all historical data.

   export KUBECONFIG=~/kubeconfig-bm-hosted-cluster 

2. Check that the database file was restored:

   oc exec -n cert-discovery-app deployment/cert-discovery-app -- ls -lh /data/certificates.db

3. Next, verify discovery runs were restored:

   oc exec -n cert-discovery-app deployment/cert-discovery-app -- \
     sqlite3 /data/certificates.db "SELECT COUNT(*) FROM certificate_discoveries;"

4. Verify certificate records were restored:

   oc exec -n cert-discovery-app deployment/cert-discovery-app -- \
     sqlite3 /data/certificates.db "SELECT COUNT(*) FROM certificates;"

5. View most recent discoveries:

   oc exec -n cert-discovery-app deployment/cert-discovery-app -- \
     sqlite3 /data/certificates.db "SELECT id, timestamp, total_certificates FROM certificate_discoveries ORDER BY id DESC LIMIT 5;"

   Expected output:

   -rw-rw-r--. 1 1000960000 1000960000 211M Mar 31 14:47 /data/certificates.db
   
   862
   
   567802
   
   862|2026-03-31 14:47:54|173
   861|2026-03-31 14:44:18|173
   860|2026-03-31 14:41:20|173
   859|2026-03-31 14:33:14|173
   858|2026-03-31 14:30:14|173

   You can also access the web UI via the following:

   ROUTE=$(oc get route cert-discovery-route -n cert-discovery-app -o jsonpath='{.spec.host}')
   echo "Application URL: http://$ROUTE"

If you see historical discovery runs and certificate records, it means the migration was successful!

Cleanup steps (optional)

Once you have confirmed that the target cluster is working correctly, here are some optional steps to clean up the source cluster.

1. Input the following:

   export KUBECONFIG=~/kubeconfig-pm-cluster

2. Delete the application namespace:

   oc delete namespace cert-discovery-app

3. Optionally delete the backup (keeps it in S3):

   oc delete backup cert-discovery-app-backup -n openshift-adp

The OADP operator and DPA resources can be kept for migrating other applications if you want to do so in the future.