Skip to main content

Selecting an Intermediate Point To Recover From An Incremental Backup

Thread solved
Forum Member
Posts: 13
Comments: 26

I have a full backup (s.1) and three incremental backups (s.2; s.3 and s.4). I want to recover from a version including s.1, s.2 and s.3 but not s.4.  When I boot into windows from my ATI 2019 recovery media I am prompted to browse for a backup. Should I select s.1 first and restore that. Then select s.2 and restore that. And then s.3 and restore that. If I do that will I have a restored drive up to the date s.3 was made but not including the changes made between s.3 and s.4?

Thanks in advance for any help.    

 

0 Users found this helpful
Legend
Posts: 109
Comments: 28221

Ronald, the way recovery works is that you simply select the latest version that you want to recover from and Acronis then handles all earlier versions within the backup version chain.

In your specific case, select to recover from s3 if you don't want to include the changes in s4.

Forum Member
Posts: 13
Comments: 26

Hi,  Steve,

Thanks for your prompt response.

Does validation work the reverse of recovery?

In other words if I right click on any tib file in a folder with a base and incremental backups  and choose the validate option it appears that ATI validates the entire chain no matter which incremental backup I choose. Is that how validation works?

In my original backup location on an external HD 23.  I have s.1 (base) and incremental backups s.2, s.3, s.4 and s.5.  About three weeks ago I used Windows 10 to copy s.1, and s.2 ato a folder on  HD 22..About a week later I also copied S.3 to the same folder on HD 22.   When I validate from s.5 or s.1 on HD 23 (the original backup chain) I get the attached error message indicating a problem accessing s.3. When I attempt to validate s.1 on HD 22 (the copy) I get the same error message.  After I dismiss the error message I get a popup saying the validation was successful.

When I boot into ATI from a rescue disk and attempt to validate S.1 on HD 23 I get the same error message in the rescue media recovery environment. However, when I navigate to S.1 on HD 22  the validation is successful with no error message.      

My goal is to recover from S1 on HD 22 to about three weeks ago and if that is successful attempt recovery to S.2 and if that works perhaps S.3.  Is there anything further you would suggest I check before attempting recovery to S.1? 

Also, what does the error message mean? I tried to search the error code in the Acronis Data base, but there was no article and only general trouble shooting advice.

Thanks for your answer above. Please let me know if you shed any further light on how validation works.

Best regards,

Ron McGuire 

 

   

Attachment Size
607558-342693.jpg 77.72 KB
Legend
Posts: 109
Comments: 28221

Ron, validation is a whole different kettle of fish than recovery!

When doing validation from within Windows then Acronis also has access to the internal database assuming that the task that created the files being validated is still shown in the main ATI GUI.  The database records the original location for files created!

If you have copied or moved files then this can lead to some strange issues when validating from those different locations.

When validating from rescue media, then there should be less of an issue with looking at backup files stored in different locations provided that all the files created are stored together (as the database is not involved).

Validation is not a guarantee that a backup will result in a successful recovery and bootable system! 

What validation does do is to confirm that the backup file that was created by the backup operation has not been changed after it was written to the storage drive / location.  It does this by reading the backup TIB / TIBX file and calculating checksum values for each block of the file then comparing those checksums with values embedded within the file.  It the checksums match, then the file has not been changed since written.

What validation cannot do is to change whether any malware, virus or corruption was present in the source data for the backup operation when it was performed.  This can also include file system issues present when a backup was created but not detected or known about.