Restoring the management subsystem

Use apicup to list backups and restore a selected backup of the management subsystem

Before you begin

  • If you have to perform a restore, you must complete the restoration of the Management Service first, and then immediately restore the Developer Portal. The backups of the Management and Portal must be taken at the same time to ensure that the Portal sites are consistent with Management database.
  • When restoring, the Management, Analytics, and Developer Portal subsystems must be at the same version and fix pack level.
  • Restoring the Management Service requires database downtime and is a destructive process that deletes current data and copies backup data. During the restoration process, external traffic must be stopped.
  • In a Disaster Recovery scenario, do not log in to the administration UI or attempt to configure or change any settings prior to restoring the backup. Restore the backup immediately after installing the subsystem.
  • To restore the management database, you must use the original project directory that was created with apicup during the initial product installation. You cannot restore the database without the initial project directory because it contains pertinent information about the cluster. The endpoints and certificates cannot change; the same endpoints and certificates will be used in the restored system. Successful restoration depends on use of a single apicup project for all subsystems, even those in a different cluster. Multiple projects will result in multiple certificate chains which will not match.
  • Endpoints for the components cannot change between deployments. However, the endpoints for the VMware hosts can be modified for the new deployment.
  • Map the DNS entries from the source cluster to the corresponding IP addresses on the target cluster. Record the DNS entries for each endpoint before starting the restore.
  • When restoring the management database, the endpoints (on the new cluster which is the target for the restoration) have to be the same as those on the old cluster (the source of the backup).

About this task

Restoring a backup restores the registration credentials (client_ID, client_secret) that were in use at the time that the selected backup was created. For information on the registration credentials, see Changing the registration client_id and client_secret for applications.

Note: There is a known issue where sometimes a restore from the Management subsystem's SFTP backup succeeds but the data is not restored. If this happens, run the restore again.

Procedure

  1. To list the available backups:
    apicup subsys list-backups [subsystem_name] [flags]

    Example:

    # apicup subsys list-backups mgmt
    NAME                  STATUS   ID                 CLUSTER      TYPE   CR TYPE   AGE
    management-3aa3bebf   Ready    20200929-152150F   management   full   record    10h
    management-3c4ca8df   Ready    20200929-115520F   management   full   record    20h
    management-5tbxj      Ready    20200929-224349F   management   full   create    17h
    management-f10af337   Ready    20200925-133703F   management   full   record    5d2h
    management-jtlcd      Ready    20200929-224349F   management   full   create    25h
    management-zxjtz      Ready    20200929-224349F   management   full   create    28h

    Optional flags:

    ./apicup subsys list-backups -h
    List backups of the subsystem
    Usage:
      apicup subsys list-backups SUBSYS [flags]
    Flags:
      -h, --help               help for list-backups
          --timeout duration   Command timeout in seconds. (default 40s)
    Global Flags:
          --accept-license   Accept the license for API Connect
          --debug            Enable debug logging
    Attention: You can restore the Management subsystem from any backup where the STATUS is Ready; however, you should avoid restoring to the initial system backup. During installation, the Management database is used for an initial system backup before certain database schema jobs are complete. Restoring to this backup will result in an unstable system.
  2. To restore a selected backup:
    apicup subsys restore [subsystem_name] --name <backup_name> [flags]

    Example, where management-zxjtz is the value of <backup_name>, chosen from the backup NAMES listed by apicup subsys list-backups in Step 1:

    apicup subsys restore mgmt --name management-zxjtz

    Optional flags:

    apicup subsys restore management -h
    Restore management subsystem
    
    Usage:
      restore SUBSYS_NAME [flags]
    
    Flags:
          --debug                               Enable debug logging
      -h, --help                                help for restore
          --name string                         Name of the backup to restore
          --wait                                Wait for the operation to complete or fail.
          --wait-timeout duration               Command timeout in seconds. (default 40s)
  3. You can list your restores and their statuses.
    apicup subsys list-restores [subsystem_name] [flags]

    To view the optional flags, use -h:

    apicup subsys list-restores -h
    List restores of the subsystem
    
    Usage:
      apicup subsys list-restores SUBSYS [flags]
    
    Flags:
      -h, --help               help for list-restores
          --timeout duration   Command timeout in seconds. (default 40s)
    
    Global Flags:
          --accept-license   Accept the license for API Connect
          --debug            Enable debug logging