Tips for configuring your Zerto Commit Policy

What is a Zerto Commit Policy?

If you are a Zerto customer, you have probably seen this phrase when doing Moves and Live Failovers. But, unless you are the manual reading type, you probably have no idea what it means. I used Zerto for a year or so before Sean Masters (www.seanmmaster.com) was like “you idiot, do you not know what a commit policy is?” (I would venture to say that is verbatim how he said it too.) So don’t feel bad if you don’t know. Plus I’m going to explain it to you. 🙂

A Zerto commit policy allows you to either automatically commit or delay committing to a particular point in time when going to a recovery site copy of your data. This is a major differentiator for Zerto because it means that you aren’t stuck with a bad copy of the data after you failover. If the point in time (or checkpoint in Zerto speak) isn’t what you want, then you can get out of that copy and move to a different checkpoint quickly and easily.

Real world example

If your file server gets hit with a cryptovirus and all of you data is encrypted, you are probably going to want to fail over to your DR copy. But do you know EXACTLY when the virus started? Zerto gives you incredible granularity with its checkpoints, so if you know exactly when it started, you can recover with minimal data loss. (If you don’t you can always roll back farther, but the idea is to minimize data loss.)

We will assume that the virus hit at 10 AM; therefore our first checkpoint selection might be from 9:59:35 in the journal. Next, we tell Zerto to do a live failover, and the VM boots up. After logging in, we realize that the virus is still there and files are already encrypted. I guess that checkpoint isn’t going to work. So how to we go to a different point in time? EASY!

We tell Zerto to rollback instead of commit. Then we are essentially right where we started; we can again go through and pick a new checkpoint, say 9:55:00, and fire up that copy. If it looks right, we will “commit” to this copy of the data. Why do we have to commit? Well, we want Zerto to know that this checkpoint is good and that we are ready to start reverse replication back to the other site. Committing to a checkpoint will allow that process to start.

Zerto Commit Options

There are three options that you can pick from for commit policy.

zerto commit policy
Zerto’s Global Failover/Move Commit Policy

None

None is the easy one to explain. Commits do not happen automatically when you select “None”. You must manually come back to Zerto after checking the failed over virtual machines and tell Zerto to Commit or Rollback. The “None” commit policy is what I illustrated in the example above.

The downside to the “none” commit policy is that if you leave a VM in a not-committed state for too long, it can run out of scratch disk space. This will cause the VM to lock up. The “none” policy also does not consolidate the journal and base disk automatically, so it will cause your VMs to use more datastore space than needed after a while.

Auto-Commit

Auto-Commit means that after a predetermined amount of time, Zerto will assume that everything is OK with the virtual machines it has failed over and automatically commit those VM’s. Reverse replication can then start if it was supposed to. By default, Zerto waits for zero (0) minutes before auto-commit happens. In other words, if you haven’t modified your commit policy either manually during VPG failover or move, or globally, Zerto will automatically commit you to whatever checkpoint you picked without asking you to confirm.

Why is that a bad thing? Well, when you commit to a checkpoint, all other checkpoints in the journal are consolidated and removed to save disk space. So by committing, you are essentially saying “I no longer need my journal history, this is the point in time that I want.” Sounds like a that could be risky if you don’t know what you’re doing, doesn’t it? (Mainly because once the journal is consolidated Zerto can’t magically go back to any other point in time… hence why we call it “commit.”)

However, in a situation where your goal is to failover to a DR site after a disaster, this option is the “easiest.” After clicking failover you literally have nothing else to do, everything is automated to bring VMs online at the DR site. Which is super awesome, if that is your goal. But again, it can be a problem if you are trying to recover from data corruption and you aren’t sure exactly what checkpoint to use. Bottom line, if you are unsure of the checkpoint you want to use, change the time before auto-commit from zerto to something else (10-60 are good options).

Auto-Rollback

Auto-Rollback is the opposite of Auto-Commit. However, because Auto-Rollback is not the default option, you will have to specify the number of minutes to wait before the rollback happens. The process then looks something like:

  • Failover the VMs
  • wait for “X” minutes
  • if the user doesn’t manually commit to the failed over VMs
    • power off failover VMs
    • assume it didn’t work and allow the admin to start over
  • if the user does manually commit consolidate the journal
    • turn the failed over VMs into “regular” VMs
    • Start reverse replication if desired

I like to think of auto-rollback as the “dead man’s switch,” meaning that if you go grab a pizza after starting a failover, Zerto will take control of things after the number of minutes specified have passed. Its goal is to put things back to the way they were before you clicked failover. So essentially, “tell me everything is good to go, or I’ll reverse everything we have failed over.”

The only real downside to this option is the lack of automation. If you have someone who isn’t familiar with Zerto at the controls during an actual disaster, and you walk them through the failover process, you will also have to walk them through the Commit process as well.

So what is the best option?

Good question, but I’m not going to give you an answer. This is one of those questions where there is no right or wrong answer, it just depends on what is best for you and your situation. I’m sure there has been an internal debate at Zerto about what to make the default option. Each option has pro’s and con’s, so it’s not always an easy decision, but hopefully this article has helped you understand what each of the options will do and situations in which you would want them.

