Skip to main content

Incomplete backups and off site storage

Thread needs solution

I'd like to understand how this is supposed to work.

I want to take backups off site but not all, for example a full backup plus the last three differentials. When I try to do a test restore I get multiple "Cannot Find n", generally I have to cancel about 8 times for each one. Then it goes away for maybe an hour, I get tired of waiting so maybe less. The process gets repeated once and then I can do the restore. The restore crashes on Windows (crashes widows itself) and on Windows PE environment and works only on the Linux recovery.

I have tried with different backups from different machines going to different locations - same problem. I have also tried "validating" the backups with the full and differentials which seems to do something but doesn't change the restore issue which still crashes and requires multiple "Cannot find n".

Surely this is a standard use for backup software. Am I missing a step or something?

Thanks in advance

 

Richard

0 Users found this helpful

I want to take backups off site but not all, for example a full backup plus the last three differentials. When I try to do a test restore I get multiple "Cannot Find n", generally I have to cancel about 8 times for each one. Then it goes away for maybe an hour, I get tired of waiting so maybe less. The process gets repeated once and then I can do the restore. The restore crashes on Windows (crashes widows itself) and on Windows PE environment and works only on the Linux recovery.

Richard, any 'Cannot find version N' messages are generated because information in the Acronis Database is being referenced, which in turn means that the restore is being done from within Windows, as the database is not used when using the bootable Acronis Rescue Media.  This is assuming that all your backups are using Differential schemes.  Any missing file for Incremental schemes will render the backup version chain broken at that point!

If you move any backup files (whether offsite or to another folder etc) then you need to perform a Validation for the task that created those moved backup files, then take the Ignore option when given a pop-up error message.

When doing any restore of the OS drive / partition from Windows - ATI will require that a system restart is performed to complete the action.  This in turn will cause the Windows BCD (boot configuration) files to be modified to boot from a temporary boot environment which may not always have all the needed device driver support for your computer drives or drive configuration.  I would recommend using Acronis Rescue Media for such restore actions, testing first that the boot media is used in the same BIOS mode as used by Windows itself, and that all drives can be seen to allow the actions to be performed.

If you need further assistance, please confirm the version / build of ATI you are using, and how you are moving files, where to, copies of the logs for the restore actions etc.

Steve,

Thank you for taking the time to respond. On the issue of "Cannot Find n" I believe you are mistaken, I shall attach an example from the Linux recovery environment I just went and checked. The folder contains a full backup and the seventh differential backup which I want to recover. 

I'm sorry but I may not understand your second paragraph completely. It seems you are saying that if I copied, say, a full and one differential to another folder I should run validate from the task on the machine that originally created the backup I partially copied. I can't understand how that would work since the task doesn't know I copied the files. Indeed when I right click the task that created the backups I have only the option to validate, no chance to choose my new location.

I am using ATI 2019 build 14690

Thanks again

Richard

Attachment Size
485774-162731.JPG 149.06 KB

On the issue of "Cannot Find n" I believe you are mistaken, I shall attach an example from the Linux recovery environment I just went and checked. The folder contains a full backup and the seventh differential backup which I want to recover. 

Richard, if you are seeing this error message when using the rescue media application, then there is no database involvement and the error is directly related to the files involved in the restore action.

For that scenario, we would need to see what messages are shown in the Log for this attempt, and a listing showing the exact files you are working with in this folder you are using.

I'm sorry but I may not understand your second paragraph completely. It seems you are saying that if I copied, say, a full and one differential to another folder I should run validate from the task on the machine that originally created the backup I partially copied. I can't understand how that would work since the task doesn't know I copied the files.

Richard, my second paragraph didn't use the word copy or copied - it said about moving which is a subtle but important difference that does require validation.  Copying still leaves all the original files in situ so nothing has changed with regards to the Acronis database.  Moving impacts the database causing it to no longer accurately reflect the status of files and their location.

Steve,

Thanks for your ongoing support.

