Restoring the Developer Portal subsystem

You can use apicup to restore the Developer Portal subsystem.

About this task

Note: These instructions apply to API Connect 10.0.1.1-eus or later.

You can restore your Developer Portal service by using the backups that exist on your remote server, by running the following apicup commands in your API Connect installation project directory. Note that before you can run these commands, you must have configured your remote backup server details, and have valid backups of both the Portal system and the installed sites. See Configuring backup settings for the Developer Portal subsystem and Backing up the Developer Portal subsystem.

Note:

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.
Restoration requires a functioning Developer Portal. In a disaster recovery scenario, you might need to reinstall the Developer Portal subsystem before you can restore the backed-up data. To reinstall, refer to Deploying the Developer Portal.

Procedure

To view the available backups and their status:

apicup subsys list-backups [subsystem_name] [flags]

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

Review which restore actions will be performed.
To see what restore actions are performed when the apicup subsys restore ptl command is run, you can use the following command:
```
apicup subsys restore ptl --dry-run --timestamp [now|YYYYMMDD.HHMMSS]
```
where --timestamp can be now, so the latest backup file that is available is used. Or you can specify a timestamp in the format of YYYYMMDD.HHMMSS to retrieve the nearest backup file to a specified time, searching backwards from the timestamp given.
Note:
- From IBM® API Connect Version 10.0.1.4-ifix1-eus, the timestamp format changed to YYYYMMDD.HHMMSS. For Version 10.0.1.2-eus and earlier, the timestamp format is YYYY-MM-DD HH:MM:SS.
- With the --dry-run option, the utility runs through the restore steps without executing them. You can use this option to see if the restore from the selected backup will succeed.
  The --dry-run option starts with the following output message:
```
Starting restore...please check later for completion status of restore
PortalRestore is Running
```
  To view the results of the dry-run, you can either look in the portal restore CR for a message of completion (or failure) or you can get a high-level status by entering:
  apicup subsys list-restores <subsys_name>
  Status values can be: Ready, Completed, Failed or Running.
Run the following command, and attach any flags as appropriate.
```
apicup subsys restore [SUBSYS_NAME] [flags]
```
- To restore your Portal service, run the following command:
```
apicup subsys restore ptl --timestamp [now|YYYYMMDD.HHMMSS]
```
  where --timestamp can be now, so the latest backup file that is available is used. Or you can specify a timestamp in the format of YYYYMMDD.HHMMSS to retrieve the nearest backup file to a specified time, searching backwards from the timestamp given. This command executes the portal restore process, which downloads the system backup and all of the site backups from the remote server, and installs them within the Portal stack. This process will then restore the system configuration from the found backup, and restore all of the sites. Note that if a backed up site is already installed on the current stack, then the site is reinstalled by using the backup (the site is overwritten by the backup). If there are multiple sites to restore, then these sites are queued for restoring. You can track the restoration process within the Portal www admin logs.
- By default the restore is a complete restore. You can optionally include --type all on the command line to specify a complete restore, but the flag is not required, as a complete restore is performed by default.
  Note that the complete restore uses the priorityList configuration setting that you specified in Configuring backup settings for the Developer Portal subsystem.
- To restore just the Portal system configuration, run the following command:
```
apicup subsys restore ptl --type system --system-name arg
```
  where arg can be a .tgz name or also accepts backup ID if TYPE=system and CR TYPE=record from the list-backups command.
  
  Note that if Portal system configuration information exists on the current stack, running this command will overwrite that configuration.
- To restore just the Portal sites, run the following command:
```
apicup subsys restore ptl --type site --site-name arg
```
  where arg can be the site backup tgz file name or URL, to restore a particular site by using the specified backup ID (or the latest backup file found if using a URL). Or you can use the argument all to restore all of the Portal sites that have backup files on the remote server. Note that if any of the backed up sites are already installed on the current stack, then they are reinstalled by using the backup (the sites are overwritten by the backup).
```
apicup subsys restore portal -h
Restore portal subsystem

Usage:
  restore SUBSYS [flags]

Flags:
      --debug                   Enable debug logging
      --dry-run                 Runs a dry run of the command, returning the actions that will be taken.
  -h, --help                    help for restore
      --site-name string        File to restore site from which should exist on the pod's local filesystem or the remote server. Also accepts backup ID if TYPE=site and CR TYPE=record.
      --system-name string      File to restore system from which should exist on the pod's local filesystem or the remote server. Also accepts backup ID if TYPE=system and CR TYPE=record.
      --timestamp string        In 'YYYYMMDD.HHMMSS' format, specify a timestamp to retrieve the backup from. The nearest backup, searching backwards from this timestamp, is used. (default "now")
      --type string             Type of restore to take ['system' (restore Portal System), 'site' (restore Portal Site), 'all' (complete restore)] (default "all")
      --wait                    Wait for the operation to complete or fail.
      --wait-timeout duration   Command timeout in seconds. (default 40s)
```

To view your restores and their statuses, run:

apicup subsys list-restores <subsys_name> <flags>

Help output:

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

To list the Portal backup sites, use the Portal CLI command. See Using the sites commands.
To list the Portal system sites, use the Portal CLI command. See Using the platforms commands.