corrupted backup

one of my backup failed this morning with "the file is corrupted" error. I tried to run backup validation on the backup and got "failed to validate some of the device backups. They may be corrupted". Is it possible to repair or recover the corrupted backup? VM in this backup is very large and need two days to finish a full backup in case I have to re-create the full.
Regards,
Aldous

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?
- Anmelden, um Kommentare verfassen zu können

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.
- Anmelden, um Kommentare verfassen zu können
Best regards,
Vasily
Acronis Virtualization Program Manager
Information provided AS-IS with no warranty of any kind.
To contact support, please follow http://www.acronis.com/en-us/support/

У нас также постоянно вылетает архив Tibx. План выпадает в ошибку ввода / вывода. Пересоздаем план с новым tibx и архивы делаются. Через 4-20 дней ситуация повторяется. Архивы не более 5 ТБ. В течение 2 месяцев. Файл имеет название _.tibx. В параметрах копии указано деление архива.
Хранилище расположено на HP MSA 2040 в связке с FB 16 Гбит / с.
- Anmelden, um Kommentare verfassen zu können

Александр,
Данную проблему стоит исследовать с помощью нашей команды поддержки. Потребуется системный отчет (https://kb.acronis.com/content/58301) с машины, которая выполняла резервное копирование, которое завершилось с ошибкой. Возможно, влияет факт деления архива (опция Archive split), но это только предположение.
Спасибо.
- Anmelden, um Kommentare verfassen zu können
Best regards,
Vasily
Acronis Virtualization Program Manager
Information provided AS-IS with no warranty of any kind.
To contact support, please follow http://www.acronis.com/en-us/support/

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).
- Anmelden, um Kommentare verfassen zu können

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.
- Anmelden, um Kommentare verfassen zu können
Best regards,
Vasily
Acronis Virtualization Program Manager
Information provided AS-IS with no warranty of any kind.
To contact support, please follow http://www.acronis.com/en-us/support/
Best regards,
Vasily
Acronis Virtualization Program Manager
Information provided AS-IS with no warranty of any kind.
To contact support, please follow http://www.acronis.com/en-us/support/