I understand the difference between move (done by ATI) and copy (done by explorer or equivalent). My use case is that I want to take a subset of backups off site while keeping the originals where they are. As I tried to explain by my statement "for example a full backup plus the last three differentials". I see that I wasn't clear. This seems like a typical use-case for disaster backups. I could force a full backup but that would mess up the cycle I have established, would be much larger and once I have a full backup off site I want to be able to take differential backups only every few days.

BTW, another reason I have to at least move the backups before I can restore from them is that the rescue media doesn't recognize storage pools.

I did a recovery under Linus again. I was asked the "Cannot Find" question ten times for each missing differential then again eight times before I could proceed. The two backup files are in a directory of the root names "Hilary Temp: and are named:

My disks_diff_b1_s8_v1.tib

My disks_full_b1_s1_v1.tib

I attached a capture of the folder which also includes the logs I saved using in the rescue enviroment after the disk recovery that gave me the above "Cannot find" messages. That log doesn't seem very useful but I found others at: C:\ProgramData\Acronis\TrueImageHome\Logs although they also look rather sparse are there more logs somewhere I am missing?

Richard

Attachment Size
485814-162741.JPG 22.68 KB
485814-162744.log 1.69 KB
485814-162747.zip 1.47 KB

Richard, the logs are all normal and show no errors or any information related to the 'Cannot find...' messages.

I have to admit to being puzzled that the rescue media environment gave you errors for the missing files, and particularly for a differential version chain, as this would suggest that there is information about the version chain files stored within the .tib files when we have been led to believe this was held in the database and only used in the Windows environment!  I guess that any such restore that I have done has always had all the files present thus I have not encountered this situation for myself!

One thought on the above, I wonder if the 'Cannot find...' message is being generated by virtue of the actual file names involved, i.e. _full_b1_s1_v1.tib followed by _diff_b1_s8_v1.tib where the chain is missing files for s2, s3, s4, s5, s6, s7 - not sure how this figures with your 10 then 8 messages you saw unless there were more than the 8 files in this version chain.

Steve,

Well, thanks for the help. On the good side I can do the restore of the differential in the Linux environment (but wait for it below...). It crashed in both Windows and Windows PE but I don't have the energy right now to figure out why.  

Just for a chuckle I changed the file name of the differential from _s8_ to _s2_ but it made no difference to the process. Then I thought I'd try with a different differential so I deleted my _s8_ and copied in my _s6_ thinking perhaps the number of mouse clicks will reduce. Instead I got a message "This is not the last volume of a backup archive" - now this is a disaster, it means I can restore only if I have the last volume although whether I can restore earlier versions, if I have them as well, I don't know. So I have a full backup and a differential and I can't restore - why is it called a backup again?

Out of interest I did look in the differential using a hex editor to see if there was an obvious reference to earlier .tib files but I found none in ASCII. I also checked for metadata and whether the backup files contain additional streams but nothing.

Maybe not relevant but it reflects on my mood. From before I tried the free version of ATI through buying copies last year up to today my old WHSv1 has chugged away making a backup of every computer every day and because it deduplicates it uses a fraction of the space. I do know that restores from it don't boot in EUFI but the data's there.

Richard

 

Steve,

Here's a question. How would differential 6 know it wasn't the last one or, for that matter, how does the full backup know how many differentials there were? When differential 6 was created it was the last one and the modified dates on both the full backup and differential 6 were not changed after they were created. There's not even any metadata unless I missed it.

 

Richard

Richard, more investigation is needed for this issue as it is totally new to me with this behaviour for handling differential backups in the offline environment.

I would recommend raising a Support ticket with Acronis for this as it goes against what differential backups are described as allowing and looks to be rendering them almost as if they were in an incremental chain with the complaints about missing files, not being last in chain etc!

It will take me a while to setup a recreate scenario where I can test this for myself.

Thanks Richard.

Steve,

I doubt I'll have much luck with the issue of trying to restore something other than the most recent differential backup. Linux is doing strange things and the recover now works. It found the other differential backups and made them available despite the fact that I never opened the disk they were on, however I do know that the full backup tib file includes the information of where it was created so I suspect that Linux read that and went and found all the backup files so if I want to create the problem again I'll need to do it on a computer which doesn't have the backup anywhere.

