How to Protect Your Database with Zerto

For a business, databases have become more valuable than diamonds, as they often store millions of dollars in value. However, unlike diamonds, databases are dynamic and therefore require protection from a plethora of vulnerabilities and data loss. Database contents change depending on the applications they serve, and they need to be protected alongside other application components. Ensuring that the integrity of the data is preserved while handling the dynamic characteristics of databases complicates data protection requirements for a business’s most precious asset.

Zerto, a Hewlett Packard Enterprise company, simplifies the protection of a business’s most precious assets by providing disaster recovery for databases at scale. This article will discuss the different types of databases and how Zerto leverages its continuous data protection (CDP) to best preserve these instances.

SQL Databases (Microsoft SQL Server & Oracle)

A SQL database (also referred to as a “relational database”) is a structured grouping of data into rows and columns to make a table. These databases leverage a Structured Query Language (SQL) in order to organize, manage, and relate with the information stored. Common SQL database servers used are Microsoft SQL Server (MS SQL) and Oracle databases. Many organizations deploy relational databases to store much of their application’s data. As the size and number of these server instances increase, so does the complexity and requirements when it comes to disaster recovery and replication.

Zerto helps avoid complexity by protecting relational databases with crash consistency during replication. This means every checkpoint in the Zerto journal provides a point-in-time restore of a relational database instance as if it were shut down immediately without warning. This is deliberate because obtaining application consistent checkpoints requires everything in memory to be flushed to disk, consequently stunning the application and causing potential downtime and data loss. To avoid this, Zerto can work with key functions within MS SQL server and Oracle databases to maintain application consistency and maintain the lowest recovery point objective (RPO) and recovery time objective (RTO).

Microsoft SQL Server

For MS SQL, data loss is critical, which is why it is important to always recover to the latest point in time possible. With Zerto, this is typically seconds before the data loss. An important characteristic of an MS SQL server is that it must maintain ACID compliance, meaning it guarantees atomicity, consistency, isolation, and durability (ACID) of the data. This is important to consider when replicating MS SQL servers, as replicating and restoring the database incorrectly could break compliance, causing data loss. When protecting MS SQL servers, Zerto helps maintain ACID compliance by ensuring write-order fidelity is maintained on all replicated data.

Application consistent replicas of MS SQL instances are achieved using the Microsoft VSS SQL Writer service. Once this is enabled, MS SQL database transactions held in memory are flushed to disk in order to maintain a failsafe point in time for recovery. Application-consistent points in time will be indicated as a checkpoint in the Zerto journal of changes to ensure visibility when performing a move, failover, or failover test in Zerto.

Read more about Protecting Microsoft SQL Server with Zerto Best Practices.

Oracle Databases

Deploying Zerto in Oracle database environments provides key benefits such as continuous data protection (CDP) to achieve the lowest RPO and RTO in the event of failures, ransomware attacks, or natural disasters.

It is important to note that an Oracle database must be placed into hot backup mode to achieve database application consistency. Hot backup mode freezes the system change number (SCN) in the redo logs, and it gives Oracle a specific application-consistent location to which to recover. After Oracle is in hot backup mode, the Oracle specific checkpoint for Zerto is recorded. After the checkpoint is complete, hot backup can be disabled. In the case of crash consistency, because all the database objects in a specific database instance are part of the same VPG, the data is consistent and proper write ordering will take place. In the event of a crash recovery, the database will recover from a specific checkpoint and behave like it is recovering from a failure.

Interested in learning how CDP can help you avoid downtime of Oracle instances? Read the full whitepaper on Protecting Oracle databases on VMware with Zerto.

NoSQL Databases (Cassandra)

Rather than rows and columns, non-relational databases, referred to as “NoSQL” databases prefer data to be stored as key-value pairs, documents, or wide-column stores. Compared to its tabular counterpart, these databases scale better horizontally (meaning it is easier to create more instances of them rather than increase their size), and they are generally used in applications that store more unstructured data types.