Personally, I think that once you are educated on what the options are and how to use them, that you should change the global policy to something other than Auto-Commit after zero minutes. (at least increase it to 5-10 minutes) As this locks you into whatever your first choice is. Why do I think this? More than likely, you will have disasters consisting of virus’s or data corruption many more times then you run into an actual natural disaster.

Also keep in mind that after making a choice for the default policy, you can always change it on a per failover/move basis on the execution parameters tab of the failover wizard.

Commit policy manual change
Changing the commit policy manually in the wizard

Thanks for reading, and let me know if you have any questions!

 

Zerto Cloud Service Provider How To – Part 3 Networking

Zerto Cloud Service Providers are the group of people who leverage Zerto Virtual Replication to provide disaster recovery as a service to customers who do not wish to own a DR site. Essentially they (the service provider) have all of the needed infrastructures in place to allow customers to fail over their virtual machines into that service providers environment. So what does it take to be a Zerto cloud service provider?

This article is the third in a series and will describe how I’ve done multi-tenant networking in my cloud provider lab, as well as what some of the other options are.

Overview

Networking in a multi-tenant cloud is the most interesting part of the series, for me anyhow.

Essentially the goal of networking in a multi-tenant cloud is to provide a secure, isolated network for each customer while still allowing them to get to their data.

To make these goals happen, there are several categories of networking that you will need to configure.

The first type is internal VLAN networking, meaning the networking that lives inside of your four walls and separates one customer’s data from another’s. There is also external networking, meaning networking that brings customer traffic from their site to yours. The third type is the networking that glues the previous two together; like firewalls, VPNs, and routers.

It doesn’t matter if you are the smallest ZCSP or the biggest, you will always have these three networking components in some form. Lastly, before we get started, you should note that Zerto doesn’t really care about which WAN type you pick, or what firewalls you use, etc. It works with them all equally well. The only concern Zerto has is that it can route data from one site to another.

Conceptual Layout

The easiest way to start is probably to show you one way that Zerto Cloud Provider networking can be configured.

What the following diagram is trying to show is that you can have customers with a variety of different WAN connectivity types terminating into your facility. Once inside of your four walls the traffic is processed the same way for everyone. It is first put into a VLAN, then sent to the ZCC. From there the ZCC gets the data to the proper Zerto component on the management network.

Some ZCSP’s use dedicated replication VLAN’s; others allow replication to flow through the “Failover Production” portgroup / VLAN. To Zerto it doesn’t really matter.

 

In my environment, I terminate remote sites into the same VLAN as the “Failover production” VLAN. Here is what it looks like:

ZCSP Block Diagram

Also in this diagram, you can see that the ZCSP’s Management network is completely separate from any of the customer VLAN’s. All of the shared Zerto components like the ZVM, ZCM, and VRA are all installed in the management network.

This is important the understand. For infrastructure to be multi-tenant it has to be effective at isolating tenants from each other as well as isolating ALL backend management components so that tenants cannot access them. If they are not properly isolated you do not have a secure environment.

So a ZCSP should have all of their Zerto components as well as all of their VMware vSphere components in one or more management networks that are isolated. Personally, I keep my VMware and Zerto management components all in the same management VLAN.

Replication Traffic Flow

Zerto has created a method to get replication traffic from the client data center to the management network at the ZCSP. If you look at the diagram again, you can see the component that straddles the two networks, this is the Zerto Cloud Connector or ZCC for short.

Here is an animated version of the diagram to help you visualize what is going on with replication to a ZCSP.

ZCSP data flow animation

Replication traffic generated by the client site VRA’s is sent across the WAN to the ZCC that sits at the ZCSP datacenter. The ZCC verifies the data needs to be transferred to the management network, then forwards it to the proper VRA at the ZCSP site. Management traffic is also passed through the ZCC to get back and forth through the client network.

In a sense, the ZCC is acting as a proxy server for replication traffic as well as Zerto management traffic. When you are configuring your ZORG’s (we will talk about these more in a later article), you will set up your ZCC to have an IP and default gateway pointing to the VPN router that can talk to the client site as well as an IP in your management network. The ZCC then configures the needed static routing and default gateway to make this all work.

During reverse replication, or in situations where the production VM’s are running at the ZCSP site, the data flow is the same but in the opposite direction.

 

My ZCSP networking and other options

Internal Networking

My setup

Inside my infrastructure things look almost identical to the diagrams I have used in this article. I have two VLAN’s defined for each ZORG, one production VLAN, and one test VLAN. Inside of VMware I use a distributed virtual switch and create port groups for each of the VLANs. I also create all of the VLANs on my switching gear as well.

If you read the first two articles in this series you know I’m not using NSX, so these are just regular 802.1q VLANs.

Each customer also has a pfSense Firewall doing routing and VPN work. (again because I’m not using NSX)

Other options

Internal network architecture and product selection will vary depending on budget, and how large you want to scale your environment. Remember there are about 4000 usable VLAN’s. That may seem like a lot, but if you allocate each client 5 VLAN’s each, you are now limited to about 800 customers. Plus you will probably use a few VLAN’s for management too. So to be safe let’s say that 600 is the practical limit (since some customer will probably want more than 5 VLANs.)

