Azure DevOps Server Backup: A Practical Admin Runbook

Azure DevOps Server backup planning is not glamorous work. Nobody opens the Azure DevOps Server Administration Console and whispers, “finally, my moment.” But when a collection database gets corrupted, a storage array misbehaves, or a data-tier migration suddenly becomes urgent, your backup runbook becomes the most popular document in the building.

This guide gives Azure DevOps Server admins a practical, review-friendly runbook: what to back up, how to schedule it, where marked transactions matter, what to test, and which guardrails keep a restore from turning into a late-night archaeology dig. The goal is simple: make recovery boring. Boring recovery is beautiful recovery.

Azure DevOps Server backup: what actually needs protection?

Azure DevOps Server stores the information needed to restore a deployment in SQL Server databases. Microsoft’s backup guidance is clear on the big idea: you do not need to back up every client machine or every application-tier server to recover the Azure DevOps data. You need reliable, synchronized backups of the databases that make up the data tier.

Component	Typical database or recovery item	Runbook note
Configuration	Tfs_Configuration or customized equivalent	Required. Treat it as deployment-critical.
Project collections	One database per project collection	Required. Add new collection databases to the plan immediately.
Warehouse	Tfs_Warehouse	Required for deployments using the warehouse/reporting stack.
Reporting Services	ReportServer, ReportServerTempDB, encryption key	Required if reporting is configured. The encryption key matters.
Analysis Services	Tfs_Analysis	Required if analysis is configured.
Legacy SharePoint integration	SharePoint admin/content databases	Only for older integrated deployments. SharePoint integration is deprecated after TFS 2017, but old farms still exist in the wild.

The sneaky admin trap is growth. Azure DevOps Server creates a new database when a new project collection is created. If your maintenance plan never learns about that database, you have a collection with a very confident-looking but incomplete recovery story. Future-you will not send thank-you biscuits.

Start with the Scheduled Backups Wizard when you can

For many deployments, the easiest supported path is the Scheduled Backups tool in the Azure DevOps Server Administration Console. It is built for the Azure DevOps Server data tier and helps admins create a regular backup schedule without hand-rolling every SQL Server job from scratch.

• Confirm the configuring account has the required Azure DevOps and SQL Server permissions.
• Give the Azure DevOps service account appropriate permissions on each SQL Server instance and full control on the backup location.
• Use a network-accessible backup path, not a mystery folder on a server that only one person remembers.
• Configure retention deliberately so backup storage does not become a very expensive junk drawer.
• If reporting is enabled, back up the Reporting Services encryption key.
• Take an immediate backup after configuring the schedule if the first scheduled run is not soon.

Use marked transactions when databases must restore together

The most important concept in an Azure DevOps Server backup strategy is synchronization. Azure DevOps Server databases are related. Restoring one database from Tuesday and another from Thursday can create mismatched state and confusing failures. Microsoft recommends synchronizing related database backups to the same point in time, and marked transactions are the classic way to establish common recovery points across databases.

Think of a marked transaction as the admin equivalent of yelling “everyone freeze” across the databases before the backup choreography begins. The mark gives you a shared restoration point so the databases can move back together instead of each doing interpretive dance.

Guardrail: If your deployment uses manual SQL Server maintenance plans instead of the Scheduled Backups tool, document how transaction marks are created, how often they run, and exactly which databases are included.

Recommended runbook structure

Your runbook should be written for the person who gets paged at 2:17 AM, not the person who designed the platform three years ago while properly caffeinated. Keep it direct, versioned, and specific.

Runbook section	What to capture	Why it matters
Inventory	Application tiers, SQL instances, collection databases, reporting/analysis components, backup share, service accounts	Reduces guessing during an outage.
Backup schedule	Full, differential, transaction log, retention, transaction mark timing	Shows recovery point expectations clearly.
Restore paths	Same-server restore, new-hardware restore, app-tier recovery, reporting key restore	Different incidents need different procedures.
Validation checks	Collection attach, project access, repo clone, pipeline queue, work item query, reporting smoke tests	Confirms business usability, not just “SQL restored.”
Contacts and approvals	Platform owner, SQL DBA, backup admin, network/storage, security, business approver	Stops the incident bridge becoming a people search engine.

