Subtopic•ArgoCD Backup

Backup Overview

In the previous module, we configured background analysis rules, query intervals parameters, and checked error rates. With metrics validations clear, we will now start Module 16: Disaster Recovery and Backup, beginning with the Backup Overview.

In enterprise Kubernetes environments, disaster recovery preparedness is critical. If your manager cluster experiences a physical outage, a data storage corruption, or an accidental deletion of resources, you must be able to recover your configurations and restore application state quickly.

In this guide, we will cover disaster recovery targets, define backup schedules, and review metadata recovery models.

1. Defining Disaster Recovery Targets

Disaster recovery plans focus on recovering the configurations that define your GitOps states.

The primary backup targets include:

  • System Configurations: Settings inside argocd-cm, RBAC rules in argocd-rbac-cm, and custom SSO identity connection properties.
  • Registered Target Clusters: Connection endpoints URLs and credential secrets registered in your namespaces.
  • Connected Git Repositories: Credential secrets, access keys, and HTTPS certificates used to connect to your Git configuration repositories.
  • Application Declarations: All Application and AppProject Custom Resources (CRDs) running in the system namespace.

2. Setting Up Backup Schedules

To prevent configuration loss, implement a scheduled backup rotation:

               Backup Rotation and Storage
┌────────────────────────────────────────────────────────┐
│  Manager (Hub) Cluster: Reconciles workloads           │
├────────────────────────────────────────────────────────┤
│  Scheduled Cron Job: Runs daily export tasks           │
│  - Executes 'argocd-admin export' CLI calls            │
├────────────────────────────────────────────────────────┤
│  Archive Encryption: Encrypts backup packages          │
├────────────────────────────────────────────────────────┤
│  Storage Upload: Saves archives to external buckets   │
│  - Uploads to AWS S3 / Google Cloud Storage / Azure    │
└────────────────────────────────────────────────────────┘
  1. Daily Exports: Run scheduled scripts (using Kubernetes CronJobs) to export the entire cluster state to a compressed archive file (e.g., backup-2026-06-30.yaml).
  2. Offsite Storage: Upload the exported archive files to external, highly durable cloud object storage buckets (like AWS S3 or Google Cloud Storage).
  3. Retention Policies: Configure lifecycle rules on the storage buckets to retain backups for a specific window (e.g., 30 days) and delete older archives automatically to save cost.

3. Operational Best Practices: Backups

  • Secure export credentials: Ensure the backup scripts run using ServiceAccounts with read-only access to cluster configurations, protecting keys.
  • Encrypt storage archives: Always encrypt backup archives before uploading them to cloud buckets to prevent credentials leaks.
  • Verify recovery playbooks: Regularly execute restoration trials in isolated staging environments to confirm that your backup files function correctly.

4. Disaster Recovery Components Reference Summary

Target ComponentConfiguration LocationBackup PriorityKey Recovery Value
System SettingsConfigMaps secretsHighSystem identity and RBAC parameters.
Registered ClustersCluster secretsCriticalCross-cluster endpoint connections.
Applications CRDsApplication databaseHighActive workloads declarations.
Git RepositoriesRegistry secretsCriticalAuthentication connection keys.

In this section, we analyzed disaster recovery targets, designed automated backup schedules, mapped resource priorities, and reviewed security guidelines.

Now we will transition to exporting configuration files. In the next guide, we will cover how to run CLI export commands and configure scheduled cron tasks.

←Previous ModuleArgo Rollouts