At the heart of every modern business is data. Use it right, and you open the door to emerging technologies that’ll help you compete. But as you continue to innovate and invest in your technology, the data that’s created and produced becomes even more critical to protect from loss and outages. For SAP customers using new systems like S/4HANA, including backup and storage design as part of your overall business continuity planning rings particularly true. Reasons for data loss and outages can be physical or logical. In this blog post, we’ll focus on protecting against physical outages, like those caused by data center failures or environmental disasters, so your business is ready for anything.

Technology 101: How backups work in the SAP ecosystem

Each of your SAP deployments has unique Recovery Point Objective (RPO) and Recovery Time Objective (RTO) requirements, which influence your entire backup strategy and toolset. You can think of RPO as your backup operations: The more capabilities you have here, the further back your recovery point goes. RTO refers to the time it takes for your systems to recover and get back online. Most of the time, a trade-off is made between the overall cost of backup operations and the cost of time due to lost data.

A typical SAP workload consists of virtual machines (VMs) running databases and application- servers on disks. There is a dedicated boot disk for the operating system (OS), and most of the remaining disks are used for applications. Because of this, we recommend that all of our SAP customers allocate a separate disk, like Persistent Disk, for all files and data that aren’t part of your OS. This makes systems easily replaceable and moveable and simplifies data capture and storage processes.

Backup strategies for SAP customers leveraging the cloud

The core principle for backup solutions is to segregate backup data copies from the primary storage location. But, in an on-premises setting, data has only one place to go: the in-house storage unit. The good news is that, as more SAP workloads have moved to the cloud on HANA, you now have multiple cloud-based backup solutions that are flexible, scalable, and self-manageable.

Persistent disk snapshots
Persistent disk snapshots are fast and cost-effective. You can specify the storage location for snapshots as regional or multi-regional. In an SAP HANA database running on Google Cloud, you can store backup folders on separate persistent disks to capture and replicate the database server independently.
Machine images (Beta)
A Google Compute Engine resource, machine images store all the configuration, metadata, permissions, and data needed from disks to create a VM instance. Machine images are ideal resources for disk backups as well as instance cloning and replication.
Shared file storage
SAP systems can use shared file storage (for example, Google Cloud Filestore or Elastifile) to fulfill any high availability and disaster recovery requirements. Shared file systems can be combined with appropriately chosen Cloud Storage buckets (multi-region, dual region) to ensure availability of data backups across zones and regions.
HANA Backint agent for Cloud Storage (Beta)
For SAP HANA database backup, Google Cloud offers customers a free, SAP-certified, and application-aware Cloud Storage Backint agent for SAP which would eliminate the need for backing up with persistent disks.
Third-party network storage
Third-party network file system (NFS) solutions offer a backup of all relevant file system volumes of an SAP instance for both the application and database layers with scheduled snapshots, which are stored in Cloud Storage. For SAP HANA, this solution is only suitable for hosting backup and share volumes.
Third-party backup agents and managed services
These solutions offer advanced technical features that enable rapid backup and recovery times, because third-party providers do not rely on database-level incremental backups. For enterprise-scale SAP landscapes, this reduces storage sizes. A word of advice, though: Stick to SAP HANA certified backup solutions.
SAP HANA data snapshot
SAP HANA databases can also create data snapshots independently, using native SQL. This doesn’t require certification, but it is a highly complex technique since some systems need to be deactivated before snapshots can be taken.
SAP HANA stop/start snapshot of secondary HANA instance
This solution is suitable for non-production cases where cost considerations supersede RPO requirements. Creating snapshots involves using a smaller standby instance in an SAP HANA system replication setup. You can also take this instance offline and make a complete VM snapshot for point-in-time recoverability.
Snapshot and disk deallocation
If cost is a high priority, Google Cloud offers services that enable you to allocate a persistent disk in time for a snapshot and deallocate it once the backup is complete. A cloud-based infrastructure will allow you to create disks for backup on an as-needed and pay-as-you-use basis.