- 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: 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
- Performing database maintenance
- Configuring the FQDN post-installation
- Forwarding logs to external tools
- Switching to the secondary cluster manually in an Active/Passive setup
- Converting an existing installation to multi-site setup
- Guidelines on upgrading an Active/Passive deployment
- Guidelines on backing up and restoring an Active/Passive deployment
- Product-specific configuration
- 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
-
You must back up only the primary cluster and external storage (SQL and Objectstore).
-
It is not mandatory to take a backup of the secondary cluster. Instead, you can choose to take a backup of the secondary. However, you can still use the primary cluster to set up the secondary cluster.
-
If the primary cluster goes down, you must use the backup to restore it.
- If configuration changes were made on the secondary cluster while the primary cluster was down, follow these steps to ensure
the restored primary reflects the latest configuration:
- Merge configurations from the primary and secondary clusters to create an updated
input.jsonthat includes all changes made on the secondary after the primary went down. - Apply any required updates to parameters that are specific to the primary cluster.
- Restore the primary cluster using the merged
input.jsonfile.
- Merge configurations from the primary and secondary clusters to create an updated
-
If the secondary cluster’s backup is unavailable, you can restore it from the primary cluster by taking the following steps:
-
Generate the
input.jsonfrom the primary cluster. -
Update the
input.jsonwith the specific value of the secondary cluster. -
Install the secondary cluster.
-
-
If the backup for the secondary cluster is available, you can restore the secondary cluster from the backup.
