When backups exist but restores would fail

One of the most common findings on a first SQL Server review is this: backups are scheduled, the job is green, and nobody has restored in months.

That is not a backup strategy. That is a hope strategy.

What “good” actually looks like

A healthy environment can answer four questions quickly:

1. What is the RPO? How much data can the business lose?
2. What is the RTO? How long can the business wait for a restore?
3. Where do backups live? Same disk as the database is a single point of failure.
4. When did we last prove a restore? Including timing and who can do it.

If any of those answers are fuzzy, risk is already present.

Patterns we see in health checks

• Full backups only — no log backups on Full recovery databases
• Log backups missing for days while the log file grows quietly
• COPY_ONLY or ad-hoc backups confusing the chain
• Backups written only to a local volume that would die with the server
• Successful backup jobs that never verify or never get restored
• No runbook for “primary is gone; restore here”

Full recovery without log backups

This combination is a classic silent risk. The database is in Full recovery, but transaction log backups never run. Disk fills, log reuse stops, and recovery point objectives become fiction.

What we recommend next

1. Align recovery model with real RPO
2. Design full / diff / log cadence that matches change rate
3. Store copies off the instance
4. Schedule restore drills and record how long they take
5. Alert on backup age, not only job failure

A free health check almost always starts with backup and restore readiness — because everything else is secondary if you cannot recover.