Skip to main content
Argo CD is largely stateless with all data persisted as Kubernetes objects in etcd. This guide covers backup and restore procedures to protect your Argo CD configuration and application definitions.

Understanding Argo CD Data

Argo CD stores its state in:
  • Kubernetes etcd: All Application CRDs, AppProjects, and configuration
  • Redis: Temporary cache only (can be safely rebuilt)
  • Git repositories: Source of truth for application manifests
Redis is used only as a disposable cache and can be safely rebuilt without service disruption.

Backup Procedures

Using argocd admin export

The argocd admin tool provides built-in export functionality to backup all Argo CD data.
1

Check Argo CD version

Determine your Argo CD version to use the correct Docker image:
2

Configure kubeconfig

Ensure your ~/.kube/config points to your Argo CD cluster:
3

Export data to backup

Create a backup file containing all Argo CD resources:
For non-default namespace:
If you are running Argo CD in a namespace other than argocd, remember to pass the -n <namespace> parameter. The export command will not fail if you run it in the wrong namespace, but the backup will be incomplete.

What Gets Backed Up

The export includes:
  • Application definitions
  • AppProject configurations
  • Repository credentials (encrypted)
  • Cluster credentials (encrypted)
  • ConfigMaps (argocd-cm, argocd-rbac-cm, etc.)
  • Secrets (argocd-secret, repository secrets, cluster secrets)

Automated Backup Strategy

Implement automated backups using a CronJob:

Restore Procedures

Restoring from Backup

1

Prepare target cluster

Install Argo CD on the target cluster if not already present:
2

Import backup data

Restore the backup using the import command:
For non-default namespace:
3

Verify restoration

Check that applications and configurations are restored:

Alternative Backup Methods

Kubernetes etcd Backup

Since Argo CD data lives in Kubernetes, backing up etcd provides a complete snapshot:

Velero Integration

Use Velero for cluster-wide backup including Argo CD:

Disaster Recovery Scenarios

Scenario 1: Complete Cluster Loss

  1. Provision new cluster: Set up a new Kubernetes cluster
  2. Install Argo CD: Deploy Argo CD fresh installation
  3. Restore backup: Import the latest backup file
  4. Verify applications: Check that all applications are present
  5. Trigger sync: Applications will automatically reconcile with Git

Scenario 2: Corrupted Application State

  1. Identify affected applications: Review application health status
  2. Delete corrupted application: Remove the Application CR
  3. Restore from backup: Import backup or recreate from Git
  4. Resync application: Trigger full sync

Scenario 3: Lost Repository Credentials

Repository credentials are stored in Kubernetes secrets:

Best Practices

Regular Backups

Schedule automated backups daily or before major changes. Store backups in multiple locations.

Test Restores

Regularly test restore procedures in a non-production environment to verify backup integrity.

Version Compatibility

Use the same Argo CD version for backup and restore operations to avoid compatibility issues.

Secure Storage

Encrypt backup files and store them in secure, access-controlled locations with retention policies.

Backup Retention Policy

Implement a retention strategy:
  • Daily backups: Retain for 7 days
  • Weekly backups: Retain for 4 weeks
  • Monthly backups: Retain for 12 months
  • Pre-upgrade backups: Retain indefinitely

Recovery Time Objective (RTO)

Typical recovery times: