Cosmos DB accounts on periodic backup keeping less than 24 hours of history
What does ZopNight detect here?
ZopNight flags an Azure Cosmos DB account that uses periodic backup with a `backupRetentionIntervalInHours` below 24, meaning less than one day of recoverable history. The periodic default takes a full backup every 4 hours and keeps only the latest two. Accounts on continuous backup are never flagged, and no saving is attached.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-1336 |
| Category | compliance |
| Severity | medium |
| Metric | none — pure configuration read |
| Threshold | periodic retention < 24 hours |
| Source | ZopNight |
| Permissions used | Microsoft.DocumentDB/databaseAccounts/read |
Where it applies
The periodic default keeps only hours, not days
Every Cosmos DB account has a backup policy of one of two types. In periodic mode, Azure takes a full backup every 4 hours and, by default, stores only the latest two. That default costs nothing extra, and it also means a mistake discovered the next morning may already be outside what can be restored.
Restores in periodic mode are not self-service in the way point-in-time restore is. Microsoft advises raising retention to at least seven days, ideally within 8 hours of an accidental delete, before opening a support request to recover data.
Reading an account’s backup policy
az cosmosdb show --resource-group my-rg --name my-account --query backupPolicyLook at type (Periodic or Continuous). For periodic accounts,
periodicModeProperties.backupIntervalInMinutes and
periodicModeProperties.backupRetentionIntervalInHours give the schedule.
The 24-hour floor and what ZopNight needs to see
ZopNight reads the account’s backup policy type from Azure. A Continuous policy clears the
account immediately. For a Periodic policy, the rule also needs the retention window in hours
and fires only when that value is present and below 24. The finding names the policy type and
the exact retention it saw.
Accounts that produce no finding
Continuous backup accounts are never flagged. Periodic accounts whose retention value is missing or unreadable are skipped as well: Azure’s inventory often omits the periodic detail, and a missing value is not evidence of a weak policy. Accounts where the policy type itself was not returned are treated as unknown.
Recovery risk; the fix can add storage cost
No saving is claimed. The exposure is data loss from a bad deployment, a runaway delete or corruption noticed after the retention window has rolled past it. Raising periodic retention beyond the two free copies adds backup storage charges.
Lengthening protection
- For point-in-time restore, migrate the account to continuous backup:
az cosmosdb update --resource-group my-rg --name my-account --backup-policy-type Continuous. The continuous tiers keep 7, 30 or 35 days; the 7-day tier has no backup storage charge, and every restore is charged. - To stay periodic, lengthen retention instead, for example
az cosmosdb update --resource-group my-rg --name my-account --backup-interval 480 --backup-retention 24. Retention must be at least twice the interval and no more than 720 hours. - Record the chosen mode and window in your recovery runbook and test a restore.