Disaster recovery involves a set of policies, tools, and procedures that you can use for recovery of vital SAP Systems following a natural or human induced disaster. Disasters are less frequent than system failures on downtimes. While it is important to understand the reference architecture and implement a plan to recover, it is also important to test your plan from time to time to be prepared for worst-case scenarios. On top of all the DR tools, architecture, and best practices that I'll discuss in this module, I would like to remind you of the automation capabilities and tools that you'll learn in module 1 of this course. Those tools can automate your DR tests and run them periodically to be best prepared for the event of a disaster. Now, let's get back to our big picture overview. You have already learned about the first block, which is high availability in the previous module. In this module, I will discuss some options on Google Cloud for disaster recovery, and I will then enhance the reference architecture diagram with DR capabilities. After that, I will discuss the native features for backup, and also some partner solutions for DR and data management that you can use in the context of SAP deployments on Google Cloud. Your disaster recovery strategy depends on both how long you can afford to have your business offline, the RTO, and how much data loss you can tolerate or the RPO. For both cases, you must determine the cause to your business, for your system being offline or from losing data. If you want to recover your system quickly from a cash point, you typically use a clustering setup. If you want a recovery within days rather than hours, you can use manual migrations. For most productive workloads, you require high availability, so use clustering setup for faster recovery. From a data perspective, synchronous and asynchronous replication across zones, lets you achieve high availability. If you can sustain some data loss, you can periodically backup your databases instead. For example, this can be a weekly full backup with incremental backups in-between. Going beyond the range of days for data recovery, you can store your backup as snapshots or discs in coldline or archiving data class like a Google Cloud Storage bucket. Restoring from a coldline backup can take more time before you can get your old data back and do a recovery. This table provides an overview of recovery methods by component for each disaster recovery scenario. If you look at the bottom row, you see the mechanism you can use to recover Databases, buying shares, and application servers within a range of seconds to minutes. Synchronous replication for database and file shares is the key here, to achieve minimal RTO and RPO. For the application servers, you can configure them once and then turn them down to save cause, but start on short notice in the event of a disaster. We'll also keep applying manual patches from time to time on the DR side to keep the application servers up to date, though they're turned on. If you look at recovery mechanisms in the middle row, you can see the options in the range of minutes, two hours. At the database level, you replicate backups across regions, either by HANA, asynchronous replication or by using managed services like Nadab or own scripting. You can also use backup snapshots that replicate across regions. But these ranges of RTO, RPO, asynchronous replication is the key. For longer recovery times and RPOs, you can manually restore your system from backup. You can also do this using scripts or automation depending on your requirements. Let's look at the disaster recovery options from the database perspective in detail. Again, as mentioned earlier, I'll be using the example of SAP HANA here. It is similar to architecture that you saw earlier when you looked at high availability, except in this case, the secondary instance of HANA is in a different region, it can be in any zone within that region. As the secondary instance of your database using a different region, you must use asynchronous HANA system replication to replicate your data in near real time. For an initial restore from backup in the event of a disaster, you use the Cloud Storage buckets that contain the backup volumes of the primary HANA database to spin up the disks. This method works well if you can tolerate some loss of data and after a little longer recovery time. Here is the reference architecture for SAP disaster recovery with both database and application server layers. At the database level, there is an instance of SAP HANA and the DR region. Data from primary region is asynchronously replicated to the DR instance. If cost considerations are important, then RTO and RPO minimization, in your DR setup, you can have smaller instance of secondary SAP HANA on the DR zone. This reduces your cost because the HANA VM on the DR side uses less memory. If a disaster happens, you can then resize the backup system to the size of the primary system and then bring the system back online. Application servers are set up with the same configuration as those in the primary, but turned on to save costs. Now, let's look at the complete picture with HA and DR. This diagram here shows the complete reference architecture with disaster recovery elements included. You can see the HANA system replication is setup asynchronously between online instances running into different regions. To complete the discussion, the systems on the DR site can be recovered from multiple backup options like PD snapshots, Google Cloud Storage buckets, and Google Machine images. I will cover backup options in more detail in the next section.
