Software AG Products 10.11 | Administrating API Gateway | Operating API Gateway | Data Management | Data Backup | Restore Operation | Restoring Data Store Backup
 
Restoring Data Store Backup
You can restore the data from backup snapshots using the apigatewayUtil script.
Important:
If your restore operation fails for some reason and if the error message instructs you to use the perform_open_indices command, follow the steps given in the section Troubleshooting a Failed Restore.
*To restore API Data Store
1. From the command prompt, go to SAGInstallDir/IntegrationServer/instances/default/packages/WmAPIGateway/cli/bin.
Note:
Replace default with the corresponding instance name.
2. Run the following command to restore a backup file:
Linux
./apigatewayUtil.sh restore backup -name backup-file-name
Windows
apigatewayUtil.bat restore backup -name backup-file-name
The specified backup is restored. Since, the repoName parameter is not specified in the above command, the value is picked from the tenantparameter.
You can include the following parameters as per your requirements:
Parameter
Description
tenant
Name of the tenant from which you want to restore.
If you do not provide this parameter, the value is picked from pg.gateway.elasticsearch.tenantId property in config.properties file located at IntegrationServer\instances\instance_name\packages\WmAPIGateway\config\resources\elasticsearch.
repoName
Name of the repository from which you want to restore the backup file.
If you do not provide this parameter, the value is picked from the tenantparameter.
In case you have more than one repository, you must provide this parameter with the name of the repository that you want to restore from.
sync
Option to specify whether the restore process is performed in a synchronously or asynchronously. The possible values are:
*true. The restore process is synchronous. That is, the script will wait until the restore is completed. Depending on the size of the data being restored, this could be a time-consuming process.
*false. The process is asynchronous. That is, the script does not wait for the completion of the restore operation. Rather, the restore request will be issued, and the script will complete. This is the default value. You can later check the status of the restore process using the status restore command. For information on viewing the restore status, see Verifying Restore Status.
srcTenant
Option to specify whether that the tenant name in the backup file is different from the tenant name on which the restore is being performed. Hence, this must be used in combination with the tenant parameter that specifies the tenant name to which the data backup is being restored. That is,
apigatewayUtil.sh restore backup
-name backup_file_name
-srcTenant backup_tenant_name
-tenant tenant_name
If you do not provide the tenant parameter, then the script assumes the tenant name as the value for srcTenant.
Note:
The srcTenant, aggregate, and restoreClusterState parameters must be used with caution and only in cases where it is deemed necessary. For normal incremental backup and restore operations, these parameters do not play a significant role.
include
Option to include any of the following based on your input:
*analytics. Restores the analytics data, logs, and events data.
*assets. Restores assets.
*license. Restores license metrics.
*audit. Restores audit logs.
*log. Restores log data.
You can provide one or more of the above values separated by commas, and without spaces. For example, to restore analytics and assets, you can provide
./apigatewayUtil.sh restore
backup -name backup_file_name
-repoName repository_name
-include analytics,assets
aggregate
Option to specify whether the existing license, logs, audit, and analytics data should be merged with the restored data. The possible values are:
*true. The existing data is merged with the restored data. If some analytics data is present in the current instance, and you restore from a backup, which also has analytics data, and if you provide -aggregate true, then the script restores the analytics data from the backup into a new index and includes it in the index alias for analytics. So you can find the existing analytics data as well the analytics data from the restored backup file in your instance.
*false. The existing data is replaced with the restored data. This is the default value.
Note:
This parameter is not applicable for assets data. That is, you cannot aggregate assets data. Hence, if you had provided -include assets in your restore command, then the parameter is ignored because it is not applicable.
restoreClusterState
Option to specify whether the global state settings such as templates and cluster state must be restored. The cluster state includes information such as persistent cluster settings, index templates, pipelines, and so on. It must be restored only in a new Elasticsearch instance. The possible values for this parameter are:
*true. The global state settings are restored.
*false. The global state settings are not restored. This is the default value.
Do not use this parameter for normal restore operations. Use only when restoring backup from a different Elasticsearch or when the -srcTenant parameter is specified.
Note:
If you have secured Data Store using Search Guard, you cannot restore the global cluster state of the Data Store. The global cluster state includes information such as persistent cluster settings, index templates, pipelines, and so on. To restore the global cluster state, you must either perform the restore with the cluster state first, then secure the Data Store, or disable Search Guard, perform the restore with cluster state, and then enable the security plugin. However, you can still perform a restore without the global cluster state with the Search Guard plugin enabled. For information on Restoring data and the usage of restore parameters, refer the Restore using script section.
logLevel
Level of log that you want to create. Log levels indicate the severity of logs. Available levels are:
*Info. Provides the list of regular events that occur during the process. These events are informative.
*Debug. Provides the events that could be useful, if you have to debug the process.
*Warning. Indicates unexpected events that occurred during the process. Usually, these events do not interrupt or have an immediate effect on the process.
*Error. Indicates the events that stop the functionality from working as designed.
*Trace. Provides the list of events in a much detailed manner that could be useful for debugging.
You can specify one of the log level with the logLevel parameter. For example, to create a log file of Warning level when listing backup files, you can run the following command:
apigatewayUtil.bat list backup -logLevel warning
When you provide Error as the log level, then only the error level logs are saved. When you provide Debug as the log level, then Debug, Info, Warning and Error level logs are saved. When you provide Trace as log level, then all level logs are saved.
This parameter is optional. If you do not specify the parameter, then the Info level logs are saved by default.
logFileLocation
Location where you want to save the log file.
For example, to save the log file in C:/apiglogs/backups, you can provide the location as seen in the following example:
apigatewayUtil.bat create backup -name samplebackup
-logFileLocation C:/apiglogs/backups
This parameter is optional. If you do not specify the parameter, the logs are saved in the following location SAGInstallDir/IntegrationServer/instances/instance_name/packages/WmAPIGateway/cli/logs/APIGWUtility.log
The parameters listed above are optional. To restore a backup from the repository that you configured, use the repoName parameter, and provide the repository name. That is,
Linux
./apigatewayUtil.sh restore backup -name backup_file_name
-repoName repository_name
Windows
apigatewayUtil.bat restore backup -name backup12april -repoName S3_repo
Note:
If you are providing the srcTenant parameter, or setting the aggregate or restoreClusterState as true, then Software AG recommends that you take a backup of the node that you need to restore before performing the restore.
3. Restart API Data Store.
In cluster setups, restart all nodes in the cluster.