Every backup strategy is built from three primitives, and the choice between them is a trade of backup speed and storage against restore complexity.

Full captures everything every time: simplest to restore (one set), but slowest to run and heaviest on storage. Incremental captures only what changed since the last backup of any kind: fastest and smallest, but a restore must replay the full plus every increment in order, so one missing link breaks the chain. Differential captures everything changed since the last full: a middle ground where a restore needs only the full plus the latest differential.

The 3-2-1 rule governs where copies live, independent of type: keep 3 copies of the data, on 2 different media, with 1 off-site. It is the single guideline that survives ransomware, hardware failure, and site loss.

Windows Server Backup (WSB) is the backup engine built into Windows Server. It is not a feature installed by default, so the first step on any new server is to add it.

What it does. WSB performs block-level backups coordinated through the Volume Shadow Copy Service, so it can back up open files and running applications consistently. It supports full-server, individual-volume, and file/folder backups, plus the two specialized jobs that matter for a domain: System State and Bare Metal Recovery. Targets can be a local disk, a dedicated USB drive, or a network share.

Why block-level matters. Backing up at the block level (rather than copying files) lets WSB capture only changed blocks and work with VSS to get an application-consistent point in time, which is what makes a live server backup actually restorable.

A System State backup captures the set of components that define the server's operating-system identity and configuration, as a single consistent unit. It is what you restore to recover the server's "brain" without imaging the whole disk.

What is always included. On any server: the registry, the COM+ class registration database, boot files, and the Windows File Protection store. What is added by role. On a domain controller it also captures the AD database (NTDS.dit) and SYSVOL; on a CA, the Certificate Services database; on a cluster node, the cluster configuration.

Why back it up separately. System State is the fastest path to recover a corrupted registry, a failed DC, or a broken boot configuration, and it is the prerequisite for an authoritative AD restore. It is small relative to a full backup, so it can run frequently.

Bare Metal Recovery restores an entire server, from nothing, onto blank or replacement hardware. It is the recovery you reach for when a machine is unbootable or physically dead, not just when a file is lost.

What it restores. A BMR image is atomic: the OS partition, all critical volumes, and System State together, plus the partition layout, so the rebuilt server is bootable and complete.

What it needs. You boot the target from Windows install or recovery media (because there is no OS to boot yet), the backup target must be reachable from that boot environment, and restoring to different hardware works but may require injecting storage or network drivers. The walkthrough is: boot media, Repair, Troubleshoot, System Image Recovery, pick the image, Finish.

A BMR backup is deliberately more than a file copy: it is everything required to make blank hardware boot and run as the original server.

The contents. It bundles System State with the critical volumes (the OS and anything the OS depends on to start), and it records the partition layout so the recovery process can recreate the disk structure before laying the data back down.

Building it in PowerShell. You construct a backup policy, add the bare-metal-recovery component to it, point it at a target, and run it. The same policy object is what you later attach a schedule to.

A backup you have to remember to run is a backup that eventually does not run. Scheduling turns the policy into an automatic, repeating job.

The options. Windows Server Backup can run once a day or several times a day, driven either through Task Scheduler or directly by setting a schedule on a WBPolicy object in PowerShell. Multiple daily runs tighten your recovery point at the cost of more backup windows.

Timing it well. Schedule backups for low-usage periods to minimize performance impact, but make sure they finish before business hours begin, an overrunning backup that collides with the workday is a classic self-inflicted slowdown.

Restoring Active Directory has two modes, and choosing the wrong one either fails to recover deleted objects or re-deletes them. The distinction is about which direction replication flows after the restore.

Non-authoritative is the default. You restore a DC from backup and then let its replication partners update it with everything that changed since the backup. Use it to rebuild a single failed DC, the rest of the domain is the source of truth.

Authoritative is for recovering deletions. You restore in Directory Services Restore Mode, then use ntdsutil to mark the recovered object with a higher version so it replicates out to every other DC instead of being overwritten by them. This is how you bring back an accidentally deleted OU or account before the Recycle Bin era.

The AD Recycle Bin is the modern answer to accidental deletion. Instead of the painful DSRM authoritative-restore dance, you recover the deleted object directly, with all its attributes and group memberships preserved.

How it changes deletion. Without it, a deleted object becomes a stripped "tombstone" that loses most attributes. With it enabled, the object retains every attribute for the deleted-object lifetime (180 days by default), so a restore brings it back whole.

