Frequently asked questions

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.

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.

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?)?

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).

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.