Azure DevOps Server backup planning isn’t glamorous. But when a collection database is corrupted, a storage array misbehaves or a data-tier migration suddenly becomes urgent, the backup and restore runbook becomes the most popular document in the building.
This runbook turns Microsoft’s guidance into practical steps for on-premises admins: what to back up, how to keep databases synchronized, how to restore, what to test, and which guardrails keep recovery boring. Boring recovery is good recovery.
Admin quick take
Your backup is only as good as the restore you’ve actually rehearsed.
- Back up the whole data tier together: configuration, collections, warehouse, and reporting or analysis databases where used.
- Keep recovery points synchronized: related databases must restore to the same point in time.
- Test the restore: a trial restore exposes hardware, media, permission and documentation problems that a “backup succeeded” email won’t.
Azure DevOps Server backup scope: what needs protection
Azure DevOps Server stores what it needs to restore a deployment in SQL Server databases. You don’t need to back up client machines or every application-tier server to recover the data; you need reliable, synchronized backups of the data tier.
| Component | Database or recovery item | Runbook note |
|---|---|---|
| Configuration | Tfs_Configuration or equivalent | Required; deployment-critical. |
| Project collections | One database per collection | Required. Add new collections to the plan immediately. |
| Warehouse | Tfs_Warehouse | Required where the warehouse and reporting stack is used. |
| Reporting Services | ReportServer, ReportServerTempDB, encryption key | Required if reporting is configured; the key matters. |
| Analysis Services | Tfs_Analysis | Required if analysis is configured. |
| Legacy SharePoint integration | SharePoint databases | Only for older integrated deployments; the integration was deprecated after TFS 2017. |
| Documentation | Service accounts, server names, configuration | Store securely, away from the servers. |
The trap is growth. Each new project collection creates a new database, and if the maintenance plan never learns about it, that collection has an incomplete recovery story.
Set RPO and RTO targets first
- Recovery point objective (RPO): how much data can you lose? Fifteen minutes, four hours, a day?
- Recovery time objective (RTO): how long can the service be down?
- Recovery scope: one failed SQL instance, an application tier, or full site loss?
These drive the schedule, media, offsite replication, SQL Server design and test cadence. If the business asks for zero data loss but funds a single aging SQL server, that conversation needs to happen before the incident.
Start with the Scheduled Backups tool
For many deployments, the easiest supported path is Scheduled Backups in the Administration Console. It’s built for the Azure DevOps Server data tier and avoids hand-rolling every SQL job.
- Confirm the configuring account has the required Azure DevOps and SQL Server permissions.
- Give the service account rights on each SQL instance and full control of the backup location.
- Use a documented network backup path, not a folder only one person remembers.
- Set retention deliberately.
- Back up the Reporting Services encryption key if reporting is enabled.
- Take an immediate backup if the first scheduled run isn’t soon.
Use marked transactions for synchronized recovery points
Synchronization is the most important concept in an Azure DevOps Server backup strategy. The databases are related, and restoring one from Tuesday and another from Thursday creates mismatched state. Microsoft recommends synchronizing backups to the same point in time, and marked transactions establish a common recovery point across databases.
Guardrail: if you use SQL Server maintenance plans instead of Scheduled Backups, document how transaction marks are created, how often, and exactly which databases they cover.
Runbook structure
Write it for the person paged at 2 a.m., not the person who designed the platform three years ago.
| Section | What to capture | Why it matters |
|---|---|---|
| Inventory | App tiers, SQL instances, collection databases, reporting and analysis, backup share, service accounts | Less guessing during an outage. |
| Backup schedule | Full, differential, log, retention, transaction mark timing | Makes recovery point expectations clear. |
| Restore paths | Same-server, new hardware, app-tier recovery, reporting key restore | Different incidents need different procedures. |
| Validation checks | Collection attach, project access, repo clone, pipeline queue, work item query, reports | Confirms usability, not just “SQL restored.” |
| Contacts | Platform owner, DBA, backup, network and storage, security, business approver | Keeps the incident bridge from becoming a people search. |
Same-server vs. new-hardware restore
A same-server restore returns a damaged deployment to a known-good state. A new-hardware restore may also move databases to a different SQL instance, rebuild application-tier services, restore reporting keys, and validate names, accounts, URLs, certificates and integrations.
For a new SQL target, Microsoft says the SQL Server version, service pack level, collation and language edition should match the original server. Mismatches can derail the restore or leave the server misbehaving after it appears to succeed.
Restore checklist
- Declare the objective: corruption, failed hardware, accidental deletion, ransomware containment or a migration rehearsal.
- Collect recovery materials: backups, logs, transaction mark details, encryption keys, the service account inventory, vaulted passwords, installation media and build documentation.
- Prepare SQL Server to match the original configuration.
- Quiesce services with
TFSServiceControl quiesceso nothing touches the databases mid-recovery. - Restore databases together to the same recovery point.
- Repair ownership and reconfigure: application tier, service accounts, reporting, build agents, proxies and integrations.
- Smoke-test before reopening: sign-in, collections, source control, work items, pipelines, service hooks, feeds and reporting.
- Record the timeline: start time, restore point, issues, decisions and validation result.
Azure DevOps Server backup guardrails to automate
- Job health: alert on failed, skipped or unusually long backups.
- Freshness: check the newest backup age for every required database.
- Coverage: compare collection databases against the backup plan.
- Storage: monitor free space and retention drift on backup targets.
- Offsite copies: keep duplicates away from the servers, as Microsoft recommends.
- Key custody: document the Reporting Services key backup location and password escrow.
- Service accounts: review rights before restore day, and don’t use the installing account as the service account.
- Restore evidence: keep the date and result of the latest test restore where auditors can find it.
“The backup job succeeded” and “we can restore the service” are related, but not the same claim.
The quarterly recovery drill
At least quarterly, restore into a non-production lab using the runbook, not memory. Time the steps, note ambiguity and update the document straight away. If it only works when one senior admin is in the room, it isn’t finished.
| Drill test | Pass condition | Evidence to keep |
|---|---|---|
| Backup integrity | Files are present, readable and restorable. | Restore logs, verification output, backup set IDs. |
| Database restore | All databases restore to the documented point without sync errors. | Recovery timestamp, restore sequence, collection list. |
| Application tier | The console recognizes the deployment and services start cleanly. | Service status, event logs, screenshots. |
| User workflows | Repos, work items, boards, pipelines and test plans work. | Smoke-test results and user sign-off. |
| Dependencies | Reporting, agents, SMTP, proxies and extensions reconnect. | Dependency checklist with notes. |
Common mistakes to avoid
- Backing up only the obvious database.
- Forgetting new project collections.
- Skipping the report server encryption key.
- Restoring databases to different points in time.
- Never testing a restore.
- Keeping backups inside the blast radius, or keeping the runbook only inside the system you’re restoring.
Treat the runbook like production code: version it, test it and improve it after every drill. If you also run Azure workloads, apply the same discipline with Azure Backup immutability and Resource Guard, and see Azure Resource Graph queries for automated guardrail checks.
Last reviewed: October 2026
Sources
- Back up and restore databases (Microsoft Learn)
- Configure a backup schedule and plan (Microsoft Learn)
- About database backups and topologies (Microsoft Learn)
- Manual database backup (Microsoft Learn)
- Restore data to a different server (Microsoft Learn)
- Service accounts and dependencies (Microsoft Learn)
- TFSServiceControl command (Microsoft Learn)
Discover more from Cloud Osprey
Subscribe to get the latest posts sent to your email.
