Zerto Virtual Replication 5.0 – 30-Day Journaling

With Zerto Virtual Replication (ZVR) 5.0 the journal retention period has been increased from 14 to a maximum 30-days, which in combination with One-To-Many replication opens some exciting new possibilities. As a quick recap, the journal is a compressed transaction log of all the block-level changes, in a single or group of VMs, enabling you to rewind and recover from thousands of points in time in the history configured. The journal is always stored in the replication target storage, which can be separate from the replica VMs, configurable with maximum size and warning thresholds.

With One-To-Many replication, VMs can now be simultaneously protected both locally and to multiple remote sites. This enables fast, local, file and VM-level recovery from logical failures by enabling the recovery of the data from seconds before a corruption or deletion occurred. You no longer have to accept the data loss from trying to restore from infrequent and complex daily backups which struggle to complete given the increasing number of multi-TB VMs.

Combining both One-To-Many replication and 30-day retention now means that your 5TB SQL or Oracle database, 10TB Exchange mailbox server, 5TB file server can be recovered from any point in time in the last 24 hours to 30-days directly to production with no nightly backups!  In fact, you can completely remove the whole notion of trying to perform nightly backups for short-term data restores all with a granularity NO backup solution can ever achieve. This leaves snapshot-based backups to what they do best, running once a week or once a month to create a portable and space-efficient VM backup for long-term retention and archiving purposes. 

You can configure different retention policies for both the local and remote replicas, anywhere from 1-hour to 30-days. Each replica uses journals with built-in compression of the block-level changes to maximize space efficiency and recovery granularity. Each journal contains checkpoints every few seconds and minutes to enable any point-in-time recovery. As a rule of thumb, we usually recommend 7-10% space overhead, i.e. if you are protecting 100TB of VMs, you would have a full copy of the VMs, to ensure maximum performance in a recovery scenario, plus 7-10TB for the compressed changed blocks.

Wondering where you will get this storage from? If you have disk space currently used for short-term backups, simply mount it on an ESXi host using VMFS or NFS and you can now perform local continuous replication to it from ZVR 5.0. Even if you are using a Windows server for disk storage you can easily use Windows service for NFS to make it usable by the ESXi hosts.

This all sounds great, but your next question might be “what can I restore using Zerto One-To-Many replication? My xxxxxx snapshot-based backup solution can do 1 million things from the last performance-crushing snapshot I managed to get away with on my multi-TB production VM.” The simple answer is ANYTHING. How? Zerto gives you the ability to perform file-level restores directly from the journal using the Zerto interface and isolated failover testing gives you the entire VM, database and application from the exact point-in-time needed to recover the data in minutes. Here are some examples:

• Need a file or folder from a file server? Simply select File Restore in the Zerto Virtual Manager (ZVM), select the point-in-time, the disk is mounted on the ZVM, enabling files and folders to be downloaded in your browser and restored to wherever needed.
• Need a SQL or Oracle database from 4 hours ago on a VM containing 10 different databases? Easy!Perform a failover test selecting the point-in-time required to an isolated bubble network, backup and export the SQL database.
• Need an Exchange mailbox item from yesterday at 2pm? Perform a failover test to the required point-in-time, the exchange server boots in the isolated bubble network in minutes, create and export a PST of the data needed.

In each of these scenarios the data can be restored from seconds before the data was corrupted or deleted without having to accept the data loss of going to the last backup. In comparison, backup solutions simply don’t have the data from the time you need it! You might now be thinking “how do I export the data from a VM on an isolated network?”Easy! It’s a VM connected to a port group that you create in your vSphere/Hyper-V environment and define on the VPG.You can therefore export the data many ways:

Option 1: Use a Data Transport VM with 1 NIC in the Isolated Bubble Restore network, that the failover test VM is connected to, and another NIC connected to the production network to restore the data directly to where it’s needed.

Option 2: Attach a RDM to the failover test VM, export the data to the disk, attach the RDM to the production VM using in-guest iSCSI (so it isn’t replicated by Zerto), restore the data directly to production.

Option 3: Use PowerCLI Copy-VMGuestFile to extract the file using VMware Tools: https://www.vmware.com/support/developer/PowerCLI/PowerCLI41/html/Copy-VMGuestFile.html

Option 4: Attach a VMDK from NFS storage to the failover test VM, export the data, mount the VMDK on your Windows OS using OSFMount: http://www.osforensics.com/tools/mount-disk-images.html

Any which way you need it you can restore any file, database or application object from any point in time using 30-day journaling, One-To-Many replication, file-level restores and no-impact failover testing. Excited? I am!

Joshua Stenhouse
Technology Evangelist
Zerto