As a piece of trivia, the number of times I have to click "cancel" is the same for each "missing" backup whether there are five missing or seven.. I may get an answer to that problem as it is reproducible.

Richard

 

I have been following this strange thread.  Never have I seen this particular issue posted here.  I am going to go out on a limb here a bit and I am certain this will sound like a wild idea but here me out.

Each time you boot your machine from a device like USB stick that device will announce itself to your network and register itself with a self generated hostname.  This registration stays until it is released by the Domain Name Server for your network.  If the name is not released because of issues in configuration then they will persist.

If this condition exists for you it could be that True Image is seeing these machines looking for files that it thinks should be there and not finding them is producing the errors you are getting.  I think that because of your statement that you always have the same number of errors and that it is reproducible.

You can clear the DNS name server of hostnames from an admin command prompt using the following commands:

  1. Type ipconfig/flushdns and press Enter
  2. Type ipconfig/registerdns and Press Enter

After you do that try your scenario again and see what the result is.  It may not work but then again, what have you go to loose.

For what it's worth I tried to restore differential 6 (of 8 made) on another machine from a folder with ..._full_b1_s1_v1.tib and ..._diff_b1_s6_v1.tib for which there are also differential backups s7 and s8 that were taken but not on the computer from which I am doing the recovery.

The recovery went into the "Cannot Find n" where n is 2, 3, 4 and 5 and require 6 to 8 cancels for each n. However when I am restoring from the last differential, s6, the cycle never ends unlike with s8 for which it repeats just two times. After cancelling all the "Cannot Find n" messages I get the clock and then it just repeats indefinitely.

Richard

 

Richard, I just did some testing and found some 'strange' results that I wasn't expecting!

My backup was of a small bootable USB drive for which I made an initial Full backup followed by 3 further Differential backups after adding additional data to the drive.

I then removed the backup from the ATI GUI and moved the Full plus the last Differential backups to a different drive location.

When I double click on the last Differential backup in Explorer it actually shows not just that backup but also the other (missing) Differential files and the Full backup, showing there is some linkage here!


This is the original backup location


This is the new backup location with only 2 files instead of 4.


The last image shows the contents of the last Differential backup file shown by Explorer where it shows all the contents of the 4 files even though only 2 of these are in the folder!

I then went back to the original backup location with the 4 files, added the most recent to the ATI GUI and then used the Cleanup Versions tool to remove the middle 2 differential backups to leave only the Full and the last Differential files.

When I open the last Diff file in Explorer, it still shows 4 files but now also gives multiple 'Cannot find version 2 & 3' errors, opening another Explorer window to ask to locate this!  Clicking on one of the abbreviated backup entries in the view gives more 'cannot find' errors before telling me it is 'Empty'!

This suggests that there is definitely information stored within the backup files about other files created as part of the same chain, and that even the Cleanup versions tool is not updating this file information when cleaning out unwanted differential files, which tends to render this to be almost equivalent to being an incremental chain to all intents and purposes!

I would suggest pointing the person working on your Support Ticket to the above findings as this does not look to me to be how differential backups should be behaving!

For anyone following this I have now been officially told by Acronis that I cannot restore anything but the most recent differential unless I have the whole chain, so a disk error in the final differential backup means the entire chain of backups is of no use. Essentially this is like an incremental except that it takes a lot more space.

They tell me I will get the message "Cannot Find x" and the restore will fail.

This means that if I take the full backup and all the differentials but the first differential gets damaged then I cannot restore anything except the last differential!

How can they calmly tell me their differential backups don't work?!

Richard, the ATI 2019 User Guide very clearly states the following which is at odds with the reply you are getting from Acronis for your support ticket!

Recovery: In the example above, to recover the entire work from the 4.tib file, you need to have two backup versions—1.tib and 4.tib.

Steve,

