Backup to Synology NAS receives more data than it transmits

Quote:

I note that in older versions of Acronis, the Incremental backups were separate tib files, but with ACPHO there is a single tibx file for each version chain

Older versions of the application used a single file and were written to a container which used a .tib extension.

ACPHO uses a different method in which all backed up data is written to a single container which uses a .tibx extension.

In the latter all full and incremental versions of the backup are held in this single container.  Each backup created in the backup chain is then compared with all other backups currently in the chain container to determine what data has changed which is then written to a new file.  The larger the chain becomes the slower this process thus the longer it takes.

The time can also be increased if validation is selected when speficying the task, particularly if complete verification is chosen. 

Enchantech wrote:

 

Older versions of the application used a single file and were written to a container which used a .tib extension.

ACPHO uses a different method in which all backed up data is written to a single container which uses a .tibx extension.

In the latter all full and incremental versions of the backup are held in this single container.  Each backup created in the backup chain is then compared with all other backups currently in the chain container to determine what data has changed which is then written to a new file.  The larger the chain becomes the slower this process thus the longer it takes.

This new "Containerised" methodology really slows down the process, in particular to a NAS. My Full backups (~350GB) used to take a couple of hours, and the incrementals only a few minutes, now a full can take up to 14 hours, and the incrementals about 4 hours.

I will see if I can shift back to the older format separate *.tib files.

EDIT: Unfortunately ACPHO does not have an option to use the older *tib file format to ensure discrete incremental files. So it seems the ACPHO must scan the whole 350GB *.tibx file before it start to write to a new *.tibx file, or update a component in the *tibx collection file.

So, I think there is no real solution here for me to speed up the backup performance.

Hello TonkleChicken.

The reason for the reverse direction data transfer is likely due to the incremental backup process.

In your case, since you have a full backup followed by three incremental backups, the software needs to compare the changes between the full backup and each incremental backup to ensure that it has captured all the changes. This process can lead to a significant amount of reverse direction data transfer.

One possible solution to reduce the reverse direction data transfer is to use a differential backup scheme instead of an incremental backup scheme. This could potentially reduce the amount of data transferred in the reverse direction.

Finally, you can also consider upgrading your network infrastructure to improve the backup speed, such as upgrading to a faster LAN.

Feel free to reply here or to contact our support https://kb.acronis.com/content/8153

Hope this helps!

Jose Pedro Magalhaes wrote:

Finally, you can also consider upgrading your network infrastructure to improve the backup speed, such as upgrading to a faster LAN.

Thanks Jose for the response, but moving my LAN to 10GbE is not a practical solution for me.

My property is cabled in CAT5e, and many of my devices, including this device being backed up would probably not be capable of utilising more than the current GbE supports. Whist my Surface Pro USB-C could possibly support a 2.5,5 or 10GbE dongle, the device itself may struggle.

Additionally my NAS peaks out at about 700Mb/s for sequential reads, so moving to one that could support ~5Mb/s would be prohibitively expensive. (This is a residential system, not for a business)

It seems to me that the new tibx file/container format does not contain an index/directory file that can be easyly independently retrieved, so it seems that the Acronis client is walking the whole file for each backup to determine the changes it needs to backup. This is not an efficient mechanism.

TonkleChicken wrote:

Jose Pedro Magalhaes wrote:

Finally, you can also consider upgrading your network infrastructure to improve the backup speed, such as upgrading to a faster LAN.

Thanks Jose for the response, but moving my LAN to 10GbE is not a practical solution for me.

My property is cabled in CAT5e, and many of my devices, including this device being backed up would probably not be capable of utilising more than the current GbE supports. Whist my Surface Pro USB-C could possibly support a 2.5,5 or 10GbE dongle, the device itself may struggle.

Additionally my NAS peaks out at about 700Mb/s for sequential reads, so moving to one that could support ~5Mb/s would be prohibitively expensive. (This is a residential system, not for a business)

It seems to me that the new tibx file/container format does not contain an index/directory file that can be easyly independently retrieved, so it seems that the Acronis client is walking the whole file for each backup to determine the changes it needs to backup. This is not an efficient mechanism.

Hello Tonkle.

We appreciate and value your feedback.

We will take in consideration your comments and hopefully improve the product on the next builds.

Thank you in advance.