network drives
I have two Netgear ReadyNAS Duo network drives.
Can Acronis TI2010 recognise network drives to allow a backup/restore.
I am running Windows 7 pro 64-bit.

- Log in to post comments

Hi Rannoch,
I too am using Netgear ReadyNAS drives for backup (with Acronis TI Workstation), and I've had problems with corrupt archives (see thread "Need to recover data from corrupt backup file"). Noone has been able to suggest why this should be the case, but personally I would put a (mirrored) NAS server as the least likely possibility.
My original ReadyNAS had 2 x 500GB drives, but I've just purchased another with 2 x 1.5TB to provide space for multiple backups. Acronis TI doesn't seem to want to play with the new one either. Apart from failed archive validations, I see the following error message intermittently (even on validations that after a "Retry" go on to validate OK)
E00640001: Error reading the file. A possible reason may be poor media quality.
One might assume a network issue, but I'm using the motherboard's (Gigabyte) own GB ethernet port, and a reputable (Belkin) switch. Never seen any other network related issues on the system, and in any case there should be enough error handling built into TCP not to have to worry about it... Once I can make some space on the PC concerned I'm going to try copying some archive-sized files (200GB) between the NAS and the local drive with before/after checksum tests. I'll post here what I find, but for now I just think that not only does TI not validate as it writes there seem to be no tools to efficiently recover whatever is still valid in an archive.
- Log in to post comments

I am also using TI 2010 and other versions with a Netgear ReadyNAS NVX, and TI 2010, when booted from a CD, only intermittently finds network based resources. On time it will, another time it won't...
By the way, the problem is in the network browse function. If I enter the path of th e ReadyNAS, something like \\ReadyNAS\backup\archive.tib, it has no problem finding the NAS and creating the archive.
I looked at the backup data stream using Wireshark, and didn't see any problems with the Layer 3/4 info (TCP/IP) that might cause a slow backup (excessive retries) or outright corruption (lost data).
I only have a week of experience with the 2010 product, and my evaluation is that the 2009 version was much less buggy. There are several features that worked in 2009, and are completely broken in TI 2010.
Cheers,
Gregg
- Log in to post comments

Hello all,
Thank you for posting your question, I will be happy to help.
To resolve the issue pleaqse use a pre backup command to mount the mapped drive for an Acronis scheduled task:
- Download map.drive.txt;
- Follow instructions in Using Batch Files in Acronis True Image.
Also I would recommend you to set the appropriate permissions to save to and restore from shared folder on your NAS device. The respective table is available in this article. It describes on how to set the permissions in Windows, the instructions on how to set the permissions for NAS folders are available in the documentation that comes with the device.
Please let us know the results, we should be sure that the program runs flawless for you. If the provided information is not clear or if you have any other question do not hesitate to post them and we will be glad to answer.
Thank you.
- Log in to post comments

Allan Green wrote:Hi Rannoch,I too am using Netgear ReadyNAS drives for backup (with Acronis TI Workstation), and I've had problems with corrupt archives (see thread "Need to recover data from corrupt backup file"). Noone has been able to suggest why this should be the case, but personally I would put a (mirrored) NAS server as the least likely possibility.
My original ReadyNAS had 2 x 500GB drives, but I've just purchased another with 2 x 1.5TB to provide space for multiple backups. Acronis TI doesn't seem to want to play with the new one either. Apart from failed archive validations, I see the following error message intermittently (even on validations that after a "Retry" go on to validate OK)
E00640001: Error reading the file. A possible reason may be poor media quality.
One might assume a network issue, but I'm using the motherboard's (Gigabyte) own GB ethernet port, and a reputable (Belkin) switch. Never seen any other network related issues on the system, and in any case there should be enough error handling built into TCP not to have to worry about it... Once I can make some space on the PC concerned I'm going to try copying some archive-sized files (200GB) between the NAS and the local drive with before/after checksum tests. I'll post here what I find, but for now I just think that not only does TI not validate as it writes there seem to be no tools to efficiently recover whatever is still valid in an archive.
Just for grins, try setting/adding a registry entry for IRPStackSize. The reason I suggest this is that another ATI user had issues trying to create differential or incremental backups, yet he could successfully do full backups. He added IRPStackSize along with an appropriate value to his registry, rebooted, and this (amazingly) resolved his problem.
See this article for a description about IRPStackSize:
http://support.microsoft.com/kb/285089
And see this article about an issue with a small range of IRPStackSize values which cause problems on Windows Server 2003:
http://support.microsoft.com/kb/924749
Finally, see my forum post about IRPStackSize and not being able to browse the drives on your computer from other computers on your local network:
http://forum.acronis.com/forum/6204#comment-11399
So, to avoid any errors or problems with whatever Windows OS flavor that you are using, I suggest setting IRPStackSize to 20 (hex) or 32 (decimal) which should give your OS plenty of stack space for the low level drivers used by ATI and by various security products such as anti-virus and anti-malware products. Decimal values of 33 through 38 decimal can cause issues on Win Server 2003, so avoid that range. Stack space is also consumed by USB memory devices, extra hard disks and/or additional partitions, and network shares. Setting IRPStackSize to 32 should be enough to handle all of these conditions, but not always. You could always try a quick and dirty test of setting the IRPStackSize decimal value to 50 which is the max, and see if this resolves the "E00640001: Error reading the file" problem. Note that you have to reboot for any change to the value for IRPStackSize to take effect.
- Log in to post comments