- 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
Automation Suite on EKS/AKS installation guide
For detailed instructions on how to back up and restore Automation Suite, see Backing up and restoring the cluster.
-
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 you applied a new configuration on the secondary cluster while the primary cluster is down, then at the time of the restore, you can reuse the
input.jsonfile of the secondary cluster and update the critical parameter, which is very specific to the primary cluster, and then you can restore the cluster.
-
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.
