Aller au contenu principal

Recover backup created with older version od True Image

Thread needs solution

Hi I use Acronis to back up my Mailserver - 10 days ago we had a problem and the Mailserver (a VM on a Hyper-V Host) bombed out.  I have been doing incremental backups but this time file 17 out of 30 is corrupted.  So I can't get an up-to-date image (just to May 15th).  I read that sometimes using a more recent Acronis can resolve the issue.  I am trying to set up a recovery on Acronis 2018 but without a clean set "17" the process just stops.  Are there tools to repair an individual TIB file?  Any ideas anyone please?  Jean

0 Users found this helpful

Jean, I am not aware of any ability in later versions of ATI to resolve issues caused by corrupt incremental backup image files.

Also, if your ATI versions are as indicated in your Products information, then these are very old products and not mentioned in the information provided by Acronis for backwards compatibility of backup image files.

See KB 1689: Backup archive compatibility across different product versions for the official position.

Hi Steve - Thanks for your post.  Yes they are very old products but have been rock solid and altho I am the IT resource I am not that qualified (we are only 4 or 5 people) - I just have a little more practical experience.  I was successful thanks to Acronis in virtualising our three ancient physical machines (AD File Server and MailServer) so I am very partial to Acronis which we've used since 2002.  The VMs have been running for 3 years without major incident.  

2 weeks ago however we had an "RPC server not available" incident and in the process of trying to figure it out the Mailserver bombed out.  I have now got it back but unhappily one set of the incremental backups must have been laid down on a bad sector.  So I have only been able to recover to the 15th May - if for example I move the faulty set out of the folder and then rename the subsequent sets to keep the numbering sequential would that trick the system?  I realise it isn't orthodox but... :)  Incidentally I now know not to allow incremental sets to grow too much!

I now have much more modern versions including 2018 (whose interface isn't as easy to understand as the earlier versions but I guess I will figure it out).  Jean

Jean wrote: "So I have only been able to recover to the 15th May - if for example I move the faulty set out of the folder and then rename the subsequent sets to keep the numbering sequential would that trick the system? "

Unfortunately, your approach would never work due to the way that Incremental backups work.  Each new Incremental backup is based on the previous file in the version chain and stores only the changes that have been captured since that last file was created. 

So if your file 17 (of 30) is corrupt, your Incremental version chain ends at file 16 and all remaining files (18 to 30) are no longer valid for recovery due to the corrupt file 17.  Renaming these files to be 17 to 29 would not make a valid chain because file 18 was based on corrupt file 17, not on file 16.

Perhaps another option to reducing the number of Incremental files in your version chains would be to add another backup schedule to a different backup location.

If you have been doing a daily backups to your current backup drive, then consider doing a second weekly backup to a different drive, so that if you encounter a similar issue in the future you would have a choice of 2 backups to recover from, and would lose less valuable data.