In this first Nakivo article, we will install Nakivo Backup & Replication on Windows 2012 Server.
These are the minimum requirements to install in a Windows Virtual/Physical Machine:
NAKIVO Backup & Replication can be installed on a virtual or physical machine with the following characteristics:
Director and Onboard Transporter:
- CPU: x86-64, 2 cores
- RAM: 4 GB RAM + 250 MB RAM for each concurrent job
- Free space: 1GB
- CPU: x86-64, 2 cores
- RAM: 2 GB RAM + 250 MB RAM for each concurrent job
- Free space: 1GB
For this particular Install/ Find here my System details:
Nakivo Backup & Replication Version: 6.2.0 (build 14770).
SO: Windows 2012 R2
CPU: 4 vCPU
Hard Disk: 60Gb
Backup iSCSI Storage Repository: 500Gb 1st Network Interface: Management control
2nd Network Interface: iSCSI Storage
Backup Source: VMware vCenter v6.0
First, we just download a Trial version from Nakivo site: HERE
Then just run the .exe file and start the installation.
- Step 1 – Type of Installation
In this initial step, we will select the type of installation. If it is a Full installation, or just a Transporter (we will talk more about Nakivo Transporters in the next articles) or a Multi- Tenant Solution.
- Install Type: For this test we will install a Full Solution.
- Create repository: In this option, we can create/indicate our Backup Repository in the beginning of our implementation. We can deselect and choose later on. In our case, we have already a Windows Disk (LUN Storage added into our VM) E: with 500Gb.
The rest of the options we leave the default (but you can change those options to adapt to your Infrastructure).
After, just click Install button to continue.
Note: If we click “Options” in the initial Install screen, we will have all options visible.
The initial installation of Nakivo Software is finished. Now we will configure the rest of the settings.
- Step 2 – Login
Note: If you are using IE, you can get these warnings/information about browser that you should use (Nakivo recommends Firefox and/or Chrome). The default URL to your new Nakivo Backup & Replication server is: https://127.0.0.1:4443.
In this step you can log in, or change/create user/password. In case if you do not plan to change it at this stage, default user and password is “admin”. We will keep the defaults.
- Step 3 – Add Inventory (Backup Source)
In this step just click “Add New…” to add the inventory Source to Nakivo Backup (vCenter in this case).
Note: Here you can add also a Public Cloud account and then you can Backup/Restore or Replicate to your Public Cloud Infrastructure.
Fill in all your vCenter details and click “Add”.
Nakivo Backup will connect and start to import your VMware Infrastructure.
As we can see in the next image, all of my VMware Infrastructure has been added to our Nakivo Backup Server.
To continue just click “Next”.
- Step 4 – Add Transporter
In the next step, we will add a new Transporter or use the one that was created in the Install of Nakivo Backup.
What is Nakivo Transporter?
The Transporter is an application, which performs all of the data protection and recovery tasks: data read, compression, deduplication, encryption, transfer, write, verification, granular and full VM recovery, and so on.
We can use just one (using Default), or create multiple Nakivo Transporters to have better Backup Performance and distribute load into different Transporters.
Deploying multiple Transporters also enables network acceleration and AES 256 encryption of traffic between a pair. For example, if VMs are backed up over WAN to an offsite location,
the Transporter installed in the source site can compress and encrypt VM data before transferring it over WAN, and the Transporter installed in the Target site can unencrypt the data prior to writing it to the Backup Repository.
- Example of Nakivo Backup & Replication with one Transporter (the default)”
- An example of Nakivo Backup & Replication with more than one Transporter in the configuration:
If you have more than one Transporter, it is important to determine which one should be used to read data from the source host and which one should be used to write data to the target host. By default, NAKIVO Backup & Replication automatically determines which one should be used by measuring the host proximity based on the ping round trip time.
Note: I will write more in detail about Nakivo Transporters in future Nakivo articles.
Continue with the Nakivo Backup Server installation:
In this following step, you just need to click “Got It” and continue with the installation.
As you can see, all the information displayed refers to the Nakivo Backup Server Transporter. We will use this one and will not create a new one at this stage, just click “Next” to continue.
- Step 5 – Add Backup Repository
As shown above, we cred the repository in the initial step and here you can see information about the repository.
If we need to add a new one (or did not create one in the initial step), we just need to click “Add Backup Repository” and configure a new one. Or we can just add an existing one to our Nakivo Backup Infrastructure.
After you click “Add Backup Repository” you can change the settings appropriated to your environment and Storage.
Name: Just give a name for the new repository.
Assigned transporter: As we discussed in Step 3, if we have more than one Transporter we can link it to a specific Repository.
Type: Here you provide the type of Repository that you will add into the Nakivo Backup Infrastructure (in the yellow board you can see all types)
The path to the local folder: Here you just indicate the path to your Repository in your Windows Server (it can be a hard disk drive, or a folder inside a hard disk drive).
Compression and deduplication we will leave default options (enabled).
After this, just click “Create” button and you will have a new Backup Repository added.
After all configurations are finished, we just click “Finish” and Nakivo Backup & Replication Server is installed in the Windows 2012 Server.
This is the main “Dashboard” of Nakivo Backup & Replication Server.
Then we need to create some Backup Jobs and start using our Backup Tool.
Just click “Create” and choose “VMware vSphere backup job”
Note: For other options in this section, we will discuss in other articles.
After select create, we will have 4 steps.
- Step 1 – Choose VMs to backup
In this step, we will choose the VMs we want to add to this Backup job.
After choosing the VM that we will backup, we can set the priority in the last? board by dragging the VMs up/down to set the order/priority. If this job does not have any priority VMs, no need to change anything.
- Step 2 – Choose the Backup Repository
In this step, we will choose to where we will Backup our VMs. If you have only one Backup Repository, no need to change nothing, if you have more than one Repository and want to divide the Backup Jobs by Repository, you can do it in the option “Backup Repository”.
Next also in this step we can define if we want specific VMs go to specific Repository, or even Backup VMs Virtual Hard Disks(VHD) to different Repository(example, backup OS Hard Disks to one Repository and Data Hard Disks to different Repository).
You can also in these options; disable backups for particularly VHD that you think are not needed.
Note: By experience, please beware if you have big Virtual Infrastructure and you choose different VMs, or VHD, to different Backup Repository, it will be more difficult to track and manage your Backups/Restores and backups/restores can have slower performance . So use this options wisely and only if you really need them.
- Step 3 – Choose the schedule
In this step, we will choose the schedule that we want our job to run.
We can set our backup job Daily/Weekly, Monthly/Year or run periodically (every 30 minutes for example. Alternatively set every 2 days, or months).
We can also choose that this job runs after another Backup that we have already in our Backup Infrastructure.
Note: You can also click the “Do not schedule, run on demand”. With this enable, we need always to run the Backup Job manually.
- Step 4 – Choose job Options.
In this step, there are some options that we can choose to improve our backup, or to set for particular purpose. Click “Advance Options” to see all options
We will try to talk about the more important ones.
- Option 1 – App-aware mode
If the App-aware mode option is enabled, VM backup will be performed using VMware Guest OS Quiescing (which in turn relies on Microsoft VSS) to ensure that application data is consistent.
Note: If you choose to enable App-aware mode, click “Settings” then you can choose on which VMs you want this option to be enabled. By default, job will be enabled in all VMs.
- Option 2 – Change TrackingWhat is CBT? Changed Block Tracking (CBT) is a VMware feature that helps to perform incremental backups. Nakivo uses this technology. You can read more about it in VMware KB HERE.
Type of CBT that can be used:
- Use VMware CBT: If this option is selected, NAKIVO Backup & Replication will enable the Changed Block Tracking feature for source VMs. This feature enables the product to quickly identify which data blocks have changed since the last job run, which significantly increases the job speed.
- Use NAKIVO change tracking: If this option is selected, NAKIVO Backup & Replication will perform incremental backups using a proprietary change tracking technology. This feature requires reading the contents of all VM disks to determine which data blocks have changed since the last job run.
- No change tracking (always full): If this option is selected, NAKIVO Backup & Replication will always perform a full VM backup of all source VMs.
- Option 3 – Screenshot Verification
If the Run screenshot verification after each job run option is selected, all VM backups created by the job will be verified as follows: after a backup of a VM is completed, the VM will be recovered from the backup using Flash VM Boot (and will be disconnected from networks), a screenshot of the recovered VM will be made once the VM OS has booted, after which the VM will be discarded. VM screenshots will be included in email notifications (if they’re configured), and in job reports.
Note: In one of our next articles we will focus on this feature. For now, we will leave disable.
Option 4 – Truncation of Microsoft Exchange Transaction Logs
This option is to use when we Backup Microsoft Exchange Server.Microsoft Exchange Server database transaction logs record all changes to an Exchange Server database. Over time, these log files accumulate and can consume all of the available disk space, if not periodically removed.
NAKIVO Backup & Replication provides an option to delete (aka truncate) Microsoft Exchange Server logs on the source VMs after job completion.
NOTE: If enabled in a job, this feature will try to truncate Microsoft Exchange logs on all VMs added to the job using the credentials provided. In other words, if you plan to truncate Microsoft Exchange logs on one or more VMs, you need to create a separate job with the VMs, and make sure that all the VMs can be accessed with the credentials you specify in the job.
The transaction logs are deleted after the job completion, so that the log files are available in the VM backup. Note that the product deletes only those transaction logs which are already committed to (available in) the Microsoft Exchange database.
- Option 5 – Transport Mode
Transport mode is the method that Nakivo Transporter (can be the default, Nakivo Server, or other Transporter that exists in the Backup Infrastructure) uses to Backup the VMs from source.
There are 3 types of Transport:
- Hot Add: NAKIVO Backup & Replication can read data directly from source VM disks, bypassing the network, which can significantly increase the job performance. This is achieved with the help of VMware’s Hot Add technology, which enables attaching source VM disks to a different machine and reading data from the disk. In order for the Hot Add feature to work, the source Transporter (the one that will be reading data from the source VM) should run on a host that has access to the datastore(s) with your source VM’s disks.
NOTE: If hot-add cannot be enabled for at least one disk of a source VM (even if the disk is deselected in the job), then Hot-add will be unavailable for all disks of the VM.
- SAN: If your VMs are located on a Fiber Channel or an iSCSI Storage Area Network (SAN) device, NAKIVO Backup & Replication can use the direct SAN access for data retrieval. Using this storage access mode can significantly increase the speed of backup and replication, while decreasing the load on your production network.
- LAN: Data will be retrieved via LAN
Note: If you don’t have sure which is to use, just leave the default (Automatic Selection).
If the source Transporter is installed on a VM, NAKIVO Backup & Replication will try to use transport modes in the following order: Hot Add > SAN > LAN.
If the source Transporter is installed on a physical machine, NAKIVO Backup & Replication will try to use transport modes in the following order: SAN > Hot Add > LAN.
Option 6 – Transporters
Transporter is responsible for transporting and merging the Backup/Restore data from source to destination.
When we install Nakivo Backup & Replication we will install a default Transporter that is on the same server. We can install more Transporters to reduce the load in the main Transporter(if it is automatic, backup will choose the best Transporter) or even reach a network subnet that is not reachable by the Nakivo Server.
Example: Let’s assume that we have Nakivo Server in a subnet 192.168.1.x VLAN 10, but there are some ESXi hosts (or even a vCenter) that are in a subnet 192.168.10.x VLAN 20 that is not reachable by Nakivo (or even some isolated network that cannot be accessed), we then create a VM, or use an existing one, in that Subnet and that VM will have both subnets and VLANs.
Then Nakivo to backup Virtual Environment will use that Transporter to access that network through the Transporter to read/write from the Source and write/read to the destination (Nakivo Repository). With this design, only Transporter VM can access the Network and Nakivo Server will never access that network directly.
Transporter can be set in the Job for particular ESXi hosts, or to Backup VMs.
Transporter can be set in Backups Jobs, or in Backups Repository.
Automatically determine source transporter: The product will automatically determine which Transporters are the closest to source hosts (the hosts that run selected VMs) and will use those Transporters to retrieve data from source VMs.
Set a source transporter for all VMs: Select this option to manually specify a single Transporter that will be used to retrieve data from source VMs.
Manually set transporters for source hosts: Select this option to manually specify which Transporter should be used to retrieve data from each source host.
Note: The target Transporter for the backup job will always be the Transporter assigned to the Backup Repository.
- Option 7 – Recovery Points
For this last option, we will set the number Recover Points that we need.
The rotation of the Backups can be set by using the Grandfather-Father-Son (GFS) method.
- Keep X last recovery points: Keeps the specified number of last recovery points for each VM in the job.
- Keep one recovery point per day for X days: Keeps one last recovery point per day for the specified number of days.
- Keep one recovery point per week for X weeks: Keeps the last available backup of every week for the specified number of weeks.
- Keep one recovery point per month for X months: Keeps the last available backup of every month for the specified number of months.
- Keep one recovery point per year for X years: Keeps the last available backup of every year for the specified number of years.
Daily: 7 Recovery Points (the 8th will replace the 1st).
Weekly: 5 Recovery Points (the 6th will replace the 1st).
Monthly: 12 Recovery Points (the 13rd will replace the 1st).
How Backups are restored? You can read more about in Nakivo help Center HERE
After all the steps are finish, we can just “Save” and run the job after or when is schedule, or just click “Save & Run” to run the job immediately.
In this case, we just choose to save and go to the Jobs board.
As we can see above, if we want to run the job, we just need to click “Run Job”.
Just an image of my Nakivo VM resources usage while the backup is running. As we can see, the usage is not very high.
Let’s just finish this long article with a fast restore of one of the VMs that we have backup.
In the Dashboard click “Restore”. For example we will only choose a Full VM restore (we will go through the other options in a different article).
The Restore option is in 3 Steps.
- Step 1 – Select VMs to Recover
Next, just select the VMs that you want to Restore (option 1) and then select the Recovery Point (option 2). Then click “Next”.
Note: Since we are using the option “VMs from Backup” we need to select the Tab “Backup Repositories” (where our VMs that we have backup previously are located).
- Step 2 – Specify the location to Recover (destination)
In the next step we will choose where to restore our VMs (ESXi host, Datastore, Virtual Network, etc.).
- Option 1 – Container
In this option, you choose the destination for the VM(s) that we will Restore (in this case we will select ESXi host 192.168.1.2).
- Option 2 – Datastore
Next option is to select the Datastore that we will Restore the VM(s). In this case, we will select “ESXi01-sto-01”.
- Option 3 – Network
Next we will select the network for the VM Virtual Interfaces. We will select the “Nested Network”.
Since this VM have 2 Virtual Interfaces, in the VM section we can choose the network for each interface.
- Step 3 – Recover Job Options
In this step we select our options for our VM restore.
We will try to give some information about the most important ones.
- Option 1 – VM Power on
As the options indicates, here we choose if the VM will be power on after the restore. Select the option that adapts more for your VM and restore.
- Option 2 – MAC addresses
In this option, we choose if we want to generate a new MAC addresses, or just keep the same MAC addresses from the original VM.
Note: This is an important option if we will keep the original VM in the Virtual infrastructure. As we will demonstrate after the restore (we will not generate a new MAC address).
This is an example of a VM that was recovered and we decided not to generate new MAC address while the original VM still exists:
vCenter generate a red Alert regarding a VM MAC Address conflict. If this happen we need to change manually the MAC address (from the recovered VM, or in the original VM).
- Option 3 – Recovered VM names
In this option, we choose if we keep the same name for the VM.
We can just add an “append” to the name, keep the same name, or just change the full name to a new one.
- Option 4 – Recovery Mode
Synthetic mode: Environment dependencies (such as CPU affinity, memory allocation, vApp Info, datastore URL, and so on) will be removed from the recovered VM(s).
VM(s) will be fully functional and will contain all their data.
Production mode: Environment dependencies will be preserved on the recovered VM(s). Make sure the location where the VM(s) will be recovered does not contain the original VM(s), otherwise UUID and MAC address conflicts may occur.
- Option 5 – VM Disks
In this option, we choose if we will keep the same type of Virtual Disks for our Restored VM, or if we will convert the disk(example: from Thick Disk to Thin Disk).
If we want to change/convert our VMs Virtual disks to save Datastore space, this is a good change to do it when the system restore the VM.
Options “Transport Mode” and “Transporters” works in the same way has we have explicated in the Backup Job option.
Options “Network Acceleration” and “Encryption” is only used if we are Backup/Restore through WAN. In future articles we will discuss the usage of WAN for backup/restore or just replication.
Next just click “Finish & Run”, or just “Finish” if you plan to run the recover job after.
And with the Recover option, we finish this initial article about Nakivo Backup & Replication.
Nakivo announcement: NAKIVO v7 Beta with Hyper-V Backup is out. Check Nakivo website to download and participate in their “v7 Beta Promotion”.
Hope this information was useful.
Note: Share this article, if you think it is worth sharing.