Thanks, I will raise that issue to the support person. The latest I was told is:

...if you want to move the backup version it is not possible to move individual backup versions. A complete backup chain has to be moved i.e, the first backup to the last backup version complete chain has to be moved. 

To me this is absurd, why even have differential backups?

Grrr.

 

Richard

Steve, Others,

Any idea how this can get escalated or get real attention? Basically I'm being told that Differential backups just take up more room and offer no benefit over incremental backups.

 

Richard

Richard, send a private message to Renata Gubaydullina | Product manager, Acronis True Image who should be best placed to review and escalate this - I agree that this makes a mockery of what differential backups are if this is the new reality with ATI 2019.  Point Renata to this forum topic.

I will try to find time to test how differential backups behave on ATI 2018 to confirm that this is a change with 2019.

The response to the position from Steve above about the documentation is:

... the statement mentioned in the web-help related to the backup which are not moved to different location. If the backup has been moved or copied to another location you will face this issue which is the design behavior. 

So Acronis' position is that I can't backup off site without backing up the entire chain. Why should there be any limitation on what I move off-site, I am pretty sure I'm not the only person who has off-site backups!

Has anyone tried this offline with rescue media to see if it still behaves this way as well there? Seems like a bug for sure but maybe doing a recovery with rescue media as a test might at least be a workaround. I haven't had a chance to test any of this yet but plan to tomorrow morning.

Tested this issue with ATI 2018 (from the GUI) and see exactly the same behaviour as I captured in the earlier screen shots, where there is a definite internal linkage to all differential version files in each file created, so any attempt to open a file (except the initial Full) after removing any other differential files triggers an immediate 'Cannot find version X' with an Explorer dialog box shown to browse to where the file is!

This has effectively rendered Differential backups to be the same as Incremental with the added cost of much larger / increasing sized backup in the chain!

Not tried yet from the rescue media but would expect similar behaviour because of information being embedded in the actual files!

What is perhaps more surprising is that there have not been more complaints about this changed behaviour.  I am sure that I have deleted unwanted differential files in earlier versions unless I am mistaken!

Bobbo,

I have tried it several times in the Linux recovery environment with various file combinations. I also tried in windows PE and Windows both of which also failed but I forget the messages.

As Steve said this makes Differentials functionally the same as Incremental and in either case a single damaged file renders the entire backups series useless for both methods, other than the original full backup.

Richard, thanks for checking in the recovery media too.  I'm seeing the same thing in the Windows environment and posting pics for reference.  I have not tested in the recovery environment yet though. 

I did notice that after closing the "cannot locate" windows as they popup several times, I can then navigate the contents of the diff I'm trying to open.  However, with each layer deeper that I try to navigate in Windows Explorer, I get more "cannot locate" prompts that I have to close, and then it shows the content.  So this behavior is definitely not how it should be for a Differential Scheme as you should only need the original full and any single associated differential file with it to restore to that point in time.  This does indeed feel like it's behaving like an incremental backup scheme instead, where it is relying on all versions of the chain to recover from!

The other thing I notice is that when attempting to explore a differential, it is referencing an OLDER last full, which no longer exists!  I.E, I no longer have any version 74's.... I open a DIFF version 75 (where there is a full version 75 to go with it) and Acronis then shows it is referenced with FULL version 74, yet with DIFF version 75!!!  All version 74 were already automatically deleted by the Acronis software as part of the retention scheme (I keep only 2 full versions and have version 75 and 76 presently).  This may be more of a visual bug, but wonder if this is part of the culprit.

 

Attachment Size
487054-163248.JPG 252.59 KB
487054-163250.JPG 120.72 KB

Tested this issue from my MVP WinPE recovery boot environment and got mixed results too.

Validation of the Differential chain (with a missing middle diff file) went as expected with no errors!

Recovery from the same Differential chain (Full plus Diff s3) popped up numerous errors about the missing s2 file, but after hitting cancel to all of these, it did actually complete the recovery then crashed the offline ATI 2019 application followed by creating a System Report zip file for the crash!

