Monitoring Backup Jobs and Verifying Recovery Readiness

Explanation

A backup is only useful if it can be restored, and many organizations discover gaps in their backup chain only during an actual outage. This lesson focuses on the operational discipline of monitoring backup jobs, validating catalog consistency, and periodically proving that recovery actually works within the agreed Recovery Time Objective (RTO) and Recovery Point Objective (RPO). On classic ECC systems running Oracle, DB2 or SQL Server, Basis administrators typically monitor backup status through database administration transactions (commonly DB13 for scheduling and DB12 for backup logs, though exact transaction availability depends on the database platform). Each backup run produces a log entry showing start time, duration, size, return code and any warnings. A healthy monitoring routine checks not just 'did the job finish' but 'did it finish within the expected window, with the expected size, and zero errors.' A backup that completes with warnings (for example, skipped files, retry events, or truncated logs) can create a false sense of security if nobody reviews the detailed log. For SAP HANA, backup monitoring shifts to the HANA backup catalog, which is a persistent record of every full, differential, incremental and log backup taken, including their status and dependency chain. Administrators use HANA Cockpit, HANA Studio, or SQL queries against system views to inspect this catalog. A critical HANA-specific risk is a gap in the log backup chain: if log backups stop (due to disk full, permission issues or a paused backup destination) while the database continues transacting, you may still 'succeed' at full backups but be unable to do a point-in-time recovery past the gap. Detecting this requires actively checking for continuous, gap-free log backup coverage, not just confirming that full backups exist. Recovery verification means periodically restoring a backup to a non-production or sandbox system and confirming: the system starts, data is consistent, and the point-in-time recovery target matches what was requested. This exercise also validates that backup media (disk, tape, cloud object storage, or backint-integrated third-party tools) is actually readable and that restore procedures, permissions, and documentation are current. Skipping this validation is one of the most common causes of failed disaster recovery events, because backups can silently degrade due to media corruption, expired retention, or configuration drift between the backup tool and the database. In S/4HANA on-premise and private cloud, this monitoring and verification responsibility usually remains with the customer's Basis or infrastructure team, often supplemented by monitoring integration into Cloud ALM for centralized alerting across systems. In S/4HANA Cloud (public edition), SAP performs backup execution and infrastructure-level recovery as part of the managed service; customer administrators typically do not directly execute or verify HANA-level backups themselves, and recovery requests go through SAP support channels under contractual RTO/RPO commitments, so assuming customer-side control equivalent to on-premise is incorrect. For BTP-based services, backup and recovery responsibility depends on the specific service model and should not be assumed to mirror on-premise HANA behavior. When advising on architecture, always confirm current responsibility boundaries with the actual product documentation rather than assuming a uniform model across deployment types, since responsibilities can evolve between contract and service tiers. A mature monitoring practice combines automated alerting for backup failures, periodic manual review of full and log backup logs, catalog validation to detect chain gaps, and scheduled restore tests with documented pass/fail evidence. This evidence is often required for audit, and demonstrating a successful test restore is stronger assurance than simply showing a green backup log.

Code example

-- Example: Inspecting HANA backup catalog for recent backups and status-- Run in HANA Studio SQL console or via hdbsqlSELECT    ENTRY_ID,    BACKUP_ID,    ENTRY_TYPE_NAME,   -- e.g. complete data backup, log backup    SYS_START_TIME,    STATE_NAME,        -- successful, failed, running, canceled    BACKUP_SIZEFROM M_BACKUP_CATALOGWHERE SYS_START_TIME > ADD_DAYS(CURRENT_TIMESTAMP, -7)ORDER BY SYS_START_TIME DESC; -- Example: Checking for gaps in log backup chain-- (conceptual approach: compare consecutive log backup end/start times)SELECT    BACKUP_ID,    SYS_START_TIME,    UTC_END_TIME,    STATE_NAMEFROM M_BACKUP_CATALOGWHERE ENTRY_TYPE_NAME = 'log backup'ORDER BY SYS_START_TIME ASC;-- Review manually or via script for time gaps larger than the expected-- log backup interval, which would indicate a coverage gap. -- Operational checklist example (documented, not executed via SQL):-- 1. Confirm latest full backup completed with STATE_NAME = 'successful'-- 2. Confirm no gaps exceed configured log backup interval-- 3. Confirm backup destination has sufficient free space and retention-- 4. Schedule quarterly restore test to isolated sandbox system-- 5. Document restore duration and compare against agreed RTO

Real project scenario

During a quarterly disaster recovery audit, a Basis team reviewing the HANA backup catalog discovered a six-hour gap in log backups two weeks earlier, caused by a temporary permission issue on the backup destination after a storage migration. Full backups had continued to report success, so no alert had fired. Because the gap was identified through catalog review rather than during an actual incident, the team was able to confirm that the affected window had no critical transactions and adjust monitoring to explicitly alert on log backup chain gaps, not just job failure codes. This became a standing agenda item in monthly Basis operations reviews.

Common mistakes

• Treating a 'successful' backup job status as sufficient without reviewing detailed logs for warnings or partial completions • Failing to monitor for gaps in the HANA log backup chain, which can silently break point-in-time recovery capability • Never performing an actual test restore, so backup media corruption or configuration drift is discovered only during a real emergency • Assuming customer teams retain full backup and recovery control in S/4HANA Cloud (public edition) when the operating model is SAP-managed • Not aligning backup frequency and retention with the documented RTO/RPO, leading to recovery gaps that exceed business tolerance • Ignoring backup destination capacity monitoring, which can cause backups to fail silently once storage fills up

Best practices

• Review backup logs in detail, not just job return codes, to catch warnings that indicate partial or degraded backups • Actively monitor the HANA backup catalog for continuous log backup coverage without unexplained gaps • Schedule and document periodic restore tests to a non-production system to validate real recovery capability • Configure automated alerting for backup failures, missed schedules, and backup destination capacity thresholds • Confirm current backup and recovery responsibility boundaries for your specific SAP deployment model rather than assuming they match on-premise practices • Maintain documented evidence of successful restore tests for audit and disaster recovery certification purposes • Align backup frequency, retention and monitoring thresholds explicitly with agreed RTO and RPO targets rather than generic defaults

Interview angle

Interviewers assess whether candidates distinguish between backup completion and recovery readiness. Strong answers explain how to detect log backup chain gaps in HANA, why periodic restore testing is necessary even when backups report success, how monitoring responsibilities differ between on-premise/private cloud and S/4HANA Cloud (public edition), and how to translate RTO/RPO business requirements into concrete backup frequency and monitoring practices. Being able to describe a real gap-detection or restore-test scenario signals hands-on operational maturity beyond theoretical knowledge.