Latest posts by Paul Schnackenburg (see all)
- Repair a corrupt EDB file with Stellar Repair for Exchange - Tue, Jan 14 2020
- Fixing WSUS issues with the SolarWinds Diagnostic tool for the WSUS agent - Tue, Nov 26 2019
- ManageEngine Desktop Central: Unified endpoint management for Windows, Linux, and Mac - Wed, Sep 18 2019
Nakivo provides both backup (lots of recovery points going back in time so you can recover from accidental file, email, or database deletions, ransomware attacks, and for regulation compliance) and replication (VMs replicated from one location to another for fast disaster recovery).
Nakivo runs on Windows (2008 R2 to 2016) or Linux (Ubuntu, SUSE, and Red Hat Enterprise, many different generations). There are two main components. The Director gives you the web interface and coordinates all backup jobs. The Transporters actually perform the backup jobs. If you co-locate them on the same machine, you'll need two cores and 4 GB + 250 MB for each concurrent job (the default maximum is 6GB). Interestingly, you can also run Nakivo on network-attached storage (NAS) devices for an "all-in-one" backup appliance. Supported NASs are Synology, QNAP, ASUSTOR, Western Digital, and Netgear.
If you have a VMware environment, you can also deploy Nakivo as a Virtual Appliance. It comes with a 20 GB OS disk and a 500 GB backup repository disk (which is deployable with thin provisioning, saving space initially). Note that you can't expand this disk; you'll have to attach additional disks to expand the amount of backup space. The maximum size of each backup repository is 128 TB.
It's interesting to see that Nakivo isn't just for SMB scenarios. There are guides for simple single-site deployments but also for distributed scenarios where the Director in the head office coordinates backups across the Transporters in several branch offices. You can be back up these locally first and then replicate them to another location using a Backup Copy job. Providing great flexibility is the ability to mirror a repository from one location to another or just pick the important VMs or backups that particular jobs create for a secondary copy.
You can even choose to have different compression settings for the two repositories (fast for the primary copy and best for the secondary copy) and different retention policies, perhaps keeping local copies of the last couple of weeks but storing multiyear backups in a secondary location. Nakivo has bandwidth rules for compression (up to 50% savings) and throttling options to control how much your backup jobs use your WAN pipes. These are comprehensive with global and per-job rules giving you full control over bandwidth allocation.
Finally, Nakivo has built-in functionality for multitenant service provider configurations. The web UI is trimmed so tenants can only see and interact with their own jobs, but the service provider or managed service provider (MSP) can see all sites, repositories, and backup jobs.
You can configure backup and replication from remote sites to the master site (the Transporter in the remote site talks to the Transporter in the master site) as well as local backup and replication for each site. Replication has support for assigning new IP addresses to the VMs when recovering them on the replica servers.
You can schedule emails with PDFs for errors, warnings, and tenant reports. There's an option to create a support bundle (a zip file of logs and system configuration) when a problem occurs and send it to the MSP. A built-in support chat even allows tenants to interact with their service providers.
Under the hood, Nakivo relies on VM snapshots and uses the forever-incremental model where the initial backup is the only "full" one of all the data. Every subsequent backup (up to once per minute) only copies changed data. But each of these incremental copies can comprise a full backup of that VM at that point in time.
You can set up protection for containers (clusters, folders, or resource pools) to protect VMs created later automatically by backups and replication. Nakivo has built-in data deduplication (based on 4 MB blocks). This is very useful for VM backups since each VM often has a lot of the same data, at least on the OS disk. If you're backing up to a device that supports native deduplication, Nakivo automatically disables its deduplication.
Configuring options for a backup job
For VMware there's an option called Hot Add to have Nakivo read VM data directly from your data stores. This bypasses the TCP/IP stack in the OS and thus provides better performance.
Tape backup isn't built into Nakivo (this is true of most modern backup solutions), but you can schedule detaching a repository from Nakivo. This makes it available to copy it to backup tapes and then automatically attach it again for normal backups to resume. You can stage (seed) initial backups, particularly useful where you have a large amount of data on the wrong side of a WAN link. You can back it up to a repository on a removable disk, detach it, and courier it to the other side.
Nakivo is licensed on a per-CPU socket basis for each server where you back up or replicate VMs. Note that you don't need a license for the replication target server(s). Amazon Web Services (AWS) is licensed per instance.
Interestingly, Nakivo supports AWS in several different ways. You can deploy Transporters in AWS, which lets you back up and replicate VMware VMs to AWS as well as backup and replicate Amazon Elastic Compute Cloud (EC2) instances to another region in AWS. There's an option to run the Transporter only when required, saving costs for running the Transporter EC2 instance.
Restoring a large VM from backup can take time, and like other backup products, Nakivo offers Flash VM Boot where the VM runs directly from the compressed and deduplicated backup storage, providing quick recovery. Take care when you have the VM up and running. If you actually want to continue using it (in the case of deletion or corruption of the original VM) and you're not just testing it, you'll want to move it to another location.
You can restore individual items from file servers, Exchange, and SQL Server. Nakivo is aware of the latter two applications and can also truncate logs after backup jobs have run.
A challenge with backup at scale is verifying it's possible to recover the protected VM, particularly for an MSP that may have hundreds or even thousands of VMs under management. Sure, you can manually restore a VM, log in to it, make sure it starts OK, and verify the application and data are happy, but that doesn't scale well. Nakivo has a feature called screenshot verification where it'll Flash Boot the VM (without networking), take a screenshot of the OS after booting it, email a report, and then discard the VM. Note that a successful boot doesn't necessarily guarantee that applications inside the VMs are working correctly.
You can also do cross-platform recovery where you can convert a backed-up VM from one platform to another.
I installed Nakivo in my four-node Windows Server 2016 Hyper-V Storage Spaces Direct cluster. Initially, it didn't recognize my cluster (only individual Hyper-V hosts). However, an unplanned power outage solved this. After restarting the hosts, Nakivo saw the cluster, and configuration was easy. I like the combination of backup and replication in a single product—it makes a lot of sense. I find Nakivo to be exceptionally competent across the VMware stack and also strong for Hyper-V deployments and AWS. Yet I would like them to add Azure to the list of supported clouds in the next version.