Let’s face it – backup software is not the most exciting thing for a CIO in today’s world. I mean, 99% of the time it sits idle, backing things up, spewing out reports – for the most part its somewhat of money sinkhole in an environment – but when push comes to shove and someone has deleted that important email, or that mission critical server fails – when a recovery or restore option takes place a piece of backup software can make or break a business! Whether you are a simple SMB or a large enterprise backup could almost be classified as one of the most important things to your organization – so it has to be easy, intuitive, and reliable! Nakivo, with their flagship Backup & Replication has taken that exact approach when developing their software! Nakivo, headquartered in the infamous Silicon Valley was founded just in 2012 and after 4 fast-moving years have just released version 6.1 of their product. This is one piece of software I have been hearing a lot about, but never had the chance to check out. With that said I grabbed an NFR key from them and put it in the lab – and here are my thoughts.
[symple_box color=”yellow” fade_in=”false” float=”center” text_align=”left” width=””]Disclaimer: This review is sponsored, meaning I did receive compensation in some sort of form for writing this! That said, as always, any review I post on my site is solely my words and my opinion and in no way was modified or changed by the vendor![/symple_box]
Architecture
Before we dive directly into the installation its best to first explain a little around Nakivo’s architecture. Nakivo is really broken down into three main components; a Director, a Transporter, and a Backup Repository.
The Director
We can think of the Director as somewhat of a management plane for Nakivo – providing the user interface we log into and maintaining lists of our virtual infrastructure. It also handles the creation, configuration, and scheduling of our backup job environment. We only need one instance of the Director as it can handle multiple vCenters and standalone ESXi hosts.
The Transporter
The next component, the Transporter is our heavy lifter. The Transporter is the data mover per say, performing all of the backup, replication and recovery operations as it receives its respective instructions from the Director. The transporter also handles features such as compression, encryption and deduplication. When we install a Director we will automatically get one “Onboard Transporter” installed on the same machine by default which cannot be removed. That said, as we find we are processing simultaneous VMs and processes at once we can scale our backup environment by adding additional standalone transporters to help with the lifting! As we do so, we also get network acceleration and encryption between transporters as data is passed back and forth. Finally we have the Backup Repository.
The Backup Repository
This one is pretty self explanatory in the backup world. It’s a container or pool of storage to hold our backups. This can be a CIFS share or simply any local folder or storage attached to a transporter. Again, when we initially install our Director we also get an “Onboard Backup Repository” to use by default.
Installation
Alright, with a little background knowledge behind us it’s time to get Nakivo deployed and wow, talk about some options!!!! Deploying Nakivo Backup & Replication should satisfy just about every environment out there! If you are primarily a Windows shop, simply use the Windows installer – Does your environment mainly consist of Linux-based distributions – hey, simply install the Linux package! Or, do you prefer the ease of simply deploying appliances – they have you covered there as well with ova based virtual appliances! Keep in mind that it doesn’t matter which installation method you chose – in the end you are left with the same product. For the sake of this review I’ve chosen what I think might be the most common installation method – the Windows-based install.
So on with the install! I’ve chosen the “Full solution” option as my installation type – meaning I will get an all-in-one install of a Director, Transporter and Backup Repository on the same machine! Certainly this might not be ideal for a production environment, but suffices in the case of my lab. As you can also see , the first screen allows me to specify where exactly I’d like to create the repository as well.
One click later…
Wait what!?!?! Yeah – one click! One click and we are done with the Windows installation of Nakivo Backup & Replication! As for the other installation types they are just as easy – Linux requires the execution of a single command, and we all know how simple deploying a virtual appliance is! If you are looking to protect an Amazon instance, a simple link to a deployable AMI is provided as well!
Configuration
Time to start configuration the product now! Just a note, I really dig the earth/space image that is displayed by default in the UI. It’s kind of a nice break from the standard box type login screens you see in most products.
Upon first launching Nakivo you will be prompted to set up a username and password. After doing so you will be brought into their Configuration wizard and as you can see below only they only require three types of information; Inventory, Transporters and Repositories – This wizard, along with many others within Nakivo are short and to the point – and clearly make sense in the simplest terms – think, What to back up, how to move it, and where to put it – easy right?
As far as Inventory and VMware goes we just need to point Nakivo to our vCenter Server and provide it some proper credentials – from there the product goes out and discovers our inventory and allows us to add it into Nakivo Backup & Replication.
The Transporter section allows us to add/import any existing Transporters we may have already installed in our environment – be them on vSphere or Amazon AWS if we chose to do so. As we mentioned earlier this review will simply use the “Onboard transporter” that is installed by default.
Lastly we can set up any Backup Repositories we want to have within our backup environment – again, I’m sticking with the default “Onboard repository” we setup during the installation, but if need be we can create new or import existing repositories into Nakivo during this step.
Once we are done we are brought into the Nakivo Management UI where we can begin creating jobs and backing up our environment – but before we go to far there are some other configurable options we change that weren’t included in the initial bare-bones wizard.
I’m not going to go through all of the configurable options but I’ll highlight a few common settings normally setup within environments as well as some very “nice to have’s” that Nakivo includes…
- General->Email Settings – here we set up our SMTP options in order to have Nakivo send out alerts and reports.
- General->Branding Settings – as mentioned earlier we have complete control over modifying the look and feel of Nakivo, uploading our own logos and backgrounds as well as support and contact information
- General->System Settings – This allows us to specify how long we store job history and system events, as well as setup any regional options we prefer such as week start days, etc.
- Inventory – Here we can add multiple vCenter/ESXi hosts as well as AWS environments
- Transports/Repositories – Again, this is where we can manage or add any new transports or repositories to the system.
- Licensing – Handles the changing of licenses for the product.
So on to the job setup
Now that we have Nakivo configured it’s time to start creating some jobs and see just how the product performs. From the main dashboard we can do this by simply clicking the Create button. As you can see to the left we have a variety of different jobs we can create, and depending on what you have set up within your inventory some may be unavailable to us. For instance I don’t have an Amazon account attached to my instance of Nakivo so I’m unable to create a job to back up or replicate EC2 VMs. That said we did add our vCenter into our Inventory so let’s go ahead and select ‘VMware vSphere backup job’ to get started…
As you can see above, the vSphere backup job creation is again in a wizard type format, firstly requiring us to select just what VMs we would like to process with this job. We do this by either browsing through the inventory presented, or filtering with the search box provided, then checking the box next to our VMs we’d like to back up. We can also select parent objects here as well, such a host, cluster, or vCenter, which would in turn backup all VMs residing within the parent. This is useful in the event you want to capture and newly created VMs in the environment without having to modify existing jobs every time. If selecting multiple VMs during this stage you can drag them around within the right hand pane in order to set priority preferences for processing – ensuring certain VMs are backed up before others, for now I’ve selected just my Scoreboard VM.
The second step deals with repository selection – we’ve already selected what we want to back up, now it’s time to say where to back up to. Selecting ‘Advanced’ and expanding out our VMs we can see that we can globally select a repository for the job, yet perform overrides as well on a per-vm per-disk basis –giving us the granularity to place certain VM disks on certain repositories if we chose to do so.
Thirdly we setup the job schedule, with shortcuts to all days, workdays, weekends etc which can change depending on our regional settings we have setup within the system.
Lastly we setup our job options. It is here where we give the job a name, select our retention cycles for the job and execute any pre/post job scripts we might want to kick off – all of the standard features you expect from a backup solution – but there are some additional options available here as well we should have a look at…
- App-aware mode – instructs VMware tools to quiese the VM before backing up, allowing applications to ensure they are in a consistent state.
- Change Tracking – This is a common feature provided by VMware that allows backup application to process just those blocks that have changed since previous backups, speeding up the time it takes to create an incremental backup. Here we can select to use either the VMware version (preferred) or Nakivo’s proprietary version (available if no other CBT exists).
- Network Acceleration – if backing up over a WAN or slow LAN links this option will leverage compression and other reduction techniques to speed up data transfer
- Encryption – this option will encrypt data that flows between transports. Since we have only one transporter, this option is not available to us.
- Screenshot Verification – This option will use a Nakivo technology called Flash VM Boot (we will cover this later) that will automatically recover our backups in an isolated manner and take a screenshot of the VM for inclusion in the Job Reports and notifications.
- Recovery Points – here we can specify how many daily, weekly, monthly, and yearly recovery points we would like to maintain.
- Data Transfer – Allows us to specify how Nakivo gets to the source data (Hot Add – mounts VM disks to the transporters, SAN – retrieves data directly from a FC or iSCSI SAN lun, or LAN – network access to the data). We can also specify which transporters we would like to use for the job here if we had multiple transporters on different networks, clusters, etc.
After clicking ‘Finish’ we can now see that our ‘Run Job’ tab in the dashboard is active and displays our newly created job. As we can see above our new job is indeed running, with the status being updated in the Job Info section of the dashboard. I really like the way Nakivo has displayed this data. We can see everything we need to know about any given job, as well as it’s run status, resource usage on any transporters its utilizing and the events and job status on all on dashboard. When the initialization of the job is complete, the UI switches to different view showing the speed and data transferred – A very intuitive design for a UI. The only thing I’d love to see here is the ability to break this information out into another window without having to open a new tab.
But it’s Nakivo Backup AND REPLICATION
Now that we have successfully backed up our Scoreboard VM its time to have a look at replication. The process for creating a replication job is similar to that of a backup, simply click ‘Create’, and select ‘VMware vSphere Replication Job’. Again, we are presented with a similar 4 step wizard. Step 1 we select which VMs we wish to replicate, again with the options of selecting parent containers.
Step 2, as shown above, presents us with some different options than that of a backup. Since we are replicating VMs, they will be stored in their native VMware format, therefore, instead of selecting a repository as a target we need to select another ESXi host. As you can see above I’ve simply selected to replicate my ConcessionStandPOS VM from it’s location in Montreal, to another ESXi host located in Brossard for DR purposes. Again, Step 3 allows us to create a schedule for the replication to occur with the exact same options as that of a backup job.
Step 4, shown above, is similar to that of the backup job options with a few added options. We still have the ability to select our transporters and transport mode, as well as set recovery point retention settings, and finally perform the Screenshot verification as well, however we have a few new options to configure outlined below
- Replica Names – append/prepend a string to our VM name for the replica, or allows us to specify individual names on a per-vm basis
- Replica Disks – Allows to specify to maintain consistency in terms of disk type for the replica, or specify that replicas are only stored thin-provisioned.
Once we click Finish again we will see our newly created job on our dashboard. One item of interest here is that by default Nakivo doesn’t group our jobs, meaning backup and replication jobs are intermixed together. They are distinguishable by the small icon next to them but if you want to further distinguish between the two visually we can click ‘Create’ and then ‘Job Group’. This essentially creates a folder that we can drag and drop our jobs in and out of, allowing us to create a Backup Job Group and a Replication Job Group. Job Groups also allow us to perform bulk operations on all jobs within that group, such as starting, stopping, disabling and enabling, etc…
When it really matters…
We can do all of the backing up and replicating we want, but when push comes to shove we all know that it’s the recovery that matters most! All recovery within Nakivo is done on the ‘Recover’ menu in the main dashboard. As you can see to the left we have a variety of options when it comes to recovery in Nakivo, with each explained below…
Individual Files
This allows us to recover individual files from a VM backup within Nakivo. After selecting our backup and then a desired restore point or point in time to restore to, Nakivo will mount the deduplicated, compressed backup file to its Director interface. In the end we are presented with file browse dialog box, allowing us to select individual files, folders, partitions, and drives. From there we have the options of either downloading these files directly to our Nakivo server, or whatever client you happen to be running the Nakivo UI on, or forwarding them via email.
Microsoft Active Directory Objects
Active Directory objects are treated somewhat the same as a file level recovery. The backups are mounted in their compressed and deduplicated state to the Nakivo server. From there you can browse or search for individual objects and recover them directly to your client machine. The AD objects are downloaded in a .LDIF format, which allows for easy importing directly back into Active Directory.
Microsoft Exchange Objects
Similar to that of Active Directory objects Nakivo can restore Microsoft Exchange items as well. With this, we have the ability to search for and recover items such as emails, folders, mailboxes, etc. The items are downloaded to the client machine, or alternatively forwarded via email to an address of your choosing.
VMs from backup
If you need to restore an entire VM this is the option you would most likely chose. Nakivo allows you to restore a complete VM from a backup file – at which point it extracts the data from the deduplicated, compressed backup file and re-registers a VM on a host of your chosing, either preserving the VMs UUID, or creating a new one. Just as in replication, we are able to restore the VM to it’s original disk type, or force it to be thin-provisioned. We can also specify whether we would like our recovered VMs powered on, and whether or not we would like to change or preserve the MAC address on the recovered VM.
VMs from replica
Failing over to a replica within Nakivo is a very easy process. Essentially you simply select which VM you would like to fail-over, select a time frame in which you want to fail-over to and run the job – after that, Nakivo simply places the replica in the correct point in time snapshot and powers it on. When completed you are left with an absolute copy of your VM, recovered almost immediately.
Flash VM Boot