Salta al contenuto principale

Unable to recover disk

Thread needs solution

I am completely baffled by the the new user interface on true image 2016.

I have used true image home 11 for some time with no problems. The user interface was much more intuitive.

Today I attempted to use TI 2016 for the first time to recover a disk

I get the terse and uninformative error: 'Cannot Find Version 1'.

What does this error message actually mean? 'Version 1' of what?

If I then click 'Cancel' It tells me 'Failed to open item I:\SAMSUNG MHHPV256HDGL-00000_full_b1_s1_v1.tib'.

On the backup drive itself there are 2 files:-

The first full backup: 256GB SSD_full_b1_s1_v1.tib

and an incremental backup based on the first: 256GB SSD_full_b1_s1_v1-2.tib

It's not clear from the error message whether I should browse to the first full backup or the incremental backup file to restore the drive.

As for why it can't find the files, first of all the backup drive is no longer designated  I: It changed to L: after I mounted an iso image the other day.

Secondly, it's looking for the wrong file prefix for the backup file names:-

When I first added the source/destination pair before carrying out the backup, I renamed it from SAMSUNG MHHPV256HDGL-00000 (chosen by TI) to something shorter and more meaningful to me i.e. '256GB SSD'. When the backup was carried out, TI used this name string as a file prefix. Why then, is it trying to find a file with the original name 'SAMSUNG MHHPV256HDGL-00000' when I try to restore?

 

 

0 Users found this helpful

Having thought about this further, it seems to me that the way the backup file and source/destination pair naming works in TI 2016 is completely illogical:-

If you look at the way Microsoft's SyncToy works, the name given to the source/destination pairs can be anything you like. It doesn't include any reference to the drive letter (e.g. C:) etc. It doesn't make sense to include the drive letter since it can change. Also the name given to the source/destination pair should not be used to as a prefix for backup file names. The prefix should be derived from the source disk name.

 

Did you modify the backup task after it ran or manually move backup files in Windows by chance?  The acornis database expects files to be exactly as they were named and where they were created and should not be manually moved or updated outside of Acronis. In this case, it looks like it was originally created on a disk that was mounted as I, but perhaps the drive letter has changed or the drive is not connected, or there is a different drive being used as I: now?  The backup names themselves, do not have drive letters in them - just the name you create for the backup task, followed by the type of backup (full, inc, or diff) and the version of the backup.

At some point, it looks like there may have been an issue as the -2 at the end of 256GB SSD_full_b1_s1_v1-2.tib suggests it failed with the first creation of that file or that file name already existed so it appended -2 to make it unique.  

To simplify things for testing, I would create a new backup job and run a new backup.  Use a unique name and put the backup in it's own folder (not mixed with other backups directly).  Once done, then attempt a recovery and see if the error still exists or not - I believe it will work fine.  After that, be sure to not modify the backup tasks or manually name or move backup files.  Also make sure that your backup destination drive and letter remain the same as Windows often assigns a differnent drive letter automatically if that letter is already in use by another drive.  You also can't swap one drive with another, even if using the same letter, because Acronis reads the hardware ID and detects it is not the same disk as the backup was originally created with.

Sorry, there is something I missed...

There is a third file on the backup disk.

The three files are as follows (I've included dates this time to clarify the sequence)

07/06/2016  13:54    27,606,512,128 256GB SSD_full_b1_s1_v1.tib
12/06/2016  22:09    27,495,379,968 256GB SSD_full_b1_s1_v1-2.tib
20/06/2016  17:08     4,543,868,416 256GB SSD_inc_b1_s2_v1.tib

So the first full backup carried out on 07/06/2016 was 256GB SSD_full_b1_s1_v1.tib.

When this was done, the source/destination pair name was the default assigned by TI i.e. SAMSUNG MHHPV256HDGL-00000

I then renamed the source/destination pair that appears on the TI user interface from 'SAMSUNG MHHPV256HDGL-00000' to '256GB SSD''. I also renamed the tib file on the backup disk from 'SAMSUNG MHHPV256HDGL-00000 _full_b1_s1_v1.tib' to '256GB SSD_full_b1_s1_v1.tib'

The next attempt at an incremental backup did not work correctly as TI was expecting an existing full backup file named 'SAMSUNG MHHPV256HDGL-00000_full_b1_s1_v1.tib'. Hence it created another full backup named 256GB SSD_full_b1_s1_v1-2.tib. At the time I wasn't too concerned about this - I just assumed the next incremental backup would use this second full backup as it's starting point.

The next incremental backup, carried out on 20/06/2016, is SSD_inc_b1_s2_v1.tib

Now I have no idea if this incremental backup is actually based on 256GB SSD_full_b1_s1_v1.tib  or 256GB SSD_full_b1_s1_v1-2.tib.

I would hope that it's based on  256GB SSD_full_b1_s1_v1-2.tib so that if I restore 256GB SSD_inc_b1_s2_v1.tib then I will get my files back to as they were on 20/06/2016.

Most likely these two are the ones that are linked together

12/06/2016  22:09    27,495,379,968 256GB SSD_full_b1_s1_v1-2.tib
20/06/2016  17:08     4,543,868,416 256GB SSD_inc_b1_s2_v1.tib

However, when you rename backup tasks (especially outside of Acronis), it can cause things to get out of whack.  If navigate with Windows file explorer to SSD_inc_b1_s2_v1.tib and double click on it, does it open up or ask you to locate version 1 that way?  if so, and you then point it to 256GB SSD_full_b1_s1_v1-2.tib, does it open up after that?

If not, I would scrap this backup schedule and start a new one and be sure not to rename the task (especially not outside of Acronis) and hopefully things will be OK after that.