backup slow in EC2 and Physical machine

[Leslie Lei]

We just tested AWS EC2 and found the job runs slow.  The support wasn't able to provide the answer.  When backing up EC2 instant, the Nakivo director creates a target machine snapshot and  Hotadd the snapshot to the transporter.   The transporter reads the data in the snapshot.  Because the transporter is a Linux machine and the target server is a Windows server, we can't tell if this is the trouble with the Linux machine reading the Widows NTFS volume.   We changed the setup to the Physical machine backup method instead.   Basically, we just treat the EC2 server as a physical server and deploy the Nakivo agent on it.  Let the agent on the target server collect data from the volume and send it to the Transporter.  That eliminates the possible NTFS volume and Linux system issues.  The target server and the transporter are also in the same network subnet in AWS to eliminate possible network issues.  However, the backup process is still slow.  The slowness is not caused by the performance of the target machine, transporter or network.  If I watch the backup process (incremental backup), I can see the job starts with 100Mb/s - 300Mb/s at the beginning 10 minutes of the job.  After that, the speed will drop to 0.01Mb/s or even 0.0.Kb/s for almost an hour.  It will resume the speed to 100-300Mb/s in the last 10 minutes.  This backup process makes the backup duration much longer than it should.  This issue happens in both AWS EC2 backup and the physical server backup.  the VMware backup works fine.  For the same-size of server, it only takes about 3 minutes to complete the incremental job for the ESXi VM.  I think there is a software bug in the Nakivo software that the change block tracking doesn't work or doesn't work efficiently in the EC2 instant or physical backup job.  The job should quickly skip any data blocks with no changes.  In the current backup process, I can tell the job is still walking the data block with no changes.  It doesn't know which block has no changes or it doesn't know how to skip them. That's why it wastes most of the time to walk through the data with no changes.

[The Official Moderator]

13 hours ago, Leslie Lei said:

We just tested AWS EC2 and found the job runs slow.  The support wasn't able to provide the answer.  When backing up EC2 instant, the Nakivo director creates a target machine snapshot and  Hotadd the snapshot to the transporter.   The transporter reads the data in the snapshot.  Because the transporter is a Linux machine and the target server is a Windows server, we can't tell if this is the trouble with the Linux machine reading the Widows NTFS volume.   We changed the setup to the Physical machine backup method instead.   Basically, we just treat the EC2 server as a physical server and deploy the Nakivo agent on it.  Let the agent on the target server collect data from the volume and send it to the Transporter.  That eliminates the possible NTFS volume and Linux system issues.  The target server and the transporter are also in the same network subnet in AWS to eliminate possible network issues.  However, the backup process is still slow.  The slowness is not caused by the performance of the target machine, transporter or network.  If I watch the backup process (incremental backup), I can see the job starts with 100Mb/s - 300Mb/s at the beginning 10 minutes of the job.  After that, the speed will drop to 0.01Mb/s or even 0.0.Kb/s for almost an hour.  It will resume the speed to 100-300Mb/s in the last 10 minutes.  This backup process makes the backup duration much longer than it should.  This issue happens in both AWS EC2 backup and the physical server backup.  the VMware backup works fine.  For the same-size of server, it only takes about 3 minutes to complete the incremental job for the ESXi VM.  I think there is a software bug in the Nakivo software that the change block tracking doesn't work or doesn't work efficiently in the EC2 instant or physical backup job.  The job should quickly skip any data blocks with no changes.  In the current backup process, I can tell the job is still walking the data block with no changes.  It doesn't know which block has no changes or it doesn't know how to skip them. That's why it wastes most of the time to walk through the data with no changes.

Hello, @Leslie Lei I've forwarded your message to our Level 2 Support Team.

 

Can you please provide me with the original ticket number associated with your support request? This will help us track the progress of your case and understand if the ticket is still open or has been closed without resolution. Thank you for your feedback!

[Leslie Lei]

The ticket is #225141.

[The Official Moderator]

1 hour ago, Leslie Lei said:

The ticket is #225141.

@Leslie Lei, currently the solution workflow for EC2 instances and physical machines is similar with proprietary change tracking. NAKIVO Backup & Replication reads the whole disk(s) and compares them with existing backup data to identify changes. In some cases, a backup can take longer and there may zero data transfer during a job run when data is being checked but not written.

The difference in transfer rate for VMware vSphere and Hyper-V VMs has to do with NAKIVO Backup & Replication leveraging native change tracking technologies for backup jobs. These technologies allow for faster job runs. Our Dev Team is working on enhancing change tracking for physical machines to increase the speed of physical machine backup. However, we cannot provide an exact ETA at this time. Thank you again for sharing your feedback. Let us know if you have any other questions.