Data Recovery and Disk Utilities Forum @R-TT

Guest wrote: My final suggestion (which you gave a thumbs up to in your reply) to R-tt: It would be convenient to have the option to provide a credential associated with backup destinations (primarily for networks but even in certain local contexts this could be useful). It would also be nice if it were easier to browse for network backup destinations on adminstative shares that are not visible in the tree such as 'c$' or 'd$' since currently I have to manually type full paths for these.

Thank you for the suggestions. I've passed them to our developers.

Another tip, in your Antivirus client, you should always put mounted network shares on the exclusion list (provided the host that provides the share is protected as well). You will see great speedups in network transfers when you do this. How great they are depends on your AV software, some slows down network transfers by as much as 70-80% when network shares are not excluded. As for AVG , i have not had many positive experiences at all other then its free. A very good AV scanner for Win based machines (available to linux also) is NOD32 in my opinion. Just make sure to uncheck the "detect potentially unwanted applications" on server installations or you will experience weird behaviours that some applications and services might refuse to start because they are silently killed.

You should also exclude R-Drive from the AV tool since your AV software will constantly probe and scan that process during imaging, this might help to speed up the process as well.

There are some imaging products that offes both Filbased imaging and Sectorbased. The filebased do in most cases support to keep all NTFS permissions, however, they are unlikely to be able to backup your System Volume Info unless the task is run under the local system account. Some people use this option because the backup archives are usually considerable smaller then a sector backup, however its in most cases also much slower. I would not recommend this type of imaging backup if your goal is to have a 1:1 copy of your drive.

Good luck, and hope this is of any help to you.

I really need to register a forum account! Anyway, thank you very much for the replies - I checked and saw System Volume Information is backed up (unlikely what I falsely assumed and you also disagreed with) so I do indeed have a complete backup. That is pretty much perfect because I was also worried that with bizarre security permissions you would need a list of users to attempt enumerating folders and reading files (bizarre as in a folder only allowing SYSTEM containing a folder only allowing USER containing a folder only allowing SYSTEM). Sounds like I am overthinking this though because you do it at a sector level not the file level - using some sort of service meaning the files are backed up regardless of permissions.

Lastly, when I had the very slow backup with errors it was all local (no network). AVG Free 8.5 may have been installed/running and it has been causing different random I/O errors - as well as on another machine. I will try to confirm that AVG Free caused the slow down and event log errors which I suspect it did. The event log being reliable does make the UI aspect of my request pretty unimportant and arbitrary as I rethink it.

All in all, looks like there is no real issue then with using the user account. If anything your suggestion of a more sophisticated designated backup account seems like the right next step though I do not really feel the need right now.

My final suggestion (which you gave a thumbs up to in your reply) to R-tt: It would be convenient to have the option to provide a credential associated with backup destinations (primarily for networks but even in certain local contexts this could be useful). It would also be nice if it were easier to browse for network backup destinations on adminstative shares that are not visible in the tree such as 'c$' or 'd$' since currently I have to manually type full paths for these.

I have a week left on the trial but thanks to this clarification I am now fairly certain I will buy the licenses.

naturally, the local system account does not have access to network shares unless you have granted full access to any account, which i shouldnt suggest. I believe in a domain environment you have to give the machine account of the host privileges to that share to. I would not recommend this. For a domain, use an domain administrator account or create a backupadmin account for this sole purpose. For a workgroup environment, make sure to use an account that has full read/write access to the network share or naturally you will have trouble.

The errors you get in your log would logically suggest an issue with your hardware. That is, either u get timeouts with the controller driver / hardware when reading data or there are physical defects on your disk. However, that could not be the case if you do not experience this behaviour by simply changing to a user that is a member of the local administrators group.
What OS are you running? What types of drives and on what controller?

Normally and in almost all cases, the I/O Device error message in eventviewer is something that is reported from your hardware, in most cases your harddrive or your harddrives controller driver.

A very basic, but simple advise worth trying. 1; if you have Antivirus products running, temporarily disable it. 2: make sure you have the latest drivers installed for your HD controller.

I noticed that under Local System, when the backup went extremely slow imaging a local drive onto another local drive, the event viewer got flooded with application logs: Read Disk C: at position <x> failed after 2 attempts. The request could not be performed because of an I/O device error (1117). <x> increases with each log. All during the first minute of the job though I suspect the time stamps are wrong.

I contend that there is some Local System issue with local backups causing I/O errors and slow backup. There is also the issue of network shares not being supported from Local System. The last issue of no UI as implied before would be little needed if these situations which will currently require troubleshooting, were handled.