Restoring files from Acronis backup TO Synology NAS
I am trying to populate a shared folder on Synology Drive (Cloudstation successor) from a series on Acronis backups. I want to end up with common files, including older versions of the files in the folder, with versioning provided by Synology Drive.
My Synology DS3612 named Diskstation1 has two volumes:
Volume 1 contains the shared folder Common1
Volume 2 contains the TIB files create by Acronis file backup under Windows 7
I ran a test, "recovering" a file from a TIB file to \\Diskstation1\Common1. Acronis True Image 2019 reports that the file recovery failed. The log shows the following:
6/19/2019 6:22:30 PM: Recover Backup Archive From file: \\DISKSTATION1\Backup2\Desktop2\D\D Backup to NAS_full_b80_s1_v1.tib Recovery of: Files Recover to: \\DISKSTATION1\Common1\
6/19/2019 6:22:31 PM: Failed to recover file or folder 'Blendery 2019-2020 Budget Estimator 20190109.xlsx'.
Failed to restore the file (folder). (0x4001A)
Path = "\\?\UNC\DISKSTATION1\Common1\Blendery 2019-2020 Budget Estimator 20190109.xlsx~DH4J4187",
Hints = 1),
$module = "ti_demon_vs_17750"
`anonymous-namespace'::DoBackupWrite:
c:\bs_hudson\workspace\790\core\file\windows\winnt_backup.cpp(394)
The specified account does not exist (0xFFF0)
code = 80070525),
$module = "ti_demon_vs_17750"
Common::Error::AddWindowsError:
I can drag the file from the TIB file to Common1 using Windows Explorer, and could do the same for the directories I want on my initial restore to Common1. After that, I want to restore only new or changed files from subsequent backups to minimize the number of file versions.
My PC has run a scheduled backup using Acronis (currently TI 2019) 6 nights a week for that past 2.5 years and has had no problems building TIB files on Volume2. I'm baffled as to why Acronis refuses to write to the shared folder on the other volume. I have the shared folder permissions set for read write access by my user as well as admin.
Has anyone here seen this problem, and have a remedy? Thanks in advance!
Bobbo_3C0X1 wrote:It's usually a permission error when trying to recover directly to the NAS as Acronis is launched with the Windows account permissions and that account does not have direct access to the NAS to copy files from outside of the .tib.
You can see this issue with Robocopy in Windows too. You usually have to recover the files locally and then move them to the NAS. You can use Robocopy to do that manually or make a small .bat file you can just click on, add to the end of a backup task or schedule with windows schedule manager.
If using Robocopy, you need to use the /sec switch to remove the original file permissions and let the NAS set them instead when copied (based on whatever permissions the share has)
Thanks for the reply, Bobbo. Is there any way to grant permissions on the NAS to the Windows account used by True Image 2019? I tried using Synology Assistant to map my NAS destination (Common1) to the M: drive as the NAS admin, and specify M: as the recovery destination. That gave me a bit more information in the log, where I put some key messages in bold.
Failed to recover file or folder '2014-03-25 08.07 Coca-Coca Global Hospitality _ Eventley Weekly Project Review.wmv'.
Failed to restore the file (folder). (0x4001A)
Path = "\\?\UNC\10.0.0.7\Common1\2014-03-25 08.07 Coca-Coca Global Hospitality _ Eventley Weekly Project Review.wmv~63D0G69V",
Hints = 1),
$module = "ti_demon_vs_17750"
RestoreFile:
c:\bs_hudson\workspace\790\core\file\windows\winnt_backup.cpp(1,368)
Access to the file is denied. (0x40014)
function = "CreateFileW",
path = "\\?\UNC\10.0.0.7\Common1\2014-03-25 08.07 Coca-Coca Global Hospitality _ Eventley Weekly Project Review.wmv~63D0G69V",
$module = "ti_demon_vs_17750"
`anonymous-namespace'::FileHandle::init:
c:\bs_hudson\workspace\790\core\file\windows\winnt_backup.cpp(175)
Logon failure: unknown user name or bad password (0xFFF0)
I interpret this as True Image trying to access the destination as or through an anonymous-namespace with insufficient permissions to create a folder on M:.
I'd like to avoid the intermediate steps of restoring to a local disk, then copying to the Synology Drive for each of 100 TIB files, at least manually. If True Image had a command line means of launching recovery, specifying a specific TIB file, I could do with a script. I have not found a way to do that, though.
Does anyone have any better ideas?
Acronis True Image does not provide any method of scripting recovery to any destination.
Have you tested recovering from a .tib file stored locally to your chosen NAS destination instead of recovering from a different NAS location?
Thanks for the suggestion, Steve. I did the following:
- Copied one of the TIB files from the NAS to a local disk on my Windows 7 PC
- Add the TIB on the local disk to the backup in True Image
- Recovered the backup, specifying the the local TIB file by date
The log no longer shows the "Access to the file is denied. (0x40014)" message,
but continues to show the "Failed to restore the file (folder). (0x4001A)" message, along with "The specified account does not exist (0xFFF0) code = 80070525)"
If someone uses True Image to back up one Synology NAS to another via a PC, would they be able to recover their backup?
Richard, this does still look to be a permissions issue which suggests that recovery is using a different account for some reason?
I have never tried doing any recovery to my own Synology NAS and only use it purely for storage of my Acronis backups plus with Synology Drive as cloud storage shared between a number of my PC's and other devices (iPad, phones etc).
I backup my documents, photos, etc to the NAS plus also sync them via the NAS using Drive so that there are copies in multiple locations and formats.
Recovery from the NAS to Windows & Linux systems should be no issue provided a connection can be made when using the Acronis bootable Rescue Media (for OS recoveries) or else recovery of files / folders can be done within Windows. My Linux (Ubuntu / Xubuntu) backups are for disk & partitions as there is no ATI app to run within the Linux OS.