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]
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.
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 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.
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!
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.