Keep in mind too, that I am saying that this maximum would be per core switch. So even if you have 5 POD’s as we talked about in the last article, this maximum would be imposed on as many pods as there are sharing a core switch.

 

Each customer will need at a minimum 2 VLAN’s. One for their Zerto fail-over test network, and another for their production fail-over network and replication traffic. This minimum assumes several things:

  • The customer wants a test VLAN
  • The customer only needs one production VLAN
  • Replication traffic will flow through the production VLAN

If any of the above isn’t the case, then your VLAN count per customer will vary. (That’s why I said figure 5 per customer just to be safe)

The takeaway here is that if you plan to scale more than 600-800 customers, then you may need to look at VXLAN. The only other option would be to build an entirely different POD, with different core switching. Because of the second, independent core switch, you have another 4000 VLANs to work with.

VXLAN, on the other hand, will give you about 16 million segments.

Bottom line if scalability is a concern VXLAN is probably the answer, but it comes at a premium price from VMware. It’s been a while since I reviewed the VMware service provider license agreement, but if you check you will see that there is probably still an upcharge for leveraging NSX.

External Networking

My setup

In my ZCSP lab, I am using VPN connections to remote sites. The are provided by the pfSense firewall VM’s that I talked about earlier. While they are not an enterprise class solution, they are proving to be pretty reliable and work very well for my use case. The two that I have in place have been operating flawlessly for over a year now, probably because once they are configured they “just work” and have had no config changes, just security updates.

Other options

In the real world external networking is going to vary with almost every customer. The biggest thing to remember here is that Zerto does not encrypt traffic between VRA’s and Zerto does not support NAT between any Zerto components. So, protecting replication traffic is the job of the network layer.

There are two things to remember when determining if a particular WAN connection with work with Zerto:

  • Zerto does not support NAT between any Zerto components; or between Zerto and vCenter
  • Zerto does not encrypt network traffic

 

This means that you will need to provide a single layer two network shared between sites, or you need to have layer three routing between sites. Make sure that NAT is not anywhere in the middle.

Remember Zerto does not support NAT between any Zerto components

 

WAN security is provided via a VPN or MPLS or some other type of connection that is natively secured.

Conclusion

Zerto is very flexible regarding networking. The only real requirements are no NAT and a secure connection from the client site to the ZCSP. Outside of that Zerto has no preference as to what vendor, or what type of connection you are using.

Another thing to take away is that Zerto doesn’t list a “best practice” or specific requirements on how you setup your cloud networking. All of the decisions are up to you and what is best for your customers, as long as you can deploy ZCC’s and get replication traffic from the client site through the ZCC and into the management network.

Lastly, Zerto networking is more complicated to setup than some of the other “offsite backup/DRaaS” offerings. But what good is VM recovery if it isn’t accessible? When you configure a client for Zerto replication, they are also configuring everything they need to take advantage of those VM’s once they fail over. This isn’t something that you get out of the box with a solution that is tunneling recovery data over a single SSL connection.

ZCSP Post Series

This post is post 3 of many in a series. I’d love for you to follow along and provide feedback and input as I go. If you are not already following my blog, I encourage you to sign up on the right under the sponsor ads. Don’t worry; you will only get mail when new articles get published.

For a list of other articles in this series, please visit the series homepage here.

Need more info on how to be or get started with a ZCSP? Let me know.

 

Zerto 5.0 Host Maintenance Mode Automation

This article is part of a series of posts that deep dive into the new Zerto Virtual Replication 5.0 feature set. To view the other posts check out the index post here.

Overview

VMware Host Maintenance Mode has been around since the first version of vSphere. It allows administrators to place certain hosts into a state where they are excluded from cluster HA and DRS calculations. This is extremely important if you have a host that is acting up or needs patches.

VMware also leverages maintenance mode as part of its Update Manager product for applying patches and upgrades to ESXi hosts.

Unfortunately, in all previous version of Zerto, the VRA running on each host would cause the maintenance mode operation to fail, and the host would never enter maintenance mode. The only way around this was to manually shut down your VRA before placing the host into maintenance mode.

While it sounds like more of a formality, this actually creates some interesting problems when automating administrative tasks in VMware.

What’s New

Starting with version 5.0, Zerto will recognize when you place a host into maintenance mode. Once it has recognized this, it will shut down the VRA that lives on the host and allow the host to go into maintenance mode, just like if Zerto wasn’t installed.

When exiting maintenance mode, Zerto will also automate the powering on of the VRA so that as other VM’s are migrated back to the host they can be protected.

The Video

The best way to show how this works is with a video. So this video will walk through what happens with Zerto 4.5 and then show you how the new ZVR 5.0 features help fix the issues.

Thanks for watching!

Upgrading to Zerto 5.0 Video Guide

This article is part of a series of posts that deep dive into the new Zerto Virtual Replication 5.0 feature set. To view the other posts check out the index post here.

Overview

VMware Host Maintenance Mode has been around since the first version of vSphere. It allows administrators to place certain hosts into a state where they are excluded from cluster HA and DRS calculations. This is extremely important if you have a host that is acting up or needs patches.

VMware also leverages maintenance mode as part of its Update Manager product for applying patches and upgrades to ESXi hosts.

