Backups created in older versions
I have just upgraded from ATIH 2011 to True Image 2019. The manual says that backups created in older versions will automatically be added to my backup list, but they are not there and I can't see how to pick them up. Perhaps because the backups themselves are on my NAS?
Can anybody help, please.
Steve
Thanks for the prompt reply. Yes - I did uninstall ATIH 2011 before I started. I have now found the option to add a backup and, after the odd misfire, added the one I needed and validated it. It appears to add the last full version, not the latest actual backup. (I use a daily scheduled backup, with a backup chain lasting 5 weeks, and a full backup every 7 days).
However, the added backup is not scheduled, and if I go into the Reconfigure screen, it seems I have to reconfigure from scratch, since nothing is selected. This rather defeats the object of the exercise.
I then tried a test recovery. Although the NAS is visible, so the credentials are valid, the recovery failed "access to the file is denied". I looked for somewhere to input the credentials in the recovery job, but without success. Where am I going wrong, please.
I have now found the option to add a backup and, after the odd misfire, added the one I needed and validated it. It appears to add the last full version, not the latest actual backup. (I use a daily scheduled backup, with a backup chain lasting 5 weeks, and a full backup every 7 days).
If you selected the most recent backup file for your backup chain, then it should have added that file along with the other files for the same chain.
However, the added backup is not scheduled, and if I go into the Reconfigure screen, it seems I have to reconfigure from scratch, since nothing is selected. This rather defeats the object of the exercise.
Scheduling is never carried forward from older backups, and any existing backup you add requires the task to be reconfigured as there is no information to show what the previous configuration settings might have been, especially when coming from a version 8 years distant in the past.
The good news here is that in ATI 2019 (and 2018), Acronis added new options on the Settings page in the GUI (at the bottom of the page) which allows you to save your settings to a zip file, then be able to import those settings back again if doing a reinstall.
I then tried a test recovery. Although the NAS is visible, so the credentials are valid, the recovery failed "access to the file is denied". I looked for somewhere to input the credentials in the recovery job, but without success. Where am I going wrong, please.
Difficult to say without knowing more about how you tried to do the test recovery? Was this from within the Windows ATI GUI, or did you use the Acronis Rescue Media, or did you try copying files or folders via the Windows Shell integration with File Explorer. Also when was the access denied error given, was this for the file on the NAS or for the destination where you were attempting to recover to?
Steve
Thanks. I will need to recreate the backups, in that case. I'll do that tomorrow - getting late here now.
The failure message just said access denied; screenshot attached. That makes me think it is the source file. However, I can access that folder or its root perfectly well in ATI - I did a test backup earlier and it ran OK. I did it via the ATI GUI.
Win7 Home Premium 64 bit.
Chris, the screen image shows the access denied is when recovering to the original location for the data you are choosing. I would suggest picking a different location to recover files too, which will show that there is no issue with the recovery process.
Files in the backup are normally stored with their original permissions (owner etc), and depending on where you are recovering to, you can be trying to replace a file owned by a different owner or with different permissions.
There are options for the Recovery that can allow you to recover files without their original permissions which then allows them to inherit the permissions for the user doing the recovery instead.
File recovery options
Location: Recovery options > Advanced > File recovery options
You can select the following file recovery options:
- Recover files with their original security settings - if the file security settings were preserved during backup (see File-level security settings for backup), you can choose whether to recover them or let the files inherit the security settings of the folder where they will be recovered to. This option is effective only when recovering files from file/folder backups.
Chris, where are the backups located? I've had backups on external drives where the permissions were set by the old computer (i.e. oldcomputer\\all users instead of newcomputer\\all users). It's not often this happens with external drives, but not entirely uncommon either. You might try opening the properties on the root of your external drive and giving "all users" full access to it again (this time though, it would be for all users on this computer that Acronis is accessing). Then see if you still get that access denied message.
EDIT**** just saw Steve's post too. That would be the other issue. If you are trying to replace a file currently in use, this can happen. Never attempt to recover system (Windows OS) or applicatoin (specific applications running) with a file / folder recovery. You only want to use a file/folder recovery to recover things like personal data (documents, pdfs, music, videos, etc). And if that's what you're attempting, a lot of times, it's easier to recover them to a new temporary location (like a blank disk or spare USB drive) and then copy them to the final location after that.
Steve and Bobbo - thanks for your ideas.
Firstly, my backups are all on a Synology NAS, where the client PC has full access to the shares on the NAS, both to read and write. This has been stable for a long time. I think that covers Bobbo's point.
I ran the following experiments. In every case, I had either removed or renamed the file I was trying to restore, and it was not open on the client PC. In each case, my restore was of one sample file.
a) I had run a small test backup under ATI 2019. I went back to this backup and restored one of the files. The restore was successful.
b) I tried a restore from the old ATI2011 backup, after a reboot. Still failed
c) I tried a restore from the old ATI2011 backup to a different location. Still failed.
d) I tried a restore from the old ATI2011 backup without the original permissions. Still failed.
It looks as if the problem, therefore, lies with ATI2019 reading the ATI2011 backup, not with the permissions on the NAS. This is odd, because I had validated the backup successfully, and could seethe individual files in the backup when navigating for the recovery.
Any ideas on where I should go now?
One further test. Yesterday, Windows could not see inside the ATI2011 backup - the green bar never finished. Today, after a reboot, Windows could see inside the backup and I was able to restore a file successfully. That is OK for a single file, but if I needed to do anything bigger, or restore a full disk, I would need the functionality of ATI.
Chris, in older versions, it looks like there is limited compatibility within the GUI for Windows file explorer integration. It says its not supported so I am surprised it worked at at all, but you should still be able to restore though. Another alternative is to maintain the rescue media from 2011 so that you can restore with it. Please check out the compatibility matrix here.
As for accessing .tib content directly from a NAS, through Windows Explorer, it's working fine for me in 2019 with current backups. It may be that the difference between the two versions is too great since older versions used smb 1.0 and now it is insecure and all but deprecated by Windows now too. A common work around is to copy the backup to a local USB and recover from it to see if it behaves differently. May be worth a shot to see if the recovery goes better from there and also test to see if the file explorer navigating and restore method might function better as well.
I don't have many other ideas since 2011 is so much older and don't have old backups in my environment.
Bobbo
The compatibility chart shows that ATI2019 should be able to restore from 2011 backups, so I am not sure why it isn't working for me.
Accessing the backup on the NAS via Windows is the bit that does work - see my second post this morning.
I'll try copying the backup somewhere else and restoring from there, and see if that works.
Correct, at least restore should work, just not necessarily with the Windows file explorer hooks. From the Acronis GUI or rescue media, it should indeed work though!
I could see where permissions could be an issue if restoring to the original location. But if you were to restore to say an external usn hard drive (and verified that all users and or authenticated users of that particular computer have full access to the root of that external drive first), I would hope that it restores to exactly it's supposed to. Keeping in mind if it's not done in Windows through the Acronis GUI, but instead with rescue media, if the source and/or destination drives are encrypted with Bitlocker, they need to be unlocked first too.
Bobbo
Thanks. I tried the following
1 File restore from the original NAS backup to and external usb drive - failed no access again.
2 I copied the backup to the external NAS, per your workaround. I then restored a file to its original location on my PC - succeeded.
So, it looks like my route forward is:
a) manually recreate my backups in ATI 2019 and start again. Then, as I reach the expiry dates, delete the old backups manually until ATI2019's version chain has fully taken over.
b) if I need to restore from any of the ATIH2011 backups, copy them to an external hard drive first.
c) I probably need to recreate all my emergency disks, since I doubt I can rely on the ATIH2011 versions in ATI2019.
Many thanks for your help.
Just one last comment, more for Acronis - this does seem a great deal of work for a version upgrade (although it does seem they have fixed that in current versions, from Steve's comments).