Creating Backups

Infrahub backup operations create consistent snapshots of Infrahub deployments by capturing data from Neo4j and PostgreSQL databases along with system metadata. The process supports multiple storage backends, including local filesystems, S3-compatible object storage, and Plakar repositories. Backups are bundled as tar.gz archives or streamed as deduplicated snapshots depending on the selected backend.

Sources: AGENTS.md, src/internal/app/backup.go:94-100, specs/002-plakar-integration/tasks.md

Backup Architecture and Workflow

The backup system utilizes a shared core logic layer invoked by the infrahub-backup CLI. It performs environment detection to identify if the system is running in Docker or Kubernetes and adjusts its execution strategy accordingly.

Execution Flow

The following diagram illustrates the sequence of operations during a standard backup creation:

Database Backups

The system performs specific actions for different database components to ensure data consistency:

• Neo4j (database): The tool detects the Neo4j edition. For Community Edition, it stops Infrahub services before backing up to ensure a clean state. For Enterprise Edition, it performs an online backup.
• PostgreSQL (task-manager-db): The system captures a dump of the task manager database unless the --exclude-taskmanager flag is provided.
• Metadata: Every backup includes a backup_information.json file containing the backup ID, tool version, checksums, and component list.

Sources: src/internal/app/backup.go:106-111, src/internal/app/backup.go:149-165, specs/001-k8s-helm-backup/spec.md

Storage Backends

Infrahub supports three primary methods for storing backup data:

Sources: specs/004-backup-retention-policy/plan.md, specs/002-plakar-integration/tasks.md

Plakar Streaming Integration

When using the Plakar backend, the system avoids local temporary files by streaming data directly from container standard output into the Plakar repository.

Retention Policies

Retention policies automate the cleanup of old backups to manage storage space. Policies are evaluated independently for local and S3 storage locations.

• Max Age: Backups older than a specified number of days are pruned.
• Max Count: The system keeps only a specific number of recent backups.
• Safety Floor: The system always keeps the newest backup regardless of the policy to prevent accidental total data loss.

Sources: specs/004-backup-retention-policy/plan.md, src/internal/app/backup.go:215-217

Security and Encryption

Backups can be encrypted to protect sensitive infrastructure data. The system uses ECDH public keys for encryption.

• Encryption: When requested, the tar.gz archive is encrypted, creating a .enc file, and the plaintext version is removed.
• Redaction: The --redact flag replaces attribute values in the database with random UUIDs before the backup is taken. This is a destructive operation requiring the --force flag.

Sources: src/internal/app/backup.go:189-204, src/internal/app/backup.go:115-121

Conclusion

Creating backups in Infrahub is a multi-step process designed for operational safety and storage efficiency. By integrating database-specific backup routines with flexible storage backends and automated retention, the system ensures that disaster recovery artifacts are both reliable and maintainable. The addition of streaming backends like Plakar further optimizes the process by reducing local storage overhead and enabling high-efficiency deduplication.

Sources: specs/001-k8s-helm-backup/spec.md, specs/004-backup-retention-policy/plan.md