Unfortunately, in all previous version of Zerto, the VRA running on each host would cause the maintenance mode operation to fail, and the host would never enter maintenance mode. The only way around this was to manually shut down your VRA before placing the host into maintenance mode.

While it sounds like more of a formality, this actually creates some interesting problems when automating administrative tasks in VMware.

What to remember

Before starting your Zerto upgrade to 5.0, make sure that any existing alerts have been remediated. Also keep in mind that during some Zerto upgrades the VIB driver will also need to be upgraded. This can cause a delta sync to occur if protected VMs are not migrated off on the ESXi host that you are upgrading. In the video, In the video, I walk through the workaround and how to minimize delta syncs during upgrades.

Also keep in mind that while you can mix and match different versions of Zerto Virtual Replication, you should have a plan to bring all ZVM’s and VRA’s up to the latest version. This will minimize the work that will need to be done during future upgrades and will ensure that you can support the latest version of your hypervisor platform as well.

The Video

The first thing I want you to remember is that my video editing skills are “newb” at best, so keep that in mind while you check out this video. 🙂

So without further delay, here is the video of doing a Zerto 4.5 to 5.0 upgrade. Also for the best viewing experience make sure to select 1080p as the video format. Enjoy.

A quick look at Vembu VMBackup

Vembu VMBackup is Backup and Disaster Recovery software that supports VMware vSphere,Microsoft Hyper-V, and even physical servers. VMBackup is designed to back up and replicate the virtual machines by taking snapshots of the VMs at the host (hypervisor) level.

Disclaimer: I was recently asked to review this software and while Vembu is a sponsor of my blog they, nor anyone else, have ever paid for a review by me. I also work for Zerto, so I have chosen not to review Vembu’s replication piece because let’s face it… my expectations for replication are pretty high in that area.

However, having worked with Veeam, as well as other backup products, in the past I thought it would be fun to see what some of the alternatives have to offer in the snapshot based backup space. So here we go!

Navigating the Interface

Before we dig into the meat of Vembu VMBackup I thought I would take you through the GUI a bit. I’m happy to report that it is all HTML5 and works great in every browser that I tried. In my opinion, it has a clean and organized look to it.

(Remember you can click any of these screenshots to get the full-size version)

1
Vembu Login Page

Here is a shot of the dashboard. You will spend a bunch of time here and it’s also where you can launch the live stats pop up boxes. (Keep that in mind for later.)

2
Vembu Backup job list

The Management section

There are six main sections to the Vembu Backup Interface that would get used day-to-day.

The first one that you will want to visit after installation is the Management tab. Inside of there, you can configure your backup storage location. In the limited testing that I did, I found that there are two key things to remember.

  • Move the default location off of your C:\ drive
  • You are better off to NOT use a dedupe storage device

These recommendations come from trial and error, and to be honest the Storage Management section is an area that I recommend that some improvements be made. Mainly because it was not obvious how to move the default location off the C:\ drive. Personally, I would rather remove the C:\ drive from the list all together. In my opinion, backup data should never go on a C:\ drive.

My “no dedupe storage” recommendation is because I was sending backups from Vembu to an Exagrid, and the dedupe rate was about 1.01:1. I also didn’t see any options to turn of Vembu’s compression, or optimize it for a dedupe storage device.

To make up for this pain point, Vembu has created a pretty neat file system, called VembuHIVE, that allows data to span multiple disks together to form a large backup repository. In other words, you can simply add a new drive to the server and the backup data is spanned from the old drives to the new drives. That feature is pretty awesome and is becoming more common in other backup software as well.

Normally the inability to support a dedupe storage box would be a deal killer for me. However in this case, while not really my preferred method, the design choices do make sense because of the way Vembu “grew up”. Remember that Vembu has been in the MSP space for a while, so there is a pretty good chance that their software is running on a lot of physical Windows backup servers at client sites. Why is this relevant? Well if you are in the MSP business you make money by keeping costs low, and we all know that dedupe appliances are pricey.

(BTW, when I say that dedupe devices aren’t supported, I mean that the VembuHIVE chunks don’t seem to dedupe well on the Exagrid test unit I have. They might dedupe better on different vendors’ dedupe boxes but I haven’t tested them.)

After you have your backup storage setup you can start backups.

The Backup Menu

The Backup Menu
The Backup Menu

Remember that Vembu can back up both virtual and physical machines. I personally haven’t gotten a chance to back up a physical machine because all I have are my desktops. But I have tried both the VMware and Hyper-V backup features and both work well.

The only issues that I ran into with my VMware backups were some errors about CBT. I would venture to say they were VMware problems but I didn’t investigate too deeply. Remember it’s just my lab… stuff is broke all the time.

Some other common screens

These are just some other random management interface screenshots that you can expect to see along the way. This first one is a live window of the backup job. It reports current progress and what is left to process.

Live Backup Progress Window
Live Backup Progress Window

This is one of the backup reports. It is showing a list of the jobs that I have run over the last few days and what the overall status of the job was.

Job Status
Job Status

And finally an email report, I get these every time a job completes. They are pretty easy to read and get the important information across.

Email Status Rrport
Email Status Rrport

Now let’s talk about how we get to the point where we can see all of those pretty pages and reports.

VMware Backup and Restore

VMware Backups