Same-server restore vs new-hardware restore

A same-server restore usually aims to return a corrupted or damaged deployment to a previous known-good state. A new-hardware restore is different: you may be moving databases to a different SQL Server instance, rebuilding application-tier services, restoring reporting encryption keys, and validating that names, accounts, URLs, certificates, and integrations still line up.

For a new SQL Server target, Microsoft’s restore guidance calls out details that deserve a bright yellow sticky note: SQL Server version, service pack level, collation settings, and language edition should match the original database server. That is not decorative trivia. Mismatches can derail restore or leave Azure DevOps Server behaving badly after the restore appears to succeed.

Practical restore checklist

1. Declare the restore objective. Are you recovering from corruption, failed hardware, accidental deletion, ransomware containment, or a migration rehearsal?
2. Freeze changes if needed. Use the documented Azure DevOps service control procedures when the restore process requires services to stop.
3. Identify the complete backup set. Include full backups, differentials, transaction logs, marked transaction details, reporting databases, analysis databases, and the report server encryption key where applicable.
4. Restore databases together. Use the same recovery point for related Azure DevOps databases.
5. Repair ownership and service configuration. Follow Microsoft’s documented steps for database ownership, application-tier configuration, reporting, and optional legacy integrations.
6. Run smoke tests before reopening broadly. Check sign-in, collection visibility, source control, work items, build/release/pipeline behavior where relevant, service hooks, package feeds, and reporting.
7. Record the timeline. Capture start time, restore point, issues, decisions, and the final validation result.

Backup guardrails admins should automate

This is where the tedious stuff becomes useful automation. If your team already monitors Azure subscriptions with scripts, scheduled jobs, or tools like Azure Resource Graph guardrails, apply the same discipline to the on-prem Azure DevOps Server estate.

• Backup job health: alert on failed, skipped, or unexpectedly long backup jobs.
• Freshness: check the newest backup age for every required database.
• Coverage: compare the list of collection databases against the backup plan.
• Storage: monitor free space and retention drift on backup targets.
• Encryption-key custody: verify that Reporting Services encryption-key backup location and password escrow are documented.
• Restore evidence: keep the date and result of the most recent test restore where auditors and humans can find it.

Monkey note: “The backup job succeeded” and “we can restore the service” are cousins, not twins. Be friendly to both.

The quarterly recovery drill

At least quarterly, run a recovery drill in a non-production lab. Do not improvise the process from memory. Use the runbook, time the steps, note ambiguity, and update the document immediately afterward. If the runbook only works when one specific senior admin is in the room, the runbook is not finished.

Drill test	Pass condition
Database restore	All required databases restore to the documented point without synchronization errors.
Application tier	Admin console recognizes the deployment and core services start cleanly.
User access	Test users can reach expected projects and collections.
Developer workflow	Repository clone/fetch, work item query, and pipeline or build validation succeed where applicable.
Reporting	Reports load, or the documented reporting recovery limitation is accepted and tracked.

Common mistakes to avoid

• Backing up only the obvious database. Collection databases are not the whole deployment.
• Forgetting new project collections. Every new collection adds backup responsibility.
• Skipping the report server encryption key. Reporting databases without the key can become a restoration headache.
• Restoring databases to different points in time. This is how small fires become conference calls.
• Never testing a restore. A backup strategy without a restore test is just optimism wearing a lanyard.
• Letting backup storage live beside the blast radius. Keep secure offsite or separate-location copies for disaster scenarios.

Final take

A reliable Azure DevOps Server backup runbook is part technical checklist, part operational muscle memory. Use the Scheduled Backups tool where it fits. Use manual SQL Server plans only when you need that control. Synchronize related databases. Protect reporting keys. Test restores before the emergency. Then automate the boring verification checks so admins can spend less time worrying about backups and more time building the fun stuff.

Sources

• Back up & restore databases – Azure DevOps
• Configure a backup schedule and plan – Azure DevOps
• About database backups & topologies – Azure DevOps
• Manual database backup – Azure DevOps
• Restore data to a different server – Azure DevOps