Personally, there seems no point in creating Differential backup chains given this behaviour and this is a negative backward step for the ATI application!

Richard, can you share your ticket number please then I will submit a ticket and cross reference to yours too.  I have 2 system report zip files with dumps from the crash when recovering from a differential chain.

Steve,

My ticket number is somewhere in: [03598685] Recover errors [ ref:_00D30Zcb._5001T1CaLBr:ref ]

I wouldn't be surprised at all if the error messages are finite and can all be cancelled. If I had the energy I'd have a Raspberry click the mouse but with a light sensor on the screen to detect the messages

Richard, thanks for sharing your ticket number 03598685 - I will submit my own ticket a little later and cross reference yours.

Richard, have been doing further testing since my earlier update, including digging out an old laptop with Win 7 that I installed ATI 2016 on, so that I could test this behaviour on an older version.

I am sad to say that I see exactly the same behaviour with differential backups even back on 2016 with multiple pop-up windows asking to locate missing versions, normally 2 windows per number!

This was done using some older differential backups stored on a network drive which themselves date back to 2015 & 2016, so it very much likes ATI has been working in this way for many years.

I will still consider submitting a support ticket about this behaviour but suspect that I will be given the same response that this is per the application design!  I personally think that this is a poor design where differential chains require all members of the chain to remain present, as that is counter intuitive to the purpose of a differential being a capture of all changes since the initial full backup for the chain.

I may take a different approach via the MVP community to see if there is a consensus on this design behaviour, as that would help carry more weight for a review of the design hopefully!

I can't say I like it either. Can't believe we never noticed this before though. I imagine the current logic is related to the database keeping track of all files in the chain for automated cleanup and that's where the behavior stems from. So, assuming we delete the diffs not needed via the GUI instead of manually in Windows explorer, we probably wouldnt see this either.

The only issue I still have then, is if it still errors in the rescue media if you only have the full and some other later diff and would not allow for recovery because of some nonsense idealogy that the entire diff chain is needed to continue.

I still haven't gotten around to testing that though. But... If I can recover with rescue media as expected with a full and just any differential associated with it, but not necessarily with all the diffs taken prior to a specific date available I could live with the behavior and need to train myself to use the GUI for cleanup, the same as I've had to do with incrimentals and even entire backup chains in the past.

The only issue I still have then, is if it still errors in the rescue media if you only have the full and some other later diff and would not allow for recovery because of some nonsense idealogy that the entire diff chain is needed to continue.

Rob, the same issue is present in the rescue media for me though I was able to complete a test recovery after cancelling all the multitude of missing volume error messages given!

I tested a number of older differential backups, some with missing files, others with no missing files but created back in 2015 / 2016 and I got these error messages for them all - even when there were no missing differential files - which suggests there has been other changes in how the link is stored within the diff files when handled by ATI 2019 or 2018.

I don't normally use differential backups but with this behaviour I am even less likely to use this type of backup scheme.  If space is not an issue, then keeping to Full backups only is probably going to be the safest bet.  Differential chains for me are now as attractive as a chocolate tea-pot in terms of usefulness!

One point here: the new Clean up versions tool in ATI 2019 is more than happy to let the user delete individual differential files from a chain without throwing any form of warning message about the potential consequences of doing so!

Steve,

I don't know what would happen to the backup if the clean-up tool were used to delete some differentials, maybe it "fixes" the ones left, changing pointers etc. I haven't tried. The person working on my ticket said that the restore wouldn't work with "copied" files, which is what I have since I need a copy off site but I also want to leave all backups on site.

This also means that Validate is not trustworthy since I Validated the full and differential I was trying to restore, twice, and it Validated. One might say that the results of "Validate" are "Valid".

Richard

Yeah, if the GUI lets you remove them but then balk's at missing files in Windows Explorer, that's no good and needs to be fixed. Likewise, with the rescue media, there should be absolutely no version chain dependency at all when it comes to Diffs. I've been using Diffs over Incrementals to avoid backup chain corruption that could potentially over time... If Diff's require a chain, it's flawed and essentially pointless. 

