What’s the issue?
A Recovery Point Objective (RPO) defines the maximum acceptable amount of data loss measured in time. It is implemented through a backup strategy that takes full, differential, and transaction log backups at appropriate intervals to ensure recovery to a recent point is possible. The recovery model of each database determines which backup types are supported: SIMPLE allows only full and differential backups, while FULL and BULK_LOGGED allow transaction log backups in addition.This finding identifies databases that fall outside common RPO thresholds: databases with no full backups in the last week, or databases in FULL or BULK_LOGGED recovery model with no transaction log backups in the last hour. These thresholds are common starting points for typical production environments and indicate gaps in backup coverage that warrant immediate attention.
Why is this a problem?
A database with no recent full or differential backup has no current recovery baseline. If the database is lost or corrupted, the only available recovery point is the last full backup, which can be days or weeks old, resulting in significant data loss. The longer the gap, the greater the loss, and the harder the recovery becomes.For databases in FULL or BULK_LOGGED recovery model, the absence of recent transaction log backups breaks the recovery chain. Point-in-time recovery is not possible past the last log backup, and the transaction log file continues to grow because it cannot be cleared until log backups occur. This produces both a recovery gap and an operational problem (log file growth) that can eventually cause the log volume to fill and stop the database.
The condition often arises from configuration drift, broken backup jobs, or databases that were created and never added to the standard backup process. New databases are sometimes overlooked when backup jobs are configured by name rather than by detecting all user databases dynamically. Other times, backup jobs fail silently for extended periods, with the failures unnoticed because no one is monitoring backup health specifically.
Backup gaps also have compliance implications. Most regulatory frameworks require demonstrable recovery capabilities, and an audit that finds databases without recent backups produces findings regardless of whether an actual outage has occurred. Even without compliance pressure, the inability to meet basic recovery objectives is one of the more serious operational deficiencies a database environment can have.
What should you do about this?
Take immediate action to close the recovery gap. For databases without a recent full backup, take a full backup as soon as practical, ideally during a low-activity window if the database is large. For databases without recent log backups, take a log backup immediately to reestablish the chain and allow the log space to be marked for reuse.Investigate why the backups were not running. Common causes include backup jobs that have been failing without alerts, databases that were created but not added to the backup configuration, jobs that were disabled and not re-enabled, recovery model changes that should have triggered transaction log backups but did not, and backup destinations that are unavailable. Address the root cause so the gap does not recur.
Verify that backup jobs are configured to handle all current and future databases automatically, and that backups are scheduled to meet your organization’s established RPO.
You may find it helpful to use @Mode=2 in sp_CheckBackup to see when the different kinds of backups have been occurring.