Sev1: Azure SQL database dropped or bad data written — restore a deleted or point-in-time copy

#Decide which case you are in

Restores always create a new database. Nothing overwrites the live one.

#1. Dropped database

az sql db list-deleted -g rg-sql -s sql-prod -o table

az sql db restore -g rg-sql -s sql-prod -n appdb \
  --dest-name appdb \
  --deleted-time "2026-10-24T07:41:12.000000+00:00" \
  --time "2026-10-24T07:40:00Z"

Use the exact deletionDate from list-deleted for --deleted-time. --time must be at or before the deletion. If you need the database back in an elastic pool, add --elastic-pool, or move it after the restore.

#2. Bad data change: point-in-time restore

az sql db restore -g rg-sql -s sql-prod -n appdb \
  --dest-name appdb_pitr_0730 \
  --time "2026-10-24T07:30:00Z"

Then copy only the damaged rows back, rather than swapping the whole database. Azure SQL Database does not support three-part cross-database queries, so move rows with bcp, an ADF copy or elastic query:

# Export the good rows from the restored copy
bcp "SELECT * FROM dbo.Orders WHERE OrderDate >= '2026-10-01'" queryout orders.dat -n \
  -S sql-prod.database.windows.net -d appdb_pitr_0730 -G

# Load into a staging table on the live database, then MERGE in a reviewed transaction
bcp dbo.Orders_restore in orders.dat -n -S sql-prod.database.windows.net -d appdb -G

Tip

Restore time grows with database size and log volume. Start the restore first, then investigate while it runs.

#3. Swap a restored copy in (if you must)

When the whole database must go back to the restore point:

-- Connected to master on the logical server
ALTER DATABASE appdb MODIFY NAME = appdb_broken;
ALTER DATABASE appdb_pitr_0730 MODIFY NAME = appdb;

Check after the swap: geo-replication and failover group membership (a renamed database leaves the group), auditing, firewall, service objective and any contained users.

#4. Long-term retention

az sql db ltr-backup list -l westeurope -s sql-prod -d appdb -o table
az sql db ltr-backup restore --backup-id "<id>" --dest-database appdb_ltr --dest-server sql-prod --dest-resource-group rg-sql

#5. Deleted logical server

Deleting a logical server deletes its databases. Check whether restoring a dropped server is available in your region (it has been rolling out), and open a Sev A case at once. If geo-replication or a failover group existed, the secondary may still be alive — check it before anything else.

#Prevent it next time

• CanNotDelete lock on production SQL servers.
• Configure LTR for compliance needs; PITR retention is short by default (check and raise it).
• Restrict db_owner and DDL rights; alert on DROP DATABASE via auditing.
• Practise a PITR restore every quarter and record how long it takes.