You are viewing documentation for a release that is no longer maintained. To view the documentation for the most recent version, see the latest RHACS docs.

Backup and restore

Red Hat Advanced Cluster Security for Kubernetes 3.71

Backing up and restoring Red Hat Advanced Cluster Security for Kubernetes

Red Hat OpenShift Documentation Team

Abstract

Describes how to back up the system and restore from a backup.

Chapter 1. Backing up Red Hat Advanced Cluster Security for Kubernetes

You can perform data backups for Red Hat Advanced Cluster Security for Kubernetes. You can use these backups for data restoration in the case of an infrastructure disaster, or corrupt data.

You can configure automatic or on-demand backups by integrating with Amazon S3 or Google Cloud Storage. Or you can perform on-demand backups by using the roxctl command-line interface (CLI).

The backup includes the entire Red Hat Advanced Cluster Security for Kubernetes database, which includes all configurations, resources, events, and certificates. Make sure that backups are stored securely.

Important

If you are using Red Hat Advanced Cluster Security for Kubernetes 3.0.53 or older, the backup does not include certificates.

1.1. On-demand backups by using the roxctl CLI

You can use the roxctl CLI to take the backups by using the backup command. You require either an API token or your administrator password to run this command.

1.1.1. On-demand backups by using an API token

You can back up the entire database of Red Hat Advanced Cluster Security for Kubernetes by using an API token.

Prerequisites

  • You must have an API token with the Admin role.
  • You must have installed the roxctl CLI.

Procedure

  1. Set the ROX_API_TOKEN and the ROX_CENTRAL_ADDRESS environment variables: 

    $ export ROX_API_TOKEN=<api_token>
    $ export ROX_CENTRAL_ADDRESS=<address>:<port_number>

  2. Run the backup command:

    • For Red Hat Advanced Cluster Security for Kubernetes 3.0.55 or later: 

      $ roxctl -e "$ROX_CENTRAL_ADDRESS" central backup

    • For Red Hat Advanced Cluster Security for Kubernetes 3.0.54 or older: 

      $ roxctl -e "$ROX_CENTRAL_ADDRESS" central db backup

By default, the roxctl CLI saves the backup file in the directory in which you run the command. You can use the --output option to specify the backup file location.

Additional resources

1.1.2. On-demand backups by using the administrator password

You can back up the entire database of Red Hat Advanced Cluster Security for Kubernetes by using your administrator password.

Prerequisites

  • You must have the administrator password.
  • You must have installed the roxctl CLI.

Procedure

  1. Set the ROX_CENTRAL_ADDRESS environment variable: 

    $ export ROX_CENTRAL_ADDRESS=<address>:<port_number>

  2. Run the backup command:

    • For Red Hat Advanced Cluster Security for Kubernetes 3.0.55 or later: 

      $ roxctl -p <admin_password> -e "$ROX_CENTRAL_ADDRESS" central backup

    • For Red Hat Advanced Cluster Security for Kubernetes 3.0.54 or older: 

      $ roxctl -p <admin_password> -e "$ROX_CENTRAL_ADDRESS" central db backup

By default, the roxctl CLI saves the backup file in the directory in which you run the command. You can use the --output option to specify the backup file location.

Chapter 2. Restoring from a backup

You can restore Red Hat Advanced Cluster Security for Kubernetes from an existing backup by using the roxctl command-line interface (CLI).

You can use the roxctl CLI to restore Red Hat Advanced Cluster Security for Kubernetes by using the restore command. You require either an API token or your administrator password to run this command.

2.1. Restoring by using an API token

You can restore the entire database of Red Hat Advanced Cluster Security for Kubernetes by using an API token.

Prerequisites

  • You must have a Red Hat Advanced Cluster Security for Kubernetes backup file.
  • You must have an API token with the administrator role.
  • You must have installed the roxctl CLI.

Procedure

  1. Set the ROX_API_TOKEN and the ROX_CENTRAL_ADDRESS environment variables: 

    $ export ROX_API_TOKEN=<api_token>
    $ export ROX_CENTRAL_ADDRESS=<address>:<port_number>

  2. Run the restore command: 

    $ roxctl -e "$ROX_CENTRAL_ADDRESS" central db restore <backup_file>

2.2. Restoring by using the administrator password

You can restore the entire database of Red Hat Advanced Cluster Security for Kubernetes by using your administrator password.

Prerequisites

  • You must have a Red Hat Advanced Cluster Security for Kubernetes backup file.
  • You must have the administrator password.
  • You must have installed the roxctl CLI.

Procedure

  1. Set the ROX_CENTRAL_ADDRESS environment variable: 

    $ export ROX_CENTRAL_ADDRESS=<address>:<port_number>

  2. Run the restore command: 

    $ roxctl -p <admin_password> -e "$ROX_CENTRAL_ADDRESS" central db restore <backup_file>

2.3. Resuming the restore operation

During a restore operation, if your connection is interrupted or you need to go offline, you can resume the restore operation.

  • If you do not have access to the machine running the resume operation, use the roxctl central db restore status command to check the status of an ongoing restore operation.
  • In case of connection interruptions, the roxctl CLI automatically tries to restore a task when the connection becomes available. The automatic connection retries depend on the duration specified by the timeout option.
  • Use the --timeout option to specify the time in seconds, minutes, or hours, after which the roxctl CLI stops trying to resume a restore operation. If not specified, the default timeout is 10 minutes (10m).
  • If a restore operation is stuck or if you want to cancel it, use the roxctl central db restore cancel command to cancel an ongoing restore operation.
  • If a restore operation is stuck, or you have canceled it, or it timed out, you can resume the previous restore by re-running the original command.
Note
  • During interruptions, Red Hat Advanced Cluster Security for Kubernetes caches an ongoing restore operation for 24 hours. You can resume this operation by re-running the original restore command.
  • The --timeout option only governs client-side connection retries and does not affect the 24 hours server-side restore cache.
  • You cannot resume restore operations across restarts of the Central pod.
  • If a restore operation is interrupted, you must restart it within 24 hours and before Central restarts, otherwise Red Hat Advanced Cluster Security for Kubernetes cancels the restore operation.

Legal Notice

Copyright © 2023 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.