Server Backup Checklist

List every protected workload — VMs, file servers, SQL/Oracle DBs, M365 tenants, application servers — with its RPO and RTO. Cross-check against the CMDB or IT Glue; orphaned workloads (test VMs that became prod) are the usual gap. Flag anything new since the last cycle.

Three copies, two media types, one offsite — and at least one immutable or air-gapped copy (object lock, hardened Linux repo, LTO, separate cloud account). Backups writable from production are the ransomware failure mode.

Match retention to HIPAA, PCI DSS, SOX, or SOC 2 requirements applicable to the data class. Long-term archive (Glacier, Coldline, LTO) costs differ; document the tier per workload so the next true-up isn't a surprise.

Confirm Veeam, Datto, Commvault, Cohesity, or Rubrik is on a supported version with current CVE patches applied. Backup servers are a high-value attacker target — out-of-date repos are how ransomware reaches the immutable copy.

Set the GFS chain (weekly full, daily incremental, monthly synthetic full) to fit the backup window. Long incremental chains without a synthetic full inflate restore time — verify the chain length against the workload's RTO.

Primary on-prem repo, secondary repo on different media, offsite copy to S3/Azure Blob with object lock or to a tenant-isolated MSP cloud. Confirm the offsite copy job is chained, not optional, and that the storage account uses a separate credential boundary.

Kick off jobs inside the maintenance window so production I/O isn't impacted. For VMware, confirm CBT (changed block tracking) is healthy; reset CBT on any VM that's been failing incrementals.

Check the backup console after the window closes. Record the result for this cycle — green means every job in the protection set succeeded with no warnings.

For each failure: capture the job log, identify the proximate cause (VSS writer, snapshot stuck, credential rotation, agent offline), and open a ticket with named owner and SLA. Do not re-run the job blindly — VSS-related failures often repeat until the source-side issue is fixed.

Use Veeam SureBackup, Datto's screenshot verification, or a manual mount into an isolated network. The point is to prove the restore path end-to-end — credentials, encryption keys, network — not just that the file opens.

A failed test restore is a P1 — the backup is not actually a backup. Page the senior backup engineer, open an incident, and notify the service owner. Do not move on until the restore path is validated against an alternate restore point.

Confirm BitLocker recovery keys, repository encryption passwords, and KMS key references are escrowed in the password vault (Keeper, 1Password, Hudu) — not only on the backup server. Encrypted backups with lost keys are the worst-case outcome of a real disaster.