From Lengthy Backups to Rapid Recovery: How One Expert Redesigned Database Protection on Google Cloud When this enterprise decided to safeguard its entire SAP HANA domain on Google Cloud, the technical considerations were substantial.
Opinions expressed by Entrepreneur contributors are their own.
You're reading Entrepreneur India, an international franchise of Entrepreneur Media.
A major North American uniform and facility services provider is a long-standing customer of SAP. Depending on SAP HANA, which is an in-memory database powering real-time analytics for thousands of enterprises, it commands about 2% of the database management system market in 2025.
When this enterprise decided to safeguard its entire SAP HANA domain on Google Cloud, the technical considerations were substantial. The company's core operations run on several large production systems that support a business outfitting factories, hospitals, and fire departments across North America. In manufacturing and retail sectors like this one, even a modest outage can lead to substantial financial loss and operational risk, and any data gap during recovery can compound the effect. The increasing number of security incidents targeting industrial organizations also prompted a reassessment of existing protection mechanisms.
For decades, the industry has become accustomed to a harsh reality: protecting huge, constantly changing SAP HANA databases requires slow, costly, agent-heavy backup software. Full backups routinely stretched from one-and-a-half to three hours, incremental and log backups still needed thirty minutes to one hour, and the best recovery-point objective most companies could realistically achieve was thirty minutes. These operational demands, along with significant storage usage, formed part of the typical data-protection landscape for large HANA deployments.
A Staff Solutions Consultant at Google Cloud, Srinivasa Atta, explored an alternative approach. He proposed replacing the traditional backup framework with Google Cloud's Backup and Disaster Recovery (GCBDR) service using Persistent Disk snapshots and HANA's backint interface for log management, a model intended to reduce reliance on third-party tools and simplify the infrastructure.
The migration began cautiously with a 40-terabyte non-production system. Early stages revealed issues related to snapshot scheduling, performance under heavy write activity, metadata alignment, and restore reliability. These observations led to extensive collaboration between Srinivasa and the GCBDR engineering team. Over fourteen months, he worked on identifying, documenting, and resolving more than sixty priority issues and contributed with feedback that informed several product updates, feature enhancements, and operational shifts. Certain automation frameworks and procedures from this process were later included in Google Cloud's SAP reference materials.
When the final production cutover was complete, several measurable improvements were observed. Full backups that once consumed one-and-a-half to three hours now finish in approximately fifteen minutes. Incremental and log backups that previously required thirty to sixty minutes decreased to just one to three minutes. The Recovery-Point Objective (RPO) improved from thirty minutes to fifteen minutes, cutting potential data loss in half. The company also reported reductions in backup storage usage and fewer escalated support cases. These outputs were later reflected in Google Cloud's publicly available documentation.
A senior IT executive at the company summarized the experience in Google Cloud's customer success story, "Our organisation uses Google Cloud Backup and DR to protect more than 250TB of critical SAP workloads. Their team's transition to protect HANA instances using Persistent Disk Snapshot has resulted in ~15% savings in backup costs and a reduction in full backup duration from 1.5–3 hours to only 15 minutes."
This reference, along with Google Cloud's decision to document the architecture, provided additional context for companies evaluating similar business environments.
What emerged from the project is now commonly referenced as a pattern that employs crash-consistent Persistent Disk snapshots for full backups, HANA backint for log streaming, and cross-region snapshot replication for disaster recovery. This is an architecture that does not require additional backup agents. Since its publication, the configuration has served as a reference point for organizations assessing similar needs, particularly in manufacturing, retail, and healthcare.
The project showcases how iterative testing, close coordination between engineering and field teams, and sustained technical evaluation can impact the evolution of cloud-native data-protection practices. It focuses on the importance of addressing real-world operational challenges, many of which surface only when systems are tested at enterprise scale under continuous load. By working through situations such as snapshot behavior, write-path contention, and restore validation, the team assisted in the refinement of features that now serve a wider customer base.
This kind of collaborative problem-solving depicts the ongoing, often non-public work that contributes to the reliability and evolution of large-scale cloud platforms. It also exhibits how structured feedback loops between customers and product engineering teams can speed up the evolution of tools that meet the needs of high-throughput, mission-critical workloads.
While the work centered on practical problem-solving rather than promotional goals, the outcomes contributed to the development of a repeatable model relevant to companies running SAP HANA on Google Cloud. The implementation points up how gradual improvements, such as faster backup execution, decreased operational dependencies, and a more predictable recovery framework, can accumulate to form a comprehensive architecture suited for large enterprise landscapes.
It also reflects how technical leadership and hands-on engineering engagement can reduce the gap between theoretical best practices and the complexities of real deployment settings. Ultimately, the project serves as a specimen of the way cloud-based infrastructure evolves not only through published product updates but also through sustained field experience, continuous advancement, and thoughtful application of customer insights.
