India’s Leading Domain & Web Hosting Provider
Support
Domain & Login
Blog
SAP Backup and Recovery: Backint, Log Backups and Tested HANA Restores
SAP backup and recovery is the protection of HANA databases and SAP file systems so any point in time can be restored, including after ransomware or a bad transport. NTSPL configures Backint-certified cloud backups, frequent log backups, storage snapshots and immutable copies, keeps the backup catalog clean, and proves recovery with scheduled point-in-time restores.
Delivered on
In scope
Why HANA Backups Fail at Restore Time and What a Usable Recovery Needs
HANA backups look healthy right up until someone needs one. Log backups silently stopped when a volume filled, the backup catalog has grown to millions of entries and slows every backup, the only copies sit in the same account an attacker could delete, and the last real restore was done for go-live. For SAP, a restore that recovers the database but not the matching /usr/sap and /sapmnt files, or not to the minute before a faulty mass change, is a partial recovery.
NTSPL builds SAP backup around restore requirements, not backup jobs. Full data backups go through a Backint agent certified for HANA on the target cloud, log backups run every 15 minutes or tighter, and snapshots are added where restore speed matters. Copies are locked against deletion in a separate account or vault. Every month a production backup is restored to a scratch host, recovered to a chosen timestamp and checked.
Indicators That SAP Backups Need Rework
Signals you need SAP Backup & Recovery
- HANA log backups are written to local disk and copied off the host by script once a day.
- No point-in-time restore of production HANA has been performed in the past six months.
- Backups are deletable by the same administrators or identities that run the SAP hosts.
- Restoring a 2 TB or larger HANA takes more than 4 hours, or the time is unknown.
- The backup catalog holds more than a year of entries and HANA backup runs keep getting slower.
When to choose something else
- The requirement is regional recovery within an hour; SAP disaster recovery with HSR is needed on top of backups.
- SAP runs under RISE with SAP, where SAP operates backups; NTSPL can still review retention and restore-test evidence you receive.
- The workload is non-SAP; a general cloud backup architecture applies.
Elements of an SAP-Aware Backup Design
HANA data and log backups
Full and incremental or differential data backups through a certified Backint agent, log backups at a defined interval and backup encryption with managed keys.
Snapshot integration
Application-consistent storage snapshots coordinated with HANA where the storage supports it, for fast restores and system copies.
Immutable and offsite copies
Copies in a separate account, subscription or project with vault lock or object lock, retained per policy in an Indian region.
File system and configuration backups
/usr/sap, /sapmnt, profiles, transport directory and OS configuration captured on a schedule consistent with database backups.
Restore testing and catalog hygiene
Monthly point-in-time restore tests with hdbbackupcheck, and housekeeping that trims the backup catalog to the retention policy.
Backint, Log Backup and Immutable Copy Chain for HANA
HANA Backint, Log Backup and Immutable Copy Chain
HANA writes data and log backups through a Backint agent into a cloud backup service or object storage, while snapshots give fast local restore points. Copies move to a locked vault in a separate account, and monthly restore tests prove the chain to the minute.
Select any component
HANA Backint, Log Backup and Immutable Copy Chain: click any of its 9 components to see its role and the design choice NTSPL makes for it, or trace the 6-step primary path.
HANA Backint Agents and Vault Locks per Cloud
On AWS, HANA is registered through Systems Manager for SAP and backed up by AWS Backup, with copies sent to a locked vault in a separate account in Mumbai or Hyderabad.
Azure Backup provides a Backint-certified HANA solution with log backups, while AzAcSnap adds consistent Azure NetApp Files snapshots; vault immutability and soft delete block early deletion.
On Google Cloud, the Agent for SAP's Backint feature writes HANA backups to Cloud Storage in Mumbai or Delhi, with retention policies and bucket lock making them immutable.
Backup Settings That Decide RPO, Restore Speed and Cost
Log backup interval
HANA's default log backup timeout is 15 minutes, which sets the worst-case RPO from backups. For production supporting dispatch or payments, reduce it to 5 to 10 minutes if storage and Backint throughput allow. Never let log backups write only to local disk; a host loss would take the unbacked logs with it.
Snapshots in addition to Backint
Add storage snapshots when HANA is over 2 TB and restore within 1 hour is required, or when system copies happen weekly. Snapshots are fast but share fate with the storage account, so they never replace Backint copies in a separate vault. Keep 48 to 72 hours of snapshots and push longer retention to the backup service.
Retention and immutability
Keep daily backups for 30 to 35 days, monthly for 12 months and year-end for the statutory period agreed with auditors, often 8 years for financial data. Apply immutability at least to the 30-day window. Lock periods cannot be shortened once set in compliance mode, so agree them with finance first.
Backup encryption keys
Enable HANA backup encryption and keep the root key backup outside the HANA host. Use a separate key store or account for the backup vault's keys. If keys are lost or deleted, backups are unrecoverable, so dual control on key deletion matters as much as vault lock.
Backup Build and Restore Proof in Four Weeks
Recovery requirements and retention
Agree RPO, restore time, retention and immutability periods with Basis, finance and audit.
Backint and vault setup
Install and register the Backint integration, create locked vaults in a separate account and configure encryption.
Schedules, snapshots and file backups
Set data and log schedules, snapshot jobs and SAP file system backups, with alerting.
Restore proof
Restore production to a scratch host, recover to a timestamp and run consistency checks.
Operational handover
Hand over monitoring, monthly test procedure and catalog housekeeping to operations.
What you receive
Backup Quality Measures for SAP Systems
| KPI | Typical target |
|---|---|
| Log backup success rate | 100 percent, no gap longer than the interval |
| Point-in-time restore time for production HANA | Measured monthly, typically under 2 hours for 3 TB |
| Production systems with an immutable copy | 100 percent |
| Monthly restore tests completed | 12 of 12 per year per production SID |
Backup Gaps That Surface Only During Recovery
| Risk | How NTSPL prevents it |
|---|---|
| Attacker with admin rights deletes backups before encrypting systems | Copies are in a separate account with vault lock or object lock, and deletion requires different identities and approvals. |
| Log backup chain breaks silently after a volume fills or Backint fails | Alerts fire within 30 minutes of a missed log backup, and the monthly test recovers to a timestamp that crosses multiple log segments. |
| Restored database lacks matching SAP profiles and kernel | File system backups are taken on the same schedule, and the restore test starts the SAP instance, not only the database. |
HANA Backint backups or storage snapshots for SAP on cloud?
You need both, for different jobs. Backint backups are HANA-aware, appear in the backup catalog, can be encrypted, sent to another account and locked, and support point-in-time recovery with log backups. They are slower to restore for large databases. Snapshots restore a multi-terabyte database in minutes and make system copies easy, but they live with the storage they protect and can be deleted with it. NTSPL designs Backint as the system of record and adds snapshots for speed when HANA exceeds about 2 TB or restore targets are under an hour.
Key facts: SAP Backup & Recovery
SAP Backup & Recovery in Practice
2 SAP Backup & Recovery scenarios, from Pipes and Solar module maker, plus related platform case studies.
Pipes maker recovers S/4HANA to 10 minutes before a faulty mass price update
Solar module maker cuts 4 TB HANA restore from 9 hours to 35 minutes
Multi-specialty hospital cuts HIS recovery time from 2 days to 38 minutes
3PL operator cuts warehouse system recovery time from 2 days to 45 minutes
SAP Backup & Recovery: Frequently Asked Questions
What does SAP backup on cloud cost?
Cost is driven by protected data size, retention and immutability. A 3 TB HANA with 35 days of daily copies and 12 monthly copies usually costs a few lakh rupees a month in backup storage. Setup effort is typically 12 to 20 consultant-days per landscape.
How do backups support CERT-In and DPDP obligations?
Backups stay in Indian regions, backup access is logged and retained for at least 180 days per CERT-In directions, and restore evidence helps show reasonable security safeguards under the DPDP Act 2023 for personal data such as employee payroll records.
How often should we test SAP restores?
Monthly for production HANA, recovering to a random point in time. Quarterly, the test should start the full SAP instance and let a key user check a few transactions.
Can backups be used for system refreshes?
Yes. Quality and pre-production refreshes from production backups or snapshots also act as restore tests. NTSPL scripts post-copy steps so refreshes take hours instead of days.
Should we back up HANA in the DR region as well?
If DR HANA runs continuously, backups usually stay in the primary region with copies sent to DR. After a real failover, backups must start on the DR side immediately, so the DR runbook includes enabling Backint there.
Do we still need SAP-level archiving if backups are kept for years?
Yes. Backups protect against loss; they are not a way to retrieve individual old documents. Archiving keeps HANA smaller and old documents readable, while backups protect whatever remains in the database.