- Overview
- Requirements
- Pre-installation
- Installation
- Post-installation
- Migration and upgrade
- Upgrading Automation Suite
- Migrating standalone products to Automation Suite
- Step 1: Restoring the standalone product database
- Step 2: Updating the schema of the restored product database
- Step 3: Moving the Identity organization data from standalone to Automation Suite
- Step 4: Backing up the platform database in Automation Suite
- Step 5: Merging organizations in Automation Suite
- Step 6: Updating the migrated product connection strings
- Step 7: Migrating standalone Orchestrator
- Step 8: Migrating standalone Insights
- Step 9: Migrating standalone Test Manager
- Step 10: Deleting the default tenant
- Performing a single tenant migration
- Migrating between Automation Suite clusters
- Migrating from Automation Suite on EKS/AKS to Automation Suite on OpenShift
- Monitoring and alerting
- Cluster administration
- Product-specific configuration
- Orchestrator advanced configuration
- Configuring Orchestrator parameters
- Configuring appSettings
- Configuring the maximum request size
- Overriding cluster-level storage configuration
- Configuring NLog
- Saving robot logs to Elasticsearch
- Configuring credential stores
- Configuring encryption key per tenant
- Cleaning up the Orchestrator database
- Skipping host library creation
- Troubleshooting
- The backup setup does not work due to a failure to connect to Azure Government
- Pods in the uipath namespace stuck when enabling custom node taints
- Unable to launch Automation Hub and Apps with proxy setup
- Robot cannot connect to an Automation Suite Orchestrator instance
- Log streaming does not work in proxy setups
- Velero backup fails with FailedValidation error
- Accessing FQDN returns RBAC: access denied error
Automation Suite on EKS/AKS installation guide
Backing up the cluster
Prerequisites
There is a known issue with the backup logic in Automation Suite on AKS/EKS versions 2024.10.0 and 2024.10.1. Specifically, this issue excludes the backup of Insights dashboards and Studio Web data. However, all historical data is successfully backed up.
To include the data of Insights and Studio Web in backup, you must reconfigure the backup solution using the script available here. This script allows you to reconfigure the backup solution and create the backup. For details on how to execute the command, see this section.
Before taking a backup, you must provide the objectstore configuration to store the backup. For this, see Configuring the backup store.
Enabling the schedule snapshot backup
When configuring the schedule snapshot backup, it is recommended to provide the schedule and retention of the backup via the --schedule and --retention flags. By default, Automation Suite takes a backup every 45 minutes after starting and retains the last seven days of snapshots.
To enable the backup at the scheduled time, run the following command:
./uipathctl snapshot backup enable --schedule "*/45 * * * *" --retention 168h --prefix "mysnapshot"
./uipathctl snapshot backup enable --schedule "*/45 * * * *" --retention 168h --prefix "mysnapshot"
Running the snapshot backup command ensure that backups are taken in scheduled time intervals.
| Flag | Description |
|---|---|
schedule | UNIX cron expression for schedule. This is only required if you want to enable a schedule backup. Default value is "*/45 * * * *", which means a backup is taken every 45 minutes. |
retention | Retention policy in the following duration format: Hh:Mm:Ss. For example, 8h5m1s. |
prefix | This will prefix the snapshot backups' names with the given string. This is only used if you want to enable a scheduled backup. The default value is a snapshot. The provided string must be in lowercase. |
Note 1: Any cron expression provided as part of the --schedule parameter matches the time of the cluster node. We recommend syncing the cron expression with the scheduled backup of your external data stores (such as SQL database and objectstore).
Note 2: Automation Suite stores only the snapshot backed up during the defined retention policy. If your retention policy has a shorter duration, you may lose essential snapshots once the retention policy applies. Similarly, if the retention policy is longer, more snapshots are stored, which may take up space on your objectstore.
Note 3: Carefully consider the schedule setup. Taking snapshots at small intervals (for example, every 30 minutes) implies frequent backup operations, forcing you to store the last 30 minutes' data. Similarly, taking snapshots once a week can cause data loss if a disaster occurs much later than the previous backup. Therefore, we strongly recommend synchronizing the backup schedule and the retention duration with your Recovery Point Objective (RPO) requirements.
Disabling the schedule snapshot backup
To disable the scheduled backup, run the following command:
./uipathctl snapshot backup disable --prefix <prefix_name>
./uipathctl snapshot backup disable --prefix <prefix_name>
You must provide the prefix you used while enabling the backup via the --prefix parameter; however, if you did not configure any prefix while allowing the backup, provide a snapshot as a prefix value.
On-demand snapshot backup
To take an on-demand snapshot backup, run the following command:
./uipathctl snapshot backup create <snapshot_name>
./uipathctl snapshot backup create <snapshot_name>
The aforementioned command takes an optional flag:
| Flag | Description |
|---|---|
--wait | Wait until the backup completes |
If you do not provide the --wait command, the command executes in the background. To view the status of your backup, check the snapshot list as described in the following section.
Listing the existing snapshots
To list all the present snapshots, their status, and the time at which they were taken, run the following command:
./uipathctl snapshot list
./uipathctl snapshot list
Sample output:
NAME STATUS CREATION EXPIRATION
manualbackup1 Completed 2022-09-13 09:19:50 +0000 UTC 2023-09-13 09:19:50 +0000 UTC
manualbackup2 PartiallyFailed 2022-09-13 09:19:50 +0000 UTC 2023-09-13 09:19:50 +0000 UTC
NAME STATUS CREATION EXPIRATION
manualbackup1 Completed 2022-09-13 09:19:50 +0000 UTC 2023-09-13 09:19:50 +0000 UTC
manualbackup2 PartiallyFailed 2022-09-13 09:19:50 +0000 UTC 2023-09-13 09:19:50 +0000 UTC
Deleting a backup
Deleting a backup consists of deleting the cluster metadata and the volume data from the backup storage server. This operation is irreversible.
To delete the snapshot backups from the backup store, run the following command:
./uipathctl snapshot delete <snapshot_name>
./uipathctl snapshot delete <snapshot_name>
You can retrieve the name of the snapshot that you want to delete by running the snapshot list command.
The command takes the following additional parameters:
| Flag | Description |
|---|---|
-a, --all | Delete all snapshots. If selecting this option, then you do not need to provide the name of the snapshot. |
-f, --force | Forcibly delete the snapshot without confirmation. |