corrupted backup

Hi Aldous,

Typically it's not possible to recover from corrupted backups, however in some cases partial recovery is still possible, for example if you open the backup via Windows explorer (double-click on .tib(x) file) or when you try to restore files/folders from it via bootable media vs via usual web console interface.

The general recommendation to protect from corruptions is to maintain at least 1 copy of the backup archive regularly ("2nd location" option in backup plan). The best approach is to have 1 local copy + 1 copy sent to cloud.

Thank you.

it's very unfortunate. I guess that is the risk of having all backup in single file. Just wondering if Acronis has any plan on making "corrupted backup" repair/recovery? 

Hi,

The corruption error during backup does not necessarily mean that all backups inside the archive are unrecoverable - it first of all means that it's not possible to continue updating this archive incrementally. The older recovery points may still be valid. The exact behavior highly depends on type of corruption and where it occurred inside the archive.

In fact the current archive format (.tibx) was specifically designed to make it more reliable and corruption-prone than the legacy archive format (.tib). So far we saw only one scenario where .tibx archives got corrupted: when the backup was saved to specific NAS device (specific vendor+model+firmware version) which reported success on write I/O request, while in reality the write request was not completed and thus caused the archive corruption.

Can you please clarify which archive format you are using? If it's .tibx then what is the type of backup storage (some NAS device?)?

Thank you.

У нас также постоянно вылетает архив Tibx. План выпадает в ошибку ввода / вывода. Пересоздаем план с новым tibx и архивы делаются. Через 4-20 дней ситуация повторяется. Архивы не более 5 ТБ. В течение 2 месяцев. Файл имеет название _.tibx. В параметрах копии указано деление архива. 

Хранилище расположено на HP MSA 2040 в связке с FB 16 Гбит / с.

Александр,

Данную проблему стоит исследовать с помощью нашей команды поддержки. Потребуется системный отчет (https://kb.acronis.com/content/58301) с машины, которая выполняла резервное копирование, которое завершилось с ошибкой. Возможно, влияет факт деления архива (опция Archive split), но это только предположение.

Спасибо.

Vasily Semyonov wrote:

Hi,

The corruption error during backup does not necessarily mean that all backups inside the archive are unrecoverable - it first of all means that it's not possible to continue updating this archive incrementally. The older recovery points may still be valid. The exact behavior highly depends on type of corruption and where it occurred inside the archive.

In fact the current archive format (.tibx) was specifically designed to make it more reliable and corruption-prone than the legacy archive format (.tib). So far we saw only one scenario where .tibx archives got corrupted: when the backup was saved to specific NAS device (specific vendor+model+firmware version) which reported success on write I/O request, while in reality the write request was not completed and thus caused the archive corruption.

Can you please clarify which archive format you are using? If it's .tibx then what is the type of backup storage (some NAS device?)?

Thank you.

Sorry for the late respond. we are using .tibx and it's backup to Qnap (NAS TS-EC1679U-RP). 

Hi,

From what I've checked we've seen this issue reported by customers who also use QNAP NAS devices (internal issue ID: ABR-146546). It's likely that multiple models/firmware versions are affected as well where NAS device reports success to write request, which in fact does not complete properly and instead there is garbage added to the end of the modified file (which is archive in our case). To proceed with further investigation you should contact our support team with reference to this thread (to internal issue ID: ABR-146546). The next steps would require your assistance in order to help us with debugging of the write commits operations -> get the proofs of the behavior and then we'll be able to report this issue to original device vendor.

The workaround is to avoid using new archive format when saving backups to QNAP NAS devices and use backup format v11. The root cause is in combination of improper NAS behavior + more strict dependencies between different recovery points within archive format v12 in comparison with format v11.

Thank you.