Cosmos DB Backup Verification and Restore Drill

Overview

This flow proves that Azure Cosmos DB continuous backups can actually be recovered. On a weekly schedule it (1) confirms the source account has continuous (point-in-time) backup enabled, (2) performs a point-in-time restore into a disposable scratch account, (3) polls the restore to completion, (4) validates document integrity on the restored copy, (5) tears the scratch account down to avoid ongoing cost, and (6) reports the recoverability outcome to a Microsoft Teams channel - every report stamped with a correlation id.

Why it matters: Untested backups are a false sense of safety. A periodic restore drill is the only way to confirm real recoverability (RPO/RTO) and surface configuration gaps before a real disaster.

The flow ships Off. Going live requires only authorizing the three connections (ARM, Cosmos DB, Teams) and setting the environment-variable values.

Use Case

A platform or SRE team that runs business-critical data on Cosmos DB needs recurring, auditable proof that the data can be recovered to a recent point in time. Rather than trust that "continuous backup is on," this drill exercises the full restore path on a schedule and posts a pass/fail recoverability report to the team's channel.

Flow Architecture

Environment Variables

Connectors & Connections

Note — All connections are referenced as solution connection references; the flow is portable between environments as long as a connection is mapped at import time.

Customization Guide

Almost every realistic variant of this flow can be implemented by changing environment variable values. A few cases require small edits inside the flow definition — those are called out explicitly below.

Schedule

Change the Weekly Drill Window recurrence (frequency/day/hour/time zone) to match your maintenance window or RPO targets.

Restore point

Set flowlibs_RestorePointMinutes to drill a different point in time (e.g. 1440 for ~24h ago).

Auto-discover the restorable account

Instead of the flowlibs_RestorableSourceAccountId env var, add an HTTP GET (ARM OAuth) to the restorableDatabaseAccounts endpoint, filter by properties.accountName, and feed the matched id into restoreSource.

Scope the validation

Point flowlibs_CosmosDatabaseId/ContainerId at a representative sample, or add more QueryDocuments_V5 checks (per-partition counts, checksums) for deeper integrity assurance.

Guard validate on success

Validation already runs only inside the Restore Succeeded branch; teardown runs regardless as a cost guard. Add a failure path (e.g. retry or alert) if teardown itself fails.

Report destination

Swap the Teams action for email, an incident ticket, or a Dataverse log table to retain a recoverability audit trail.

Key Expressions

The flow is intentionally light on Power Fx / WDL gymnastics — the heaviest expressions are the branch-name concatenation and the approval outcome check. They are listed below in the order they appear in the flow.

@addMinutes(utcNow(), mul(-1, int(variables('varRestorePointMinutes'))))

@body('Get_Source_Cosmos_Account')?['properties']?['backupPolicy']?['type']

@json(concat('{"createMode":"Restore", ... "restoreParameters":{"restoreMode":"PointInTime","restoreSource":"', variables('varRestoreSource'), '","restoreTimestampInUtc":"', variables('varRestoreTimestamp'), '"}}'))

@coalesce(body('Get_Scratch_Account_Status')?['properties']?['provisioningState'],'Creating')

@int(coalesce(first(outputs('Validate_Restored_Documents')?['body/value']),0))

@or(equals(variables('varProvisioningState'),'Succeeded'),equals(variables('varProvisioningState'),'Failed'))