VMware backups are started by telling Vembu about your vCenter Server (you can do ESXi directly if you want). The process is pretty straight forward. You simply enter your hostname and credentials.

vCenter server list
vCenter server list

As you can see, in this list I have a job called “Prod-VM” that is backing up VM’s from my 10.10.1.10 vCenter server.

You simply select what VM's to backup from the list in vCenter
You simply select what VM’s to backup from the list in vCenter

In the list of VM’s you will want to select all of the VM’s that you want in this backup job.

Now we select our backup schedule. For me, that means one time per day, at night. There are options to backup as often as every hour, but remember these backups leverage VMware snapshots so be careful and make sure that they are consolidated after each backup.

Backup Schedule
Backup Schedule

Retention settings are up next. Basic and advanced settings are available. The basic setting just retains a certain number of backups, while the advanced settings roll up points into a GFS schedule.

Advanced retention
Basic retention
GFS retention
GFS retention

Next you can name you backup job, as well as view a short summary of the job.

Backup Name and Summary
Backup Name and Summary

Finally, click save and then monitor job progress or wait for the status report email.

VMware Restores

VMware restores are pretty typical, meaning that you pick what you want and it restores it to the ESXi host that you want.

Here is the process. First, you will want to navigate to the Recovery section in the main blue nav-bar. Inside of there, you will find a list of the backup jobs that you have created. Click on the restore icon to start the wizard.

Restore by selecting a job
Restore by selecting a job

Next, you have to tell Vembu what type of recovery to perform. Essentially they have to know where to put the VMDK or VHDX and what type of destination will receive it. To do a simple full VM restore that goes back into VMware I choose “Live Recover to ESXi Server”

Select the type of restore
Select the type of restore

Next up is to select the snapshot to restore. I’m doing a backup each night so I can select any of the ones in the list.

Select a checkpoint from the job
Select a checkpoint from the job

After selecting the snapshot it will allow you to select one of more of the VM’s in that snapshot.

Select the VM
Select the VM

Then there is the destination. For me, that means vCenter / ESXi. You also can pick the datastore and the VM name to restore to.

One suggestion that I would make here is that there is no option to restore different virtual disks to different datastores. So while this is simple it might make restores harder for customers who have VM’s that are larger than a single datastore.

Select a Target
Select a Target

Lastly we have our review page. Here we are reviewing what will happen and we can select finish to kick off the restore. (You can’t see that button because it’s not in the screenshot)

Select Finish
Select Finish

In order to get detailed restore information you will want to navigate back over to the Dashboard section and look for an activity under the client tab. There will be one with a green down arrow. If you click it, it will launch the “live” details pop-up.

Backup Progress
Backup Progress

Here is a closer shot of the live details restore dialog. Also after the restore has completed you will also get a follow-up email letting you know that it has finished. That’s a nice touch if you decided to run and grab food while it was restoring.

Progress realtime
Progress real-time

I didn’t try all of the VMware restore options. I figured that a full VM restore is probably the most common, maybe I’ll do the others in a future deep dive article after I have more time with the product.

Hyper-V Backup and Restore

Hyper-V Backups

Hyper-V backups are the same process as vCenter with one exception, at least from what I could tell. The one exception is that I didn’t see anything labeled as “SCVMM”, so I’m guessing you have to add each Hyper-V host individually. My biggest concern with that is what happens when your VMs live migrate to another host? If I had a second Hyper-V host setup I would tell you, but I don’t.

Anyhow here is the process for what I could test. First off you have to add your Hyper-V hosts to Vembu. I tried to add an SCVMM machine but got an error.

HV1
Select Standalone or SMB3 host type

Then enter the host’s specific details like credentials and IP or hostname.

HV2
Give Vembu your Hyper-V server’s details

There are two more steps in the wizard to add a Hyper-V host, however, it wouldn’t let me go back through those steps of the wizard since I have already added my host. Anyhow you will figure it out, it’s not hard.

After adding your host you can then start to create backup jobs. To do so, click the icon under the Backup Now column.

HV3
Here is the Hyper-V server list where you can start the backup job wizard

In order to back up a VM, you will want to select it in the list. You can also exclude VMDK files if you would like by clicking on the blue button to the right.

HV4
Select the VM’s to be backed up

Now we schedule the job. You can run it as often as hourly, or daily, or weekly.

HV5
Schedule the job.

After scheduling when to run you can then select how many backups to keep in total. Under the advanced setting, you can also pick a typical GFS configuration as well.

Also on this screen is where you can also configure periodic full backups as well.

HV6
Retention settings, just like VMware

The last thing to do is give the job a name. Personally, I like naming the job at the end because it gives me a chance to grab the VM’s first and figure out what will all be in the job.

HV7
Job summary

If you want to see the real details of the job then you will want to go back to the client activity dashboard and launch the live stats pop-up.

HV8
Live backup stats

But in the end what good are backups with the restore. 🙂

Hyper-V Restores

If you read through the VMware Restore section…. you can probably skip this section. 🙂 LOL

There is really only one difference, and it’s pretty annoying to me. Vembu makes you enter your Hyper-V server UNC path where you want the data restored to. It makes no sense to me because the software already knows where my Hyper-V server is…. Why not just pull that info?

Here is what I’m talking about.

hvr5
Enter your Hyper-V server info to restore to.