I'm looking forward to some of my own testing at home tonight to see if it's the same behavior all the way around. I ended up running the clean tool yesterday and starting with a fresh slate and fresh backup jobs in an effort to figure out what's up with the "Pre" scripts on my system and still need to play with that some more too.

I will surely be submitting feedback on the Diffs if it is you say!!! 

Well, confirmed with me as well Steve and Richard.  Using Windows Explorer, I get the "locate missing backup" if I move a diff somewhere else and then attempt to open the next Diff file in the "chain".  And, if I put it back, then everything works as intended.  

So, then I deleted one of the middle Diff files in a chain through the Acronis GUI, thinking that would surely update the database at least that way. NOPE!  Exact same behavior even though it was cleanly removed in the Acronis GUI with legitimate options.

Then, as a last ditch effort, I validated the backup with the remaining files and it validated just fine. But, still no dice trying to open the next Diff in the chain through Windows Explorer.  The only recourse is that you can use the Acronis GUI to do a recovery option from within it, but that sure takes away the functionality of the Windows Explorer features that should be working. 

I'm going to test with recovery media just to be sure there as well and report back.  I've taken a video of all this and plan to attach it to my feedback and escalate through the MVP forum...

And last inputs from me as I send in my report... rescue media...

It worked fine for recovery (file/folder recovery as this was a quick and dirty test with just a few items on my desktop). There were no issues there.

However, there is also no option to view what's in the .tib files before you attempt to recover so that is a little different than the full Windows environment.

When I tried to validate the last differential in the backup (of course with one missing that came before it since that was the purpose of the test), it said that the backup was corrupted but might still be able to recover from it and it asked to locate the missing differential .tib.  

I really can't understand why the differentials are working like this as they should be completely independent of each other, so long as the original Full that goes in that chain is also there.

Feedback on its way...

The person dealing with my ticket would not escalate the problem because it is "by design" however I pushed that the Validate process not giving any errors on a backup that won't restore surely cannot be "by design" and he has forwarded at least that to another group.

Has anyone else confirmed that using Cleanup to remove an intermediate differential backup causes the chain to be unrestoreable?

 

Richard

Richard,

I just did another test with a brand new diff task.  I did 1 full with 4 diffs and retained 2 backup chains.  Once I had 1 full chain, my next full and additional 4 diff files in the 2nd chain, I then used the Acronis GUI to remove the 3rd diff in chain #1.  The GUI allowed this with no errors and deleted Diff3 in chain1.

I then used the GUI to attempt a restore with Diff4 in chain1.  I was able to recover just fine and without any issue.

However, I then attempted to use Windows Explorer to navigate the contents of Diff4 in chain 1 and was prompted to locate the deleted Diff.  I closed that prompt twice and then could navigate, but this behavior came back again and again in this particular chain for the diffs after the one that was deleted.

I then attempted to navigate Chain #2 and all was well with the next full and all diffs in that one when attempting to recover with the GUI or navigate them in Windows Explorer.

So... it appears that recover is possible (through the GUI), but the Windows Explorer hooks are treating it like an incremental in regards to needing the entire chain to navigate the backup files from there.  

I'd say this is a bug, perhaps not with the Diff method, or the Acronis GUI, but specifically with how the Windows Explorer hooks are treating the differential files in a backup chain.

FYI... my test was just a small folder using file/folder backup.  I did not see if there was any behvavior difference in a full disk or partition backup.  I'm assuming the behavior would be the same regardless of the backup source.

Bobbo,

Interesting data points, thanks.

My challenge is that I don't want to remove the intermediate diffs fro my main backup. I want to leave the main backup providing me a full and 15 days of diffs with two chains. I then want to take the most recent full and recent few diffs off site for disaster recovery.

Also, what if a diff gets damaged? Could be disk sector going bad, power interruption, errant software etc. I need to be able to rely on the other diffs which in my experience and that of others I cannot.

And, of course, why is Validate happy with backups that can't be restored.

