Backint & Cold DR: A Cost-Effective DR Strategy for SAP HANA

Obtain affordable SAP HANA protection with Backup and DR Services.

Your SAP HANA database, which houses the mission-critical data that powers your operations, is the central component of your SAP business apps, like in many other companies. However, what occurs when calamity occurs?

Cold DR: A Practical DR Strategy for SAP HANA Deployments

Making decisions is necessary to safeguard a SAP HANA system. Backint for backups and HANA System Replication (HSR) for high availability are popular techniques. Although having a disaster recovery (DR) plan is essential, it doesn’t have to be highly costly or complicated. HSR provides quick recovery, but it costs a lot of money. A cold DR approach is the ideal compromise between cost-effectiveness and recovery time objectives (RTOs) for many SAP deployments.

Cold DR: What is it?

Consider it the backup plan for your backup plan. By keeping the environment inactive and only turning on during emergencies, it reduces expenses. In contrast to hot or warm DR, this typically entails longer RTOs but much cheaper prices. Although this is frequently thought to be enough, businesses are frequently looking for any improvement in RTO and lower cost.

Backint can be a useful cold DR option when combined with storage (such as cloud storage and persistent disk) to allow data transfer to a backup destination. However, especially for big databases, using Backint for DR may result in higher storage costs and slower restore times. With Backup and DR Service with Persistent Disk (PD) snapshot integration, Google Cloud is offering a solution that addresses both the affordability of cold DR and the speedy recovery of a complete DR solution. This creative method protects your SAP HANA environment by utilizing the strength of incremental everlasting backups and HANA Savepoints.

Rethinking Google Cloud’s SAP disaster recovery

Google Compute Engine-based cloud workloads can be natively integrated with Backup & DR, an enterprise backup and recovery solution. Virtual machines (VMs), file systems, several SAP databases (HANA, ASE, MaxDB, and IQ), Oracle, Microsoft SQL Server, and Db2 may all be backed up and recovered using Backup and DR. To assist assure a low recovery point objective (RPO), you can choose to establish backup plans that specify the backup time, retention duration, location (regional or multi-regional), and storage tier. You can also set database log backup intervals.

SAP HANA databases can now integrate Persistent Disk (PD) snapshots with a new Backup and DR capability. This is a breakthrough because these PD snapshots are connected with SAP HANA Savepoints to assure database consistency. The Backup and DR agent, which runs in the SAP HANA node, tells the database to create a Savepoint image when the backup is planned. In this image, all updated data is written to storage as pages.

The fact that the data copy process takes place on the storage side is an additional advantage of this connection. The backup data is no longer copied utilizing the same network ports as the operating system or database. As a result, even when a backup is in progress, production workloads continue to use the networking and computing resources.

After they’re finished, Backup and DR services use the Google Cloud storage APIs to trigger PD snapshots, which save the image to disk and allow logs to be truncated if needed. These snapshots are all database-consistent backups that are “incremental forever.” As an alternative, you can recover to a certain moment in time (from the HANA PD snapshot picture) by using logs.

This method requires integration with SAP HANA Savepoints. The main purpose of savepoints, which are SAP HANA API calls, is to aid reduce recovery restart times by offering a low RTO. They accomplish this because logs only need to be analyzed from the most recent Savepoint location upon system startup, rather than starting from the beginning. To guarantee transaction consistency, savepoints are synchronized across all database instances and processes (referred to as SAP HANA services).

The following succinctly describes the HANA Savepoint Backup procedure using PD snapshots:

• Instruct the agent to start HANA Savepoint.
• Wait for the “Uploading” state (seconds) after starting the PD snapshot.
• Request that the agent shut down HANA Savepoint.
• Await the “Ready” condition of the PD snapshot (minutes)
• Delete any disk logs that have reached their expiration date.
• Backup catalog for reporting and auditing

Additionally, log backups can be set up to run on a regular basis without relying on Savepoint snapshots. Point-in-time recovery is possible because these logs are kept on a different drive and are also backed up using PD snapshots.

Backups of the operating system

What about backups of the operating system? The good news is that Backup and DR enables you to selectively take PD snapshots of any other disk that is directly connected to your Compute Engine virtual machines, as well as the bootable operating system. For cold DR purposes, these backup images can also be kept in the same regional or multiple regional location.

After that, you can restore HANA databases to your disaster recovery (DR) region or a local virtual machine. Because of this flexibility, you can utilize your DR region for a number of things, like testing and development, or to keep it truly cold for financial reasons.

Because backup and DR enables you to pre-configure networks, firewall rules, and other dependencies, it makes DR deployment easier. After that, it can swiftly set up a backup appliance in your disaster recovery area and restore your whole environment, including databases, logs, and virtual machines.

With the help of this method, you may decide which DR strategy hot, warm, or cold best suits your requirements. Each option has implications for cost, RPO, and RTO.

The substantial cost savings when utilizing Backup and DR with PD snapshots as opposed to conventional DR techniques is one of its main benefits. According to testing, clients can save up to 50% on storage expenses by using incremental everlasting snapshots instead of complete backups. Furthermore, Google discovered that, in comparison to a conventional backup to file methodology, utilizing a cold DR area with Backup and DR can save storage use by at least 30%.

Why this is important

There are several advantages to using Google Cloud’s Backup and DR to safeguard your SAP HANA environment:

• Improved backup performance (throughput): data transfer is managed by the storage layer instead of a HANA server agent.
• TCO was decreased by doing away with frequent full backups.
• Avoided database reads and writes throughout the backup window, which can be quite lengthy in compared to a typical backup event, resulting in less input/output on the SAP HANA server.
• An onboarding process makes operations simple, and there’s no need to handle extra storage provisioning on the source server.
• PD Snapshots restore natively to the VM storage subsystem (not duplicated over customer networks), resulting in faster recovery times (local or DR). Logs from the HANA PD Snapshot can be used to recover to a certain point in time. To further cut down on the log recovery time for restores, you can even schedule more frequent savepoints, such as every few hours.
• HANA PD data resilience Locations that are regional or multi-regional shop snapshots.
• Low Cost DR: Recovery only requires starting your virtual machine (VM), selecting your recovery point-in-time for the SAP HANA Database, and waiting a short while because backup images for both VMs and databases are already replicated to your DR area (via regional or multi-regional PD snapshots).

Persistent Disk Asynchronous Replication: When to Use It

Some customers may have particular demands or preferences that call for a different strategy, even though Backup and DR provides a full solution for many. For instance, Persistent Disk Asynchronous Replication is a useful substitute if your SAP application does not have built-in replication or if you need to replicate your data at the disk level. This method speeds up the recovery process by enabling you to use mirrored disks to spin up new virtual machines (VMs) in your disaster recovery region.

Applications without integrated replication will benefit greatly from PD Async’s infrastructure-level replication, which is application neutral. Because you only pay for the storage that the replicated data uses, it’s also reasonably priced. Additionally, it provides flexibility by letting you choose the replication frequency to strike a balance between RPOs and cost.

Take charge of your catastrophe recovery in SAP

You may create a reliable and affordable cold DR solution for your SAP deployments on Google Cloud by utilizing Backup, DR, and PD Async. This solution reduces expenses without sacrificing data security and offers comfort in the event of unforeseen interruptions.

FAQs