I’m sure this will be fixed in a future release and will act more like the VMware restore process. It’s certainly not the end of the world, just something that delays restore time because I might have to go look up the info.

At the end of the day, the bottom line is that Vembu was able to restore everything I asked it to do… both Hyper-V and VMware.

Pricing

There are few companies that have an MSRP that is also their street price. So please do your homework before purchasing. These prices are just what I could find online, and I have to believe they are MSRP. Check out my “What I learned about IT purchasing” article if you need the inside scoop on how many companies operate.

Vembu VMBackup is priced a little differently than most of the products you are probably used to. Instead of the traditional perpetual model where you buy the software and then pay an annual maintenance fee for upgrades and support… Vembu has rolled it all into a single line item, but you pay the same price every year. So the upfront cost to get Vembu is relatively low compared to a more traditional model like Veeam.

For example, let’s say that you have a four host cluster, here is roughly what pricing would look like.

(Remember this is purely theoretical because it’s been almost 2 years since I quoted Veeam to a customer.)

Prices for the VMware licenses:

Year Vembu Veeam
1 $360 * 4 hosts = $1440 ~$3055 * 4 hosts = $12220
2 $1440 $12220 * 15% = $1833
3 $1440 $1833
4 $1440 $1833
5 $1440 $1833
5YR TCO $7,200 $19,552

Prices for the Hyper-V licenses:

Year Vembu Veeam
1 $240 * 4 hosts = $960 ~$1330 * 4 hosts = $5320
2 $960 $5320 * 15% = $798
3 $960 $798
4 $960 $798
5 $960 $798
5YR TCO $4,800 $8,512

This assumes that pricing doesn’t go up on either product, etc etc. (All pricing was obtained via the vendors website.)

So Vembu is about half the cost over 5 years compared to Veeam.

VMBackup Pricing
VMBackup Pricing

Closing Thoughts

Vembu seems to be breaking into the virtualization space and is quickly releasing new features. There are some things that I think Vembu will need to put some dev time into. Mainly to refine the logic behind the scenes, as well as the stuff I listed throughout the article.

The Hyper-V UNC path stuff aggravates me too LOL, but overall the product was able to back up everything I threw at it. And as you can see from my screenshots, it has been running pretty well for almost the full 30 days of the trial key.

I would like to see a few other things added to Vembu too. First would be global dedupe. In my opinion, the savings of global dedupe shows a real value when customers start asking for GFS scheduled backups, or the ability to retain many full backups. I wasn’t impressed with the dedupe rates that a 3rd party dedupe box was able to do, so IMO they should just build it in. If they did, and they combined it with the ability to scale out disks in a backup appliance, I think customers would find that as a great selling point.

The last feature that I would ask to be added is more stats around compression rates. If they are in there, then they are hidden pretty well because I wasn’t able to find them. Actually, while we are at it… let’s just say more stats in general… if there is a metric somewhere show it to me.

Vembu does have some of the “nice to have” feature’s like item level recovery of the major Windows applications already built-in. So overall I think that Vembu is a pretty good contender and will gain traction as features are added and more customers look to exit from higher priced backup packages. After all … most backup software uses the same VMware API’s for Data Protection… and most are able to perform both file and item level restores. So it really comes down to what type of interface you want to work with (ie your personal preference), what special features each package has, and the most important…. what your budget is.

As always thanks for reading!

Zerto Virtual Replication 5.0 Generally Available

The wait is over!

waitisover

Zerto announces General Availability of Virtual Replication 5.0!

Whether you are a current Zerto customer or not, you will want to check out the latest release of ZVR 5.0. The team pulled out all the stops to release two major releases in the same calendar year, and both are jammed packed with features!

In release 4.5, Zerto added File-Level Recovery, journal compression, enhanced API support, and AWS S3 encryption.

Now new features in 5.0 include

  • 30-day journal
  • Replication to Microsoft Azure
  • One to Many Replication
  • Mobile SaaS monitoring
  • VMware Host Maintenance Mode Support
  • Zerto Licensing Tiering

Several other features and improvements have been added in 5.0 as well. Check out the release notes for the complete details.

For each of the major new features, I have put together some deep dive posts that explain how the new feature works. Some are even complete with video walkthrough as well!

Zerto 5.0 New Feature Deep Dive Posts

Replication to Azure

One to Many Replication

Mobile SaaS Monitoring

30-Day Journal

ZVR 5.0 Video Posts

VMware Host Maintenance Mode Support

Upgrading to Zerto 5.0 Video Guide

Licensing Changes

Zerto licensing has a couple of new changes that affect 5.0. For all the details check out this deep dive post.

Zerto 5.0 Licensing Deep Dive

Feedback

Zerto is always looking for customer feedback. Please, feel free to leave a comment here, or shoot me an email, or open a support ticket. We want to improve constantly, and the best way to do that it to understand your real world use cases.

Zerto 5.0 Licensing Deep Dive

This article is part of a series of posts that deep dive into the new Zerto Virtual Replication 5.0 feature set. To view the other posts check out the index post here.

Overview

If you have known Zerto for any amount of time, you know that licensing is the easiest thing possible. For the longest time, there were probably only three SKU’s (I’m kidding of course), one SKU for the product, and two SKUs for maintenance (one being 8×5 and the other being 24×7).