It seems there's a design flaw if a diff system has an reliance on more than one diff and a full as a mechanism for restore.

I wonder how making a vhdx from a diff tib works. It was one of the tests I did before buying ATI but that was with a full chain. If you can't browse the image my guess is you also can't create a vhdx. Dependency of all diffs in a chain is a flaw that is likely to ripple through the entire system.

Richard

Richard,

I suspect that you could take your recent full and some recent diffs and recover with them just fine if need be.  If you're planning on using Windows File Explorer, it would have to be on the system that has Acronis installed though but then we would run into the navigation problem as you've discovered since that appears to be a current bug that needs to be looked into.

 However, you could still recover with your rescue media  if need be (or the Acronis GUI).  I did get a warning in the rescue media that the backup was corrupt when DIFF files were removed and I tried to restore from the ones that came after those in the chain... but my experience was that file/folder recover still completed just fine.  Definitely a bug, but it worked.  I'd suggest testing the recovery of some files/folders in your environment that way to confirm, but I'm pretty sure it will work there too.

Any backup can become corrupted - it's just data like everything else.  If you have a failing disk that the backups live on, or bad sectors, etc.  There's nothing we can do if the disk that holds the backups starts physically failing and impacts the backup .tibs that might live on it.  However, if a particular diff does get damaged, you could try another one and hopefully still be able to recover from it so long as the full is there and you either use the Acronis GUI, or the Acronis Rescue media.  For now though, it looks like Windows Explorer Acronis hooks would likely be out of the question. 

There is no such thing as 100% reliability of data (to include backups).  The best you can do is diversify your backup frequency and locations.  A common I.T. backup practice is 3-2-1.  3 copies of the data, in at least 2 different locations with at least one location offsite (cloud or just physically kept elsewhere as you rotate out drives or tapes or whatever).  You could have the best backup scheme in the world, but if it is all located in your house, and it catches fire, you'd still lose everything because it's all in one location.

I'm not sure about the vhdx conversion.  I've never done it myself (other than a full chain as well and it was just a mock backup with minimal data).  I would suspect you'd need the full and at least a diff and am guessing it would still have similar behavior as were seeing in Windows Explorer if you converted without having all of the diffs in place, but really not sure. Only way to find out is to give it a test and see what happens. 

Quick update - looks like the option to convert to VHDX is only available in disk or partition backups. 

I went ahead and made a new test backup with diffs of my main OS drive.  Then deleted the middle DIFF of the test  attempted to convert to VHDX using the last Diff in the chain as the selected file.

The conversion took a little longer than i expected and ended up being quite a bit larger than the original full backup, but it worked.  I was able to mount the VHDX in Explorer and navigate it just fine.  The VHDX was made by selecting a DIFF that came after one that was deleted in front of it.  No errors or issues.

Attachment Size
488002-163676.JPG 257.62 KB
488002-163679.JPG 148.92 KB
488002-163682.JPG 105.93 KB

Bobbo,

Thanks for making the effort, your result of being able to create the vhdx is reassuring. Once I realized Hyper-V VM's of Acronis vhdx files require Generation 2 virtualizing has been perfect.

My case has been closed based on the fact that there's nothing more to do and the way the software works is "by design".

I've been told that, consistent with my testing:

  1. "there is no way to copy a backup chain" it can only be moved. Copying can "corrupt the script". 
  2. "Validate" only checks the backup files for their "checksum" and doesn't report anything related to the fitness of the backup files to be restored.
  3. If a chain is moved and a differential is corrupted, the backup of other differentials will not be affected

I think I know that:

  1. A backup chain that is copied will not restore in the Linux recovery environment except for the final differential and the initial full backup.
  2. A backup chain that is copied will sometimes restore in the Windows recovery environment though not reliably.
  3. Validate tells me nothing about the capability of a backup to be restored.
  4. ATI is unsuitable as part of an enterprise-like backup because it is not capable of supporting off-site and on-site backups of the same information - if I move something for off-site I lose the ability to recover files or backups quickly.
  5. There is no tool to confirm that a backup can be restored other than attempting the restore.

