Viewing restore logs

This page describes how you can check the restore job logs to confirm completion and validate the restore.

Verifying completion

To verify that the restore operation completed successfully:

  1. Use the following command to check if the restore operation completed without error:

    kubectl get pods -n -l job-name=apigee-cassandra-restore
    

    The output is similar to the following:

    NAME                               READY     STATUS      RESTARTS   AGE
    apigee-cassandra-restore-6tttv     0/1       Completed   0          23m
    
  2. Use the following command to check if the cassandra replicas are up and running:

    kubectl get pods -n -l app=apigee-cassandra
    

    The output is similar to the following:

    NAME                           READY     STATUS      RESTARTS   AGE
    apigee-cassandra-default-0     1/1       Running     0          24m
    apigee-cassandra-default-1     1/1       Running     0          23m
    apigee-cassandra-default-2     1/1       Running     0          22m
    

Viewing restore logs

To view the restore logs of a Kubernetes pod, run the kubectl logs -f <pod_name> -n <namespace> command. For example:

kubectl logs -f apigee-cassandra-restore-b4lgf -n apigee

Validating restore

Upon completing the restore operation, you can use the control plane to confirm that your organization's developers, apps, and API products were restored correctly.

To view the restored data:

  1. On the command line, get or refresh your gcloud authentication credentials, as the following example shows:

    TOKEN=$(gcloud auth print-access-token)
  2. Use the following command to validate your organization's data, where APIGEE_ORG is an Apigee organization deployed in the cluster:
    • For developer data:

      No data residency

      curl -s -H "$TOKEN" https://apigee.googleapis.com/v1/organizations/APIGEE_ORG/developers

      Data residency

      curl -s -H "$TOKEN" https://CONTROL_PLANE_LOCATION-apigee.googleapis.com/v1/organizations/APIGEE_ORG/developers
    • For apps data:

      No data residency

      curl -s -H "$TOKEN" https://apigee.googleapis.com/v1/organizations/APIGEE_ORG/apps

      Data residency

      curl -s -H "$TOKEN" https://CONTROL_PLANE_LOCATION-apigee.googleapis.com/v1/organizations/APIGEE_ORG/apps
    • For API product data:

      No data residency

      curl -s -H "$TOKEN" https://apigee.googleapis.com/v1/organizations/APIGEE_ORG/apiproducts

      Data residency

      curl -s -H "$TOKEN" https://CONTROL_PLANE_LOCATION-apigee.googleapis.com/v1/organizations/APIGEE_ORG/apiproducts

DNS Configuration for new cluster and traffic cutover

Once you are satisfied with validation, redirect the traffic to the new cluster and change the dns entry to new ingress EXTERNAL-IP address.

Get the EXTERNAL-IP with the following command:

kubectl get svc -n istio-system
NAME                       TYPE           CLUSTER-IP     EXTERNAL-IP    PORT(S)                                                                      AGE
istio-ingressgateway       LoadBalancer   10.11.123.45   34.56.78.90   15021:32225/TCP,80:32208/TCP,443:31942/TCP,15012:32689/TCP,15443:31936/TCP   1d