Zerto’s price tag has been rock solid as well. In fact, there hasn’t been a price change for maintenance or the product in over 5 years. (Has any other software vendor made it that long?)

However, with 5.0 some things have changed.

What’s New

Starting with version 5.0, Zerto will now have three licensing models for customers to choose from, there were 2 models before 5.0. The two existing models are the standard package for VMware and Hyper-V platforms (private cloud), as well as the public cloud platform(AWS and Azure). The new version is called “Enterprise Cloud Edition” or ECE for short.

With ZVR 4.X licensing you could essentially replicate between private cloud hypervisors and you paid per protected VM. If you wanted to go to the public cloud, you had to purchase a second license that was a subscription based license and was only good for VM’s destined to AWS.

In ZVR 5.0 things stay the same for the two existing license packages, but one of the enhancements for ECE is that you can shift your protected VM’s between private cloud and public cloud while using the same license. So if you are considering replication to Azure or to AWS, and also have a private cloud workload, ECE is probably the best choice for you!

What version fits you

Here is a matrix of what licensing looks like to help you select what is best for you:

Platform Zerto Virtual Replication ZVR to Public Cloud ZVR – Enterprise Cloud Edition
VMware vSphere
Microsoft Hyper-V
Replication to Azure
Replication to AWS
Replication to ZCSP

ECE Features

These features are NOT included in ZVR 5.0 Standard – Only ZVR 5.0 ECE, so if you want to use any of the below you will need to upgrade to ECE.

  • License mobility – use license for private or public cloud replication
  • Multi-Site Replication
  • Zerto Cloud Manager
  • Cross Hypervisor replication

Why the new changes?

Please note that this section is 100% my opinion. It may or may not be the view of my employer, but I did not check with them before writing this post.

The features that are included in the new Enterprise Cloud Edition of Zerto hold a significant value for the customer that need them. Customers who are replicating from site A to site B, however, would see little to no value added to the product.

So the powers that be had a decision: continue to provide all features to all customers – but raise the price for all customers. Or split the more advanced features into a premium version so that customers who need the premium features can pay for them, while keeping the price tag the same for the customers who do not. They choose to do the latter.

At first, I have to say that I was sort of mad about splitting the product into two versions, but since the initial internal announcement I have found that it makes sense and will be the best direction for the product long run.

Leave some feedback

Zerto is always looking for customer feedback. Please, feel free to leave a comment here, or shoot me an email, or open a support ticket. We want to constantly improve, and the best way to do that it to understand your real world use cases.

Zerto 5.0 – 30 Day Journal

This article is part of a series of posts that deep dive into the new Zerto Virtual Replication 5.0 feature set. To view the other posts check out the index post here.

Overview

With the 5.0 release of Zerto Virtual Replication, the maximum journal history has been increased from 14 days to 30 days. In a typical disaster recovery situation, being able to rewind time all the way back to 30 days in the past is not that useful. I mean come on, who would really give up an entire month of data to recover from a datacenter fire? No one.

However, if you pair a 30-day journal with Zerto’s Journal File-Level Recovery, introduced in version 4.5, you can see where we think the value is. There certainly is a use case for being able to quickly recover individual files as old as 30 days in the past.

Is there value in an extended journal?

You might be saying, well I have backup software for file restores, and I wouldn’t argue with you if you did. However, Zerto gives you granularity that you will never find in backup software.

Because Zerto is “always-on” and essentially streaming data changes to the other side, you literally can recover data from almost any point in time during the previous 30 days. If you don’t think there is value in any point in time recovery, I would ask you to talk to your accounting person. Ask them how upset them would be if they had worked on a document from 8 am until 4:30 pm, and then a virus encrypted the file. Essentially causing their entire day to be lost. If you told them that your backup software had a copy from yesterday, but all of their work today was gone, they might be upset. (Probably not as upset as if you told them that you didn’t have a backup, but still upset).

Data Protection with Snapshots and Backups
Data Protection with Snapshots and Backups

Zerto, on the other hand, would have a BUNCH of restore points that have that file in it. In fact, if you have sufficient bandwidth you can have checkpoints as often as every few seconds. So if your data gets encrypted at 4:30 pm, you could recover a copy from 4:29:50 pm.

Zerto's Journal Technology - now with 30 days of history
Zerto’s Journal Technology – now with 30 days of history

With a 30 day journal, you can now offer similar recovery all the way back to 30 days ago.

Do I still need backup software?

In my opinion yes. Zerto is meant for disaster recovery and for file recovery from points as late as 2 seconds ago or as old as 30 days ago.

If you need something from day 31 you would have to be using the Zerto Offsite Backup function. The downside to Zerto’s Offsite backup is that it’s done on a VPG basis. So if you want a single file or a single VM from a VPG with many VM’s, you would need to recover an entire VPG to grab a single item.

So for granular recovery older than 30 days, you will probably want something that looks more like “backup” software.

Zerto also has no intention (that I know of) to go to tape or to protect physical servers, so backup software is still a must in certain situations.

Bottom line, Zerto can now augment your backup strategy and may reduce your dependence on your regular backup software. But having multiple copies of your data, grabbed by multiple technologies is NEVER a bad thing.

