What Argo CD backup and disaster recovery covers
If your Argo CD runs on a cluster you control and that cluster is lost, you can rebuild it, but only if you planned for that from the start. Argo CD keeps its data in Kubernetes objects, treats Redis as a disposable cache, and is largely stateless, so the recovery question is which objects must be captured outside the cluster, how they are restored, and how long that takes. The supported way to capture them is argocd admin export, run from the quay.io/argoproj/argocd image that matches your running server version, with the matching argocd admin import used to restore. Redis contents do not need to be preserved, because the controller rebuilds its view from the cluster and from Git.
Teams usually need this plan when change control is regulated and every deployed state must be traceable to an approved request, when one Argo CD instance controls many clusters and a single loss would stop delivery everywhere, or when auditors ask how configuration is recovered and tested. In those settings the backup is only part of the evidence. You also need a documented record of which version exported the data, where the export is stored, who may read it because it can contain sensitive configuration, and a rehearsal showing the restore worked. Ask your team to confirm which Argo CD version is running in each environment, because version mismatches are the most common reason a restore is not trusted.
The rest of this page covers what the export captures, how image versions and namespaces affect the restore, what Git already restores without any export, and how to rehearse the procedure against an RTO target you set. The check to run first is simple: identify every object that exists only in the cluster (applications created outside Git, projects, repository and cluster credentials, and local accounts), then decide which of them the export must cover and which your Git repositories and secret management already reproduce. The official Argo CD disaster recovery guide is the reference for the exact commands and their current behavior.
How to run an export and restore an Argo CD instance
This sequence produces a portable copy of your Argo CD configuration and state, then loads it onto a recovery cluster running a matching version so applications can be checked and brought back under control. Each step ends with a check you can confirm before moving on.
Record the running server version
Before anything else, the platform team records the exact Argo CD server version on the live instance, using the version output from the argocd-server or the CLI against the running installation. Keep that version in your runbook next to the backup, because the export and import tools must come from an image that matches it. The step is done when the version is written down alongside the namespace and cluster where Argo CD runs, and someone other than the author has confirmed the value.
Stage a matching Argo CD image
Prepare a recovery cluster or a management workstation that can pull the quay.io/argoproj/argocd image tag matching the recorded server version. Confirm the tag exists in your registry mirror if the cluster is air-gapped, since a mismatched tag is the most common reason an export or import behaves unexpectedly. The step is complete when you can start a container from that image and it reports the same version as the live server.
Run argocd admin export
From the matching image, run argocd admin export against the Argo CD namespace of the live instance and write the output to a file stored outside the cluster being protected. Follow the exact command syntax and flags in the disaster recovery guide, since flags can change between releases. Export does not report an error when pointed at the wrong namespace, so you must check the namespace yourself before you trust the file. The step is done when the export file exists, is non-empty, and is copied to storage that the cluster failure would not affect.
Verify the export contents before restore
Open the export and confirm it contains the expected Application and AppProject objects, plus the repository and cluster definitions you rely on. Compare the Application count with what the team expects from the live instance, and note any difference for investigation. Confirm that the file does not hold plaintext credentials you were not expecting, and handle it under the same access rules as other secrets. The step is complete when counts match your records and the file is stored with restricted access.
Prepare the recovery namespace
On the recovery cluster, install the same Argo CD version into the namespace you intend to use, using the installation method your team already follows. Check that the namespace name matches the one used during export, because import depends on it and a namespace mismatch can leave you with an empty or partial instance. The step is done when all Argo CD components report ready and you can log in to the new instance as an administrator through your agreed access path.
Run argocd admin import
Using the same matching image, run argocd admin import with the export file as input against the recovery namespace, following the import command and flags in the disaster recovery guide. Capture the command output and any warnings in your change record. The step is complete when the command finishes without errors and the output shows the objects being written to the target namespace.
Confirm applications and sync status
Compare the Application count in the restored instance with the count recorded from the export, and check that projects, repositories and clusters appear as expected. Then review sync status for a sample of applications and confirm they reconcile against Git, since Git remains the source of truth for workload manifests. Investigate any application that stays OutOfSync or Progressing before declaring recovery complete. The step is done when counts match, the sampled applications reconcile, and the team has signed off on the results.
Record the rehearsal and gaps
Write down the elapsed time for each step, any command that needed correction, and any object that did not restore as expected. Confirm with your own environment which parts of the restore depend on external secrets, DNS, SSO configuration or cluster registrations, since those must be ready before the instance is useful. The step is complete when the findings are filed as changes to the runbook and the next rehearsal date is set by your organization.
Recovery options and when each fits
This table compares three ways to recover Argo CD after losing its cluster: restoring an export, rebuilding from Git, and standing up a standby instance. Read each row for what comes back automatically, what you rebuild by hand, and the trade-off that decides which option fits your environment.
| Option | What it restores | Main trade-off |
|---|---|---|
| Scheduled argocd admin export to protected storage | Argo CD configuration and state captured by argocd admin export, restored with argocd admin import into a matching server version | Export must run from the image matching the server version, and it does not fail when pointed at the wrong namespace, so restore tests are the only proof it worked |
| Rebuild from Git only | Applications, projects and manifests that are declared in Git repositories and resynced to the cluster | Settings kept only in the cluster, such as local users, cluster registrations and some repository credentials, must be recreated manually |
| Recovery into a fresh cluster | A new Argo CD install from the same version, then imported state and resync from Git | Requires a planned install path, version pinning and a documented sequence for secrets and access |
| Standby instance kept warm | Configuration mirrored ahead of time so cutover is a DNS or routing change, plus Git resync | Higher running footprint and a second set of credentials and access paths to govern and keep current |
| Redis cache after failure | Nothing required, because Redis is a disposable cache that Argo CD rebuilds | Expect a period of reduced responsiveness while state repopulates; confirm the behavior in your version |
| Documented restore rehearsal | Proof that the chosen option works end to end with your secrets, clusters and access model | Takes staff time each cycle; the main evidence an assessor or incident lead will ask for |
Namespace and image version pitfalls that break restores
Most failed Argo CD restores come from a few predictable mistakes made before the cluster was lost, not during recovery. The cards below cover what goes wrong with exports, image versions, cache data, secrets, drift and untested runbooks, and the control that prevents each one.
Exporting from the wrong namespace
The export reports no error when it runs against a namespace that does not hold your Argo CD installation, so a backup can succeed and still contain nothing useful. Check the namespace explicitly in the export command, confirm the Applications, AppProjects and repository Secrets appear in the output, and keep the export job's target namespace in your runbook so it is not inferred from a default.
Mismatched export and server images
Run argocd admin export from the quay.io/argoproj/argocd image that matches the running server version. An export produced by a different version may not restore cleanly into the rebuilt installation. Pin the image tag in the backup job, record the server version alongside each export, and rebuild the target at that same version before importing.
Treating Redis as state
Argo CD keeps its data in Kubernetes objects, and Redis is a disposable cache. Backing up or restoring Redis contents does not recover Applications or settings, and a rebuilt cluster repopulates the cache on its own. Spend the recovery effort on the exported objects and the Kubernetes resources that hold them, and confirm the rebuild does not depend on a Redis snapshot.
Secrets missing from the rebuilt cluster
Exports and Git hold the desired state, but credentials for clusters, repositories and SSO must be present in the new cluster before sync can work. Repository credentials are stored as Kubernetes Secrets in Argo CD 3.0 and later, so confirm that each one is restored or recreated from your secrets store, and test a repository fetch before you trust the restored Applications.
Drift between the export and Git
An export is a snapshot taken at one moment, and changes made through the UI or CLI after that point are not in Git. Restoring an old export can roll back an Application or override a newer change. Compare the export with the current Git revisions before import, prefer Git as the source for application manifests, and record the export time so the team knows which changes it may miss.
Restores that have never been rehearsed
A backup that has never been imported into a clean cluster is a hypothesis, not a recovery plan. Rehearse the full sequence on a separate cluster: install the matching version, import the export, restore secrets, sync a sample Application and confirm RBAC and SSO work. Time each step against your recovery time objective and write down the gaps the rehearsal exposes.
Setting an RTO target and rehearsing the restore
Set the recovery time objective for Argo CD itself before anyone restores it, and set it separately from the targets for the workloads Argo CD deploys. Those workloads may keep serving traffic while the controller is down, so the question is how long your change pipeline can stop before a delivery gap becomes a business problem. That answer comes from your change-control rules: who may deploy during an incident, how long a frozen release window can last, and whether emergency fixes must still pass through Git. Ask your business owners and change board to state the outage they will accept for deployments, then convert that into a target for Argo CD. No RTO figure is supplied for this topic, so treat any number you hear from a vendor or peer as a starting point to test, not a commitment.
A rehearsal turns that target into evidence. Schedule a restore into an isolated cluster at a regular interval, using the same argocd admin export archive, the matching quay.io/argoproj/argocd image tag and the same Kubernetes namespace layout as production. Time each step separately: retrieving the export, provisioning the target cluster, installing the matching Argo CD version, running argocd admin import, reconnecting clusters and repositories, and confirming that applications reconcile. Record where the clock actually went, because the slowest step is usually provisioning or credential re-entry rather than the import itself. Have the platform owner and an application owner sign off on the result, and file the timings, the archive checksum, the image digest and the list of deviations with the change record.
Security of backup files and recovery access
An export is a copy of your Argo CD configuration, and a restore is a privileged operation. The cards below cover what the file may contain, who can import it, where recovery credentials live, and what Argo CD already protects in transit and in its logs.
Confirm what the export holds
Before you store an export, run it in a test environment and inspect what it contains. Check for repository entries, cluster registrations, project and RBAC settings, and any credential material that your setup places in Kubernetes Secrets. Argo CD redacts cluster, Git and OAuth2 credentials from API responses and logs, but a file written by argocd admin export is a different output, so do not assume it is redacted. Record the result so the storage rules match the real contents.
Encrypt and restrict export files
Treat every export as a sensitive artifact. Encrypt it at rest in storage that your organization controls, and encrypt it in transit when it moves between systems. Limit read access to the small group that performs recovery, and keep an access log on the storage location. Avoid leaving exports on developer workstations or in shared CI artifacts, where they would outlive the access policy that protects the cluster.
Limit who can run import
Restoring with argocd admin import can overwrite live configuration, so the ability to run it should be narrower than the ability to view applications. Name the people and automation accounts allowed to perform a restore, and require a second approver for production targets. Confirm with your identity provider and Argo CD RBAC setup that these roles are not granted by default to every operator who can sync applications.
Separate recovery credentials from production
Keep the credentials used to reach a recovery cluster and its Argo CD instance apart from the production identity store. Do not reuse production admin passwords or long-lived tokens on the recovery side. Keep the built-in admin user disabled during normal operation, as the user management guidance recommends, and store any break-glass path in a separate, audited vault that is tested on a schedule.
Verify what Argo CD redacts
Argo CD authenticates API requests only with JSON Web Tokens, uses TLS between its components, and redacts cluster, Git and OAuth2 credentials from API responses and logs. Use these facts to scope your review, but test them in your own environment. Check that your log shipping, support bundles and ticket attachments do not capture raw manifests or exported files alongside the redacted views.
Document recovery access evidence
Keep a record of every export, every import, and every person who held recovery access, with dates and the Argo CD version used. This record supports incident review and change control evidence. Confirm with your auditors which logs they expect, and retain them in a location that the recovery team cannot edit alone.
Questions teams ask before planning Argo CD recovery
How much does Argo CD disaster recovery planning cost?
No figure can be given from the supplied facts, and DeployOpen does not publish prices. The cost follows from a written scope that sets how many Argo CD instances, clusters and applications are covered, which environments need a restore plan, and how often the restore is rehearsed. Ask for a quote that separates the one-time work (inventory, backup job, runbook, first rehearsal) from any recurring work (retainer, periodic rehearsals, version updates). Argo CD itself is licensed under Apache-2.0, so software license fees are not part of the quote.
How long does it take to get a tested recovery plan?
The duration depends on how many Argo CD instances you run, how many clusters they manage, how many external secrets and repository credentials must be mapped, and whether your team can give access to a non-production cluster for the restore test. A fixed-scope engagement agrees the timeline in writing before work starts. Ask the partner to show which milestones produce evidence: a documented export, a restore onto a clean cluster, and a measured recovery time compared with your target.
What does our team have to provide during the engagement?
Plan on named owners for the Argo CD installation, the clusters it deploys to, the Git repositories it reads, and the identity provider it uses for sign-in. Your team will need to confirm the current Argo CD version, how the instance was installed, which namespace it runs in, and where secrets are stored. Access to a restore target that mirrors production is also needed, along with a change window for the rehearsal. Owners should be able to answer these questions before the first workshop.
Can our platform team plan and rehearse recovery without outside help?
Yes, a team that already runs Argo CD can document an export procedure, keep a matching image version on hand, and test a restore in a lab. The harder parts are usually the ones that are easy to miss: confirming the export ran against the correct namespace, handling secrets that live outside Git, and proving the restore works under a real outage. Ask whether your team has time to rehearse on a schedule and whether anyone other than the author can run the runbook.
Does Git already protect us, so do we only need a backup of Argo CD?
Git holds the application manifests and their history, so a lost cluster can often be rebuilt from repositories. What Git does not hold is the Argo CD state that lives in Kubernetes objects, such as configured clusters, projects, and some repository and SSO settings, depending on how each was created. Argo CD keeps its data in Kubernetes objects and treats Redis as a disposable cache. Confirm with your own inventory which settings exist only in the cluster before deciding the scope of the export.
How often should we rehearse an Argo CD restore?
Rehearse at a cadence your change process can sustain and rehearse again after any change that affects the restore path, such as an Argo CD minor version upgrade, a move to a new cluster, or a change to how repositories or secrets are defined. Argo CD minor releases ship four times a year and only the three most recent minor versions receive patch releases, so a version that falls out of support is itself a reason to retest. Ask the partner how each rehearsal is recorded so auditors and operators can see when the last successful restore happened.
What recovery time objective can we realistically commit to?
A recovery time objective should be set by the business owner of the services Argo CD deploys, then checked against a measured restore. No target can be promised from outside your environment. Time depends on cluster provisioning, image pulls, the size of the export, how many applications must resync, and whether sign-in and secrets are restored in the same window. Ask for the measured duration from the last rehearsal and the steps that consumed the most time.
How DeployOpen plans and rehearses an Argo CD recovery
A recovery engagement starts with a written scope that names the Argo CD instances, namespaces, clusters and Git repositories in play, because the backup is only as complete as that list. DeployOpen agrees the scope, deliverables and timeline in writing before any work starts, and the scope states who owns each piece: the export job, the storage location, the access policy for the exported files, and the restore procedure. Configuration of `argocd admin export` runs inside your cloud account, data center or air-gapped network, using the quay.io/argoproj/argocd image that matches your running server version. The export destination, retention and encryption follow your own data classification rules, not a default chosen for the project.
The restore runbook is the central document. It records the exact image tag used for export, the target namespace, the order of steps for installing Argo CD, running argocd admin import, reconnecting clusters and repositories, and confirming that applications reconcile. It also records the checks that catch the known pitfalls: an export that completes silently against the wrong namespace, a version mismatch between export and restore, and credentials that must be recreated because they are not restored from the export. Each step has an owner and an expected result, so an on-call engineer can follow it without the author in the room. The runbook should also list what Git restores on its own, since application manifests and their history live in your repositories, and what must come from elsewhere.
A rehearsal proves the runbook works. DeployOpen runs the restore into an isolated cluster from a fresh export, records the elapsed time for each step against the recovery time objective your organization has set, and captures evidence such as command output, versions, and the list of applications that returned to a synced and healthy state. Gaps found during the rehearsal are fixed in the runbook and retested. Ask whether your retainer or project scope includes repeating the rehearsal after each Argo CD minor upgrade, since the image and export format must be checked against the version you run.
How DeployOpen scopes and supports Argo CD recovery
DeployOpen plans, implements, documents and supports self-hosted open-source platforms inside your own infrastructure, so Argo CD recovery is designed around your clusters, your Git hosts and your recovery targets. Engagements are fixed-scope, with the recovery procedure, export schedule and restore rehearsal agreed in writing before work starts.
How we scope
- Inventory every Argo CD instance, cluster registration, project and repository that a recovery would need to rebuild.
- Record which objects live only in the cluster, such as the export contents, and which already exist in Git.
- Agree the recovery time objective and recovery point objective targets in writing before any build work starts.
- Confirm the Argo CD minor version in use and the matching quay.io/argoproj/argocd image tag for every export and import step.
How we build
- Script scheduled argocd admin export runs against the correct namespace, with the export verified and stored outside the cluster.
- Document the restore sequence, including argocd admin import, image version matching and the order of cluster and repository reconnection.
- Set namespace checks and alerts so an export against the wrong namespace fails visibly instead of appearing successful.
- Define which secrets, such as repository credentials and SSO client settings, are restored from your secret store rather than from the export.
How we hand over
- Deliver a recovery runbook with step-by-step commands, owners, verification checks and decision points for on-call staff.
- Run a restore rehearsal on a separate cluster and record the measured elapsed time against the agreed targets.
- Walk your platform and security team through the rehearsal results, open gaps and the backup schedule they now own.
- Hand over the configuration as code, so Git-held applications and projects can be re-synced after a rebuild.
How we support
- Ongoing support, upgrades and recovery rehearsals are available as a retainer, scoped in writing.
- Re-test the restore procedure after each Argo CD minor upgrade, since image versions must keep matching the server.
- Review export logs, storage retention and rehearsal results with your team on an agreed cadence.
- Ask any provider, including DeployOpen, to confirm current export behavior against the official disaster recovery guide before relying on it.