I don't know:

  1. Why it is not possible to copy a backup and consequently what might make a backup unable to be restored. I recognize that's Acronis' business but if I don't understand it I can't rely on it.
  2. What aspects of a backup amount to a "copy". If a drive letter changes, if a computer name changes, if a network share name changes etc. will the backup become unrestorable?

Acronis has set up a "Customer Listening System (CLS)" on the issue which I understand means it will get attention during software updates.

Richard

I don't think I'd agree you can't copy and move backup chains. I do this all the time too and have never had issues restoring from them with offline rescue media.

I think the caveat is that they want the entire chain to be present though, even on differentials. However this should not be the case for a differential recovery and throws errors in the rescue media and the Windows file explorer hooks. It does not actually appear to prevent successful recovery with the rescue media or the Acronis GUI though.

So, to play it safe, feel free to make copies and take them with you, but when possible take the entire differential chain. If you absolutely can't, you should still be able to restore, but will get warnings that the backup is corrupted but that you can try to restore anyway and it should result in success. If possible, try to test the recovery to a spare drive to confirm the behavior, but don't practice on your main OS drive.

I don't think converting to vhdx is necessary, but doesn't hurt. You can boot them virtually, restore  with them in Acronis, restore with them in windows and mount them in windows. All pros, with the only negative of having to take the time toto imec the tibs and the extra space they take up.

Bobbo,

When I say I can't copy the backup that is under the heading of what I was told (on numerous occasions). I am told I can move it using the ATI tools but not copy. My experience is that I can't restore from a copy except the original full backup and the final differential. The words in quotes in point 1 of what I was told were cut from the support email.

For the record the support staff have been patient and responsive - the messengers are fine, it's just the message that isn't.

Richard

 

 

Well, still can't say I agree. I've copied backups from my local drive to my NAS and vice versa as well as over to a portable USB on several occasions and have been able to recover just fine. 

Copying files  elsewhere does not change the checksum of the file. If the checksum compares equally to the original and the copy, it's going to be the same data in those files.

Also, if that was the case, you wouldn't be able to restore images to a new computer because it would have no idea that the backup was meant to be on that drive or not since it never interacted with it before. 

Now, with the missing or deleted differentials in a "chain" I can see the Acronis behavior we see in Explorer, but not sure why your restore would fail when using rescue media. I just tested this the other day and all of my recoveries were successful. Granted, they were file/folder backup and recoveries, but shouldn't matter. I will test with a full OS disk recovery later this weekend though. 

---update

To clarify...

I do agree you should not copy files or move them just for the sake of moving them, outside of Acronis. The internal scripts and database account for where backups were created and located and reference that information for validation, versioning and cleanup.

But, copying elsewhere and using for recovery, especially with recovery media, has no impact on the database or script in the OS. The key here is that you should be using offload be recovery and not Acronis in Windows if you are making copies of your backup files.

This is another reason I hate that the GUI automatically scans your drives and adds backup files from anything it finds. It should ask the user where to scan and only scan those folders to avoid this behavior if it does find a copy of an existing backup and tries to add it, or that somehow can mess up an existing script which already calls on the same backup from the original location where it also already exists.

One more thing to add. Under instruction I tried to Linus Recovery restore from a differential (other differentials missing) and its full backup that had been copied. I had to cancel the "Cannot find x" message about 400 times and then the recovery worked. Apparently that is known behavior.

Richard

Yeah, was reported recently and seems to be the case. I hope Acronis fixes this. Diffs should not require a "chain" in the recovery environment.

At least you were able to confirm the recovery actually works (but that behavior is super annoying)!

As you have proven, there is no reason copying should have any impact on recovery when using rescue media as long as the chain is good... But there should be no reliance on a chain for diffs, only incrimentals and that is the issue at present when using the rescue media or navigating tibs with Windows file explorer when using a later Diff in the "chain" and earlier diffs are not present.... Even if they were cleanly deleted in the Acronis GUI.