How are you managing backups as infrastructure as code?

The important distinction is between the system that creates the backup and the backup data itself. The configuration, scripts, retention rules, credentials, and infrastructure are code; the resulting backup archives are data or payload. That’s why backup configuration belongs in version control even though the backup contents do not.

The backup mechanism should be codified, whether that means a Terraform resource, an Ansible role, or a script stored in version control. A cron schedule itself can also be managed as code. The main benefit is repeatability and review; backups typically don’t need to be changed frequently, so a simple, declarative setup may be enough.

Creating backups is only half the problem. I’d put more effort into codifying restore validation: periodically restore into an isolated environment and check things such as row counts, schema health, or the presence of known records. A backup that has never been restored is only an assumption. Whatever runs the test should also provide monitoring and alerting—an unattended cron job can fail silently for months.

For managed services, use the provider’s native automated backups when they meet the requirements, and declare their settings through your normal provisioning tools. For custom systems, package the backup job and its schedule with configuration management, then monitor both successful runs and restore tests. The exact tool matters less than having the entire lifecycle reproducible and observable.

There’s no fundamental reason backups can’t be managed as IaC. IaC is largely a structured way to make API calls to providers, so if the backup platform exposes a usable API, its policies and jobs can be declared and reviewed just like other infrastructure. Managed database backups, for example, can usually be configured directly through Terraform.