The catch. Enabling it is a per-forest, one-way operation (it cannot be turned off) and requires a forest functional level of 2008 R2 or higher, so it is a deliberate rollout decision, not a casual toggle.

The practical payoff of the AD Recycle Bin is that object recovery stops being an outage. Compared with the old authoritative-restore process, the difference is dramatic.

The four wins. Deleted objects come back with all attributes intact; no domain controller has to be taken offline into DSRM; objects remain recoverable for 180 days by default; and there is no authoritative restore and no forced replication to orchestrate. What used to be a maintenance-window project becomes a one-line restore.

The one-time cost. Enabling it is irreversible, needs Enterprise Admin rights, and raises the forest functional level, so you plan it once, then it quietly protects you from then on.

Once the Recycle Bin is enabled, recovery is a two-step query-and-restore pattern you can run on demand, no reboot, no special mode.

See what is recoverable. You query for objects whose isDeleted flag is true, including deleted objects in the search scope, to list everything currently sitting in the bin within its 180-day window.

Restore precisely. Filter that list down to the specific object (by display name, for example) and pipe it to Restore-ADObject. If the object's parent OU was also deleted, restore the OU first or pass an explicit target path so the object has a home to return to.

The Volume Shadow Copy Service is the Windows mechanism that lets you back up data that is in use. It creates a frozen, point-in-time snapshot of a volume so a backup reads a stable image even while applications keep writing.

Consistency levels. If an application provides a VSS Writer (SQL Server, Exchange, Active Directory do), VSS coordinates with it to flush and quiesce so the snapshot is application-consistent (safe to restore directly). Without a Writer, the snapshot is only crash-consistent, equivalent to pulling the power, recoverable but not guaranteed clean.

How it stays fast. VSS uses copy-on-write: taking the snapshot is near-instant, and the shadow storage area only grows as blocks are subsequently changed, so the cost is paid gradually rather than up front.

A VSS snapshot is a collaboration between three distinct roles, and knowing which is which is how you read a failed-backup error.

The Requestor is the backup application (Windows Server Backup or a third-party tool) that asks VSS for a snapshot. The Provider is the component that actually creates and maintains the shadow copy, either the built-in system provider or a hardware/SAN provider. The Writer is supplied by each application (SQL, Exchange, AD) to flush its data to a consistent state before the snapshot is taken.

Why it matters. When a backup fails, the writer status usually tells you which application failed to quiesce, pointing you straight at the culprit rather than the backup tool itself.

Beyond scheduled backups, VSS lets you grab an immediate recovery point by hand, which is the smart move right before a risky change like a software update or a configuration overhaul.

Create one now. A single command snapshots a volume on demand, giving you a known-good point to roll back to if the change goes wrong. You can also count or enumerate existing shadow copies through WMI.

When backups fail, check the writers. The first diagnostic is always the writer list: a writer in a failed or unstable state almost always points at an application problem rather than the backup software, so fix the writer and the backup follows.

Keeping backups on the same machine they protect satisfies no part of the 3-2-1 rule, so production backups target storage somewhere else on the network.

Supported targets. Windows Server Backup can write to SMB file shares, dedicated backup servers, and NAS appliances; cloud destinations are reached through third-party tools layered on top. A network share is the most common off-box target for a single server.

The trade-off to know. When WSB backs up to a network share it keeps only the latest backup at that destination (each run overwrites the prior one), so if you need multiple recovery points over time you either rotate shares or use a dedicated backup volume that retains a history.

The only proof a backup works is a successful restore. Backups that have never been restored are assumptions, and the worst time to discover a corrupt or incomplete backup is during a real outage.

The discipline. Run recovery drills on a schedule (quarterly is a common baseline) in an isolated environment so a test restore cannot collide with production, document the actual recovery time, and verify the restored data's integrity rather than just that the job finished.

The three metrics that frame every recovery plan: RTO (Recovery Time Objective), the maximum acceptable downtime; RPO (Recovery Point Objective), the maximum acceptable data loss, which dictates how often you back up; and MTTR (Mean Time To Recovery), how long restores actually take in practice. Drills are how you confirm your RTO and RPO are real and not aspirational.

The labs take backup and recovery from concept to muscle memory. You will configure protection, schedule it, and then actually recover, the full lifecycle rather than just the backup half.

In the GUI lab you configure Windows Server Backup, set a schedule, run a System State backup, and browse and restore from it.

In the PowerShell lab you build WBAdmin policies, schedule them, point them at targets, check status, and drive a recovery, the scripted equivalent that scales to many servers.