How do I get started?

Getting started with Zerto’s 30-day journal is super easy. All you do is edit your VPG and change your Journal SLA to a new value, up to 30 days.

It will then automatically be available for both file restores as well as moves, failovers, and test failovers.

The only requirement is to be running ZVR 5.0 code.

Leave some feedback

Zerto is always looking for customer feedback. Please, feel free to leave a comment here, or shoot me an email, or open a support ticket. We want to improve constantly, and the best way to do that it to understand your real world use cases.

Zerto 5.0 – Mobile Monitoring

This article is part of a series of posts that deep dive into the new Zerto Virtual Replication 5.0 feature set. To view the other posts check out the index post here.

With the release of Zerto Virtual Replication 5.0, there is a brand new way to monitor your Zerto infrastructure.

DR monitoring in your hand

How many times have you wondered if vSphere Replication or your SAN based replication was working? Chances are if you wanted to know, you had to break out your laptop, probably start a VPN client, and then remote in.

Zerto Mobile aims to simplify the process by putting the data right on your mobile device.

Zerto Mobile Main Screen
Zerto Mobile Main Screen
VPG Status Screen
VPG Status Screen

 

How it works

Zerto Mobile is delivered as Software as a Service, meaning that all the data resides in “the cloud.” The data is sent to Zerto’s cloud server from your Zerto Virtual Managers and is then retrieved by your mobile from the cloud server.

It’s important to note that there is no VPN connection needed. Instead, all data travels over SSL encrypted connections. Just to make things even more secure, the only people who can see your data, are those who you authorize to see your data.

Bottom line, we secure it the bests ways possible and look to you to give authorizations to people you trust.

Check your alerts from the golf course

Besides showing off your LOW RPO to all your buddies, you can also investigate any alerts that might be present.

Mobile Alerts List
Mobile Alerts List
Alert Details
Alert Details

You can even dig into each alert to see details of what is causing it.

If you determine that further investigation is needed, you can always break out your laptop and that VPN connection. But if things are OK then you saved yourself a lot of time and can get back to the rest of your day faster.

No mobile remediation… yet

I know what you’re thinking. If you have kids like I do, you know that they love to go into whatever apps are available. Have no fear; Zerto Mobile is currently for MONITORING only.

Let me repeat; currently, you cannot initiate a failover or any other actions from Zerto Mobile.

These features are TBD and may be included at a later date, but remember I’m just an SE so until you see an official statement it’s just my opinion.

How to get started

There are only a few requirements to get started with Zerto Mobile.

  • At least 1 ZVM running ZVR 5.0
    • Make sure to enable Mobile reporting during the installation/upgrade
    • It must have internet access
  • Mobile Device with “Zerto Mobile” installed
  • MyZerto account using your corporate email address

Once you have your MyZerto login information, and you have upgraded to Zerto 5.0, you can download the mobile application and sign in using your MyZerto credentials.

Once signed in status information will automatically start downloading to your mobile.

Leave some feedback

Zerto is always looking for customer feedback. Please, feel free to leave a comment here, or shoot me an email, or open a support ticket. We want to improve constantly, and the best way to do that it to understand your real world use cases.

Zerto 5.0 – Replication to Microsoft Azure

This article is part of a series of posts that deep dive into the new Zerto Virtual Replication 5.0 feature set. To view the other posts check out the index post here.

Zerto has expanded its public cloud support with the release of Zerto Virtual Replication 5.0. With the release of ZVR 4.0, support for Amazon Web Services was added to Zerto’s replication package.

Architecture

If you are familiar with Zerto’s architecture for AWS you will find that Azure operates the same way from the Zerto perspective. All of the Zerto components at your private cloud site (ie VMware / HyperV) are the same – you still have a Zerto Manager and VRA’s.

There is only one component at the Azure site, a ZCA, or Zerto Cloud Appliance.

Zerto's Azure Architecture
Zerto’s Azure Architecture

Your replicated data is stored as Azure blobs. Journals get 16MB block blobs, and replica disks are stored as single page blobs. If you don’t know how to set up Azure blobs, don’t worry, Zerto takes care of all of the Azure storage requirements for you.

Requirements

The Azure specific requirements include a working Azure account, a connection to Azure, and a ZCA to be configured. Connectivity options include VPN, or Azure ExpressRoute, and the ZCA should be configured as size: D3 v2.

In order to replicate to Azure you will need to be running ZVR 5.0 at your VMware/HyperV site, and you will need to contact your Zerto account team in order to get access to the Azure bits.

Limitations

As with anything, there are some limitations with Zerto replication for Azure. The largest of which is that today replication is only “to” Azure, and any failback operations have to be done with a V2V type tool. Microsoft’s level of involvement has been tremendous from what I have heard though, and I suspect that automated reverse replication and failback is right around the corner.

Some other things to keep in mind:

  • Maximum disk size of 1TB (per disk), which is the maximum Azure page blob size
  • Only Windows and Linux OS versions supported by Azure are supported for replication
  • RTO’s are much better than they are with AWS

Leave some feedback

Zerto is always looking for customer feedback. Please, feel free to leave a comment here, or shoot me an email, or open a support ticket. We want to constantly improve, and the best way to do that it to understand your real world use cases.