# Ensure Database Has Automated Backups Enabled - Source: https://support.icompaas.com/support/solutions/articles/ensure-database-has-automated-backups-enabled - Section: [Solutions](https://support.icompaas.com/support/solutions) › [DigitalOcean Cloud](https://support.icompaas.com/support/solutions/c_do_cloud) › [DigitalOcean Rules](https://support.icompaas.com/support/solutions/folders/digitalocean-rules) - Last updated: 2026-08-13 - Publisher: iCompaas, Inc. (https://www.icompaas.com) ## Description This rule confirms that automated, scheduled backups with point-in-time recovery are in place for every Managed Database cluster and that a recent successful backup exists. DigitalOcean takes free daily full backups and continuously archives write-ahead logs for PostgreSQL and MySQL, giving point-in-time recovery to any moment within the retention window; this backup capability is always on and cannot be turned off. Because backups cannot be disabled, the rule's real value is verifying that a recent backup is actually present and that the team has validated the restore path by performing test restores, so recovery works when it is genuinely needed. - Clusters for which no recent backup is listed within the retention window - Teams that have never performed a test restore to validate recoverability ## Rationale Even routine operational mistakes — an accidental table drop, a bad migration, or data corruption — can cause permanent data loss without a working backup. Point-in-time recovery lets an operator rewind the database to just before the incident. A backup is only useful if it can be restored. Periodically restoring into a new cluster proves the backups are valid and measures how long a real recovery takes, which feeds the workload's recovery objectives. ## Impact Pros: - Point-in-time recovery to any second within the retention window - Protects against accidental deletion, corruption, and failed migrations - Provided free and managed by DigitalOcean with no operational effort Cons: - Retention is fixed at 7 days and cannot be extended; longer retention needs an external export process - Restoring creates a new cluster, so applications must be repointed after recovery - Test restores consume additional resources for the duration of the exercise ## Default Value All Managed Database clusters have free daily backups with point-in-time recovery enabled by default; retention is fixed at 7 days and cannot be disabled or extended. ## Pre-Requisite - DigitalOcean Control Panel access with a role that can view the cluster and create clusters (for test restores) - Optional: a DigitalOcean API token or doctl authenticated (doctl auth init) - A documented recovery procedure and a target for periodic test restores ## Remediation ### Test Plan Using the DigitalOcean Control Panel: 1. In the Control Panel, go to Databases and click the cluster name. 2. On the Overview / Settings page, confirm the backup and point-in-time recovery window is present (there is no enable/disable toggle to change). 3. Confirm the most recent daily backup falls within the 7-day retention window. 4. Pass: A recent daily backup is listed and the point-in-time recovery window is available. 5. Fail: No recent backup is shown (open a DigitalOcean support ticket, as backups should always be present). Using doctl or the API: List the cluster's backups and confirm a recent one exists. doctl databases backups list curl -s -X GET "https://api.digitalocean.com/v2/databases//backups" -H "Authorization: Bearer $DIGITALOCEAN\_TOKEN" Pass if the backups list returns at least one backup with a created\_at inside the 7-day retention window. Fail if the list is empty. ### Implementation Steps Using the DigitalOcean Control Panel: 1. Because backups cannot be enabled or disabled, remediation is to validate the restore path rather than turn a setting on. 2. On the cluster's Overview page, use the create-from-backup / fork flow to restore the cluster (optionally to a specific point in time) into a new cluster. 3. Verify the restored cluster contains the expected data, then delete the throwaway restore. 4. Schedule this test restore periodically and record the time it takes. Using doctl or the API: Validate recovery by creating a new cluster from a backup. curl -s -X POST "https://api.digitalocean.com/v2/databases" -H "Authorization: Bearer $DIGITALOCEAN\_TOKEN" -H "Content-Type: application/json" -d '{"name":"restore-test","engine":"pg","region":"nyc1","size":"db-s-1vcpu-1gb","num\_nodes":1,"backup\_restore":{"database\_name":"","backup\_created\_at":""}}' ### Backout Plan: 1. Delete the temporary restore cluster once validation is complete (Control Panel Destroy, or DELETE /v2/databases/). 2. No change is made to the production cluster, so no production rollback is required. ## References: 1. [Managed Databases overview (backups and PITR)](https://docs.digitalocean.com/products/databases/) 2. [doctl databases backups](https://docs.digitalocean.com/reference/doctl/reference/databases/backups/) 3. [DigitalOcean API — Databases](https://docs.digitalocean.com/reference/api/digitalocean/#tag/Databases) ## Related compliance guidance - [SOC 2 compliance: a practical implementation guide for cloud-native SaaS teams](https://support.icompaas.com/compliance/soc-2-trust-services-criteria): Configuration checks like this one are the technical half of a SOC 2 / ISO 27001 programme — the guide shows where they fit, what else an auditor expects, and how to evidence them. - [ISO/IEC 27001:2022 compliance: a practical implementation guide](https://support.icompaas.com/compliance/iso-27001-2022): ISO 27001 Annex A.8 (technological controls) is where cloud hardening evidence lands; the guide shows how to run the ISMS around it.