Official Moderator

"Self-healing" and "Verification" guarantee that all backup data in the repository is in the same consistent state as during backup - NAKIVO compares checksums of blocks that were counted during the backup with actual repository data. In this case File level recovery should work fine. The only possible issue in this case - bootability of VM in case there are some issues with boot sector, for example. It could be also in case OS updates were installed during the backup. In this case we would recommend to use automated Screenshot verification (or Boot verification) feature or manually run F

In this case we would recommend you the following NAKIVO layout: 1. Deploy NAKIVO transporter on both ESXI hosts to be able to use HotAdd datatransfer mode. 2. Install NAKIVO transporter on NFS storage, in case it is supported. In this case both involved transporters will perform direct read and write operations on the source and target sides correspondingly and also have direct connection between each other. For detailed analysis, please send a support bundle (http://www.nakivo.com/helpcenter/display/NH/Support+Bundles) and the following information to support@nakivo.com : - in w

Hello! In this case, we suggest you check the following article on Physical machine requirements - https://helpcenter.nakivo.com/display/NH/Supported+Platforms#SupportedPlatforms-PhysicalMachineRequirements If nothing helps, please send us a support bundle (https://helpcenter.nakivo.com/display/NH/Support+Bundles) for further investigation.

We’re happy to announce the release of NAKIVO Backup & Replication v10.1! The NAKIVO team has added two long-anticipated features, OneDrive for Business Backup and HPE StoreOnce Catalyst Integration. Download the Free Trial and see the new functionality in action! https://www.nakivo.com/resources/releases/v10.1/

Based on the described error, we could recommend to check if 9445 and 9446 ports are opened on the affected Linux machine - NAKIVO tries to connect to agent on the first step and then to installed transporter service on these ports. Also please check and make sure that all requirements for Linux physical machine are met - https://helpcenter.nakivo.com/display/NH/Supported+Platforms#SupportedPlatforms-PhysicalMachineRequirements In case it still fails, please generate a support bundle http://www.nakivo.com/helpcenter/display/NH/Support+Bundles and send it to support@nakivo.com for further i

Please generate and send a support bundle https://helpcenter.nakivo.com/display/NH/Support+Bundles to support@nakivo.com with the description you put in the comment, so we can create a Feature request and send it to our Product Development team for possible further implementation.

With current NAKIVO workflow, the director needs access to all ESXi hosts and transporters for correct management. In case the transporter will be deployed on the customer side, then, yes, all the data will be transferred inside the customer site (without using WAN) ,but the director still will need access to the ESXi host and transporter. Generally, it is possible to do this in two ways: - configure port forwarding at customer's firewall; - configure VPN to customer's site to have full network access.

Hello! Could you please clarify if you get any error in this case? Please specify the names of affected VMs and send us a new support bundle so that we could check this case further.

Hello! It looks like the FUSE driver was used to mount the folder locally. Out of our experience, it should run with poor speed because that driver works in the user space.

For now it is not possible to perform P2P restore. It is possible to restore separate files/folders with File level recovery feature. We believe it is possible to clone physical machine data from the exported by NAKIVO virtual disk to physical machine HDD with some third-party software.

It is possible to enable "Self-healing" and "Verification" for the repository on some schedule. Please check the following link for more details - https://helpcenter.nakivo.com/display/NH/Local+Backup+Repository#LocalBackupRepository-CreateBackupRepository:Options "Run repository self-healing on schedule" and "Run full data verification on schedule" sections.

Please let us know if you ran recovery in the "production" or "synthetic" recovery mode. In the "production" mode and all uuids from original VM are used for restored one, that could cause the described situation.

Hello Giorgio, Thank you for contacting NAKIVO support. We sincerely apologize that you faced some issues in the scope of the opened ticket. Could you, please specify a ticket ID? We would like to analyze it in more detail to avoid any misunderstandings in further support from our side and provide you more explanations for your statements. We glad to hear your issue was fixed. You can contact us any time via chat, email (support@nakivo.com), or just send us a support bundle by the following link: http://www.nakivo.com/helpcenter/display/NH/Support+Bundles Thank y

Hello, @vss, have a look: https://helpcenter.nakivo.com/display/NH/Updating+on+Linux Please, let us know if any help needed.

Hello! Please note that it's not possible to install physical transporter on the same physical server where Onboard transporter has been already installed, because these transporters are different by design and can't be replaced by each other. As a workaround, you can move NAKIVO Full installation with Repository to another physical server, VM, or NAS box and add this physical server to Inventory without any difficulties.