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?
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.
This issue also impacts customers using multiple models of Buffalo NAS, across multiple hypervisors.
Acronis needs to address this with a compatibility Patch. Acronis 12.5 & 15.0. as everything we have done with Buffalo to hunt down the issue has turned up clean.
The Auto corruption fix was enabled, and Acronis had told us to turn off all validation as that might cause this error to happen more often.
Piling all of your backups in to one tibx so that you need to start you backup library from scratch to "fix" it is a design flaw in my opinion. Having to take a backup of your backup as a recommended measure is also a very poor solution.
Hello IST Admin,
thank you for taking the time to share your experience with the community! I'll forward your feedback to the product management for review, thank you!
IST Admin wrote:This issue also impacts customers using multiple models of Buffalo NAS, across multiple hypervisors.
Acronis needs to address this with a compatibility Patch. Acronis 12.5 & 15.0. as everything we have done with Buffalo to hunt down the issue has turned up clean.
The Auto corruption fix was enabled, and Acronis had told us to turn off all validation as that might cause this error to happen more often.
Piling all of your backups in to one tibx so that you need to start you backup library from scratch to "fix" it is a design flaw in my opinion. Having to take a backup of your backup as a recommended measure is also a very poor solution.
I sent you a private message. It sounds like we may have the same woes, and Acronis is taking very little ownership or assistance of the issue. I'd love to compare notes.
Buffalo support was able to reproduce this Acronis flagged CRC corruption issue on SMB backups in SCALE, VMware, and Hyper-V.
Buffalo has collected and analyzed logs from our NAS and found nothing, the NAS Intranet page reports no abnormalities or issues, and things are clean in the NAS's automated email reports.
We are currently trying to use an ISCSI volume as a target and things have been good for a week so far. Pending a restore test, but Acronis and the NAS no longer report how full they are. (in the NAS intranet page, on the VM hosting the ISCSI share, via Acronis automated email, or Buffalo's NAS Navigator software.