Nakivo v.7 beta and EC2 replication

Staring with a news

During the writing, an important news is coming out: Nakivo v.7 beta is out! This is a great opportunity for lab man to try new features that are included in this new release:

  • Window Server 2016 protection (hypervisor and objects)
  • vSphere 6.5 supports

Just check here:

Tried for you: AWS EC2 replication


As a side note, this lab was important for me, because it started my journey in AWS. After no more than 2 hours I was able to do main tasks without reading the documentation. The test started easy because Nakivo is really fully integrated with this platform: just a single click (plus confirm) to deliver the director and few steps to protect EC2 workload. After half an hour I successfully protected my first workload… mistakes included.

Before continue with the test it’s important to know a little about Nakivo architecture:

  • Director: the orchestrator instance that collect all information about infrastructures, repositories, jobs,..
  • Transporter: an instance delivered by Director, that brings data from infrastructure (EC2, esxi, hyperv,… ) to the backup repository.
  • Backup repository: could be NAS, NFS,… or a local folder. This is mounted directly by assigned Transporter.

From Amazon EC2 perspective Nakivo instance is an appliance composed by all of these components ready to be delivered in all regions (with the exception of that where it was installed). In this test I delivered an EC2 instance in Ireland Region and Nakivo instance in London Region.

 The test

Test case design:


  • Create a user credential with Amazon IAM. I suggest to a temporary full EC2 access to this user, because during Transport delivery it must be able to instantiate another EC2 out of Director region.
  • After deployment simply modify the permission like reported in this document:
  • The AWS region you should protect must not be the same where Director instance is installed.


  • Simply go in AWS Marketplace and search Nakivo
  • After deployment (when instance is ready) login via ip public (username: admin pwd: aws instance id)
  • Assign AWS user and scan deployed instance to bring under protection.
  • Time deliver Transporter in that zone with a note: AWS is billing when you generate traffic from a region to another!
  • Create a Backup Repository (or better deliver one)

With no configured repository you can only use replication job; and this is my test result:


Follow up

The simplicity how I configured this job, starting with no knowledge about sizing, architecture, etc… is what a simple user needs to start working in cloud with safety insight. In addiction there are some feature that must be mentioned:

  • there is a recovery points retention, useful to keep replication changes
  • there is an modality for executing replica application aware,
  • it is possible to choose RPO simply doing a scheduling task. After the first seeding (1m and 35 sec) every replication tasks runs in less than a minute. Obviously time depends on disk capacity and data movements. All cases I suggest to run no less than 15min in a production environment.
  • Recover from replication is performed simply choosing instance and its replication time

Next time I’ll try something different in a complex environment. Stay tuned!

   Send article as PDF