One popular NoSQL database server is Cassandra, which has a versatile cluster architecture making it simple to deploy and manage as an instance on-premises or in the cloud. Cassandra also has some built-in disaster recovery (DR) functionalities that can replicate copies of itself between hosts, whether onsite, or to a remote location. However, the replication only protects the data and not the cluster itself, so a failover to a remote node would still require a recovery that could take hours, if not days, to fully recover all the cluster nodes. This is typical as NoSQL databases have traditionally relied on their own built-in processes and tools to manage their data, but as these applications are becoming more mainstream, those tools are simply not sophisticated enough to manage the more complex needs of a modern production environment.

For example, Cassandra’s internal backup and recovery tools do enable the user to recover objects or tables within the database structure without any interruption in the online status of the database. This granular recovery capability would still be useful but does not provide the complete cluster protection required for a competent disaster recovery solution. CDP with Zerto data protection keeps track of all the writes and changes for files on its protected Cassandra instance and can replicate those changes in real-time offsite.

In the case of a local site failure, Zerto can failover the local Cassandra nodes to the remote site without taking the database offline. Cassandra clients can be redirected to the new cluster nodes in minutes and remove the need to store a cluster node offsite just to protect the databases. Plus, since all the nodes can be protected, the entire cluster can be brought online immediately, instead of having to rebuild new nodes at the remote site with Cassandra. This reduces the total cluster rebuild time to minutes rather than hours or days.

Zerto’s CDP can be leveraged in a variety of workload scenarios to provide data management solutions for a Cassandra database cluster. It is a significant improvement in disaster recovery over the native Cassandra DR functionalities.

Learn more about how Zerto helps protect Cassandra instances by checking out these three short videos: Managing Cassandra Data with Zerto.

SAP HANA

Finally, there are databases that go beyond tables and unstructured formats. In-memory databases, such as SAP HANA, offer real-time analytics for large amounts of data. SAP HANA has been adopted by thousands of large, medium, and small enterprises across all verticals. This widespread use makes SAP HANA data management a challenge—but a challenge which Zerto solves using a unique approach.

Zerto can be used with SAP HANA to achieve continuous data protection, disaster recovery, and data migration to and from on-premises data centers or the cloud. Because Zerto works at the hypervisor level, it is agnostic to the application running inside the instance (or virtual machine, VM) hosting the instance of SAP HANA. Therefore, its operations are crash-consistent by default. Zerto’s continuous journaling mechanism logs all writes that occur on the virtual disk of the instance.

As an in-memory database, SAP HANA does not write data to the disk as soon as the transaction is committed in memory. Rather, it writes in bulk, at intervals called savepoints, every 300 seconds to the persistent storage. The Zerto journal is updated when a savepoint occurs. For every committed transaction, however, SAP HANA does write a log to a volume, thereby updating the Zerto journal for the log virtual machine disk (VMDK). Therefore, Zerto offers a crash-consistent recovery for databases such as SAP HANA which uses the last good HANA savepoint and replays all the transaction logs from the savepoint timestamp until the time before the crash. A major benefit of Zerto is that it can instantly create copies of a protected VM. Unlike other data protection applications that restore to the same VM or instance, Zerto creates a copy of the protected SAP HANA database on the recovery host.

After the copy is created, SAP HANA services must be started manually. In this fashion, Zerto restores business continuity as soon as possible, and the failed, corrupted, or compromised VM can continue to be analyzed for root causes.

Learn more about how to manage data protection in SAP HANA using Zerto.

Summary

For businesses, the intricacies of managing data and the databases it lives in can be daunting, and data protection adds another layer of complexity. So, while it is difficult to protect what matters most, Zerto simplifies the protection of a business’s data by providing disaster recovery for databases at scale. Zerto’s CDP is the best way to protect your business’s most precious assets.

Do you want to see Zerto in action for yourself? Sign up for our Hands on Labs today to experience the power of CDP firsthand.

Anthony Dutra