Syncrify » Knowledge base

Document information

Document ID: 2196
Subject: Using mapped or remote drive with Syncrify client
Creation date: 10/1/12 5:46 PM
Last modified on: 12/12/18 3:56 PM


Remote or mapped drives

Often users try to backup a remote folder with Syncrify client to a Syncrify server. Consider the following image below.

A B C
Remote machine Syncrify client Syncrify server


In the above example, Syncrify client running on machine B backs up a files that actually reside on machine A, via a mapped/DFS drive or a UNC style path.

Although this configuration is possible, it is strongly discouraged. It is very important that Syncrify client runs on a machine where CPU and disk are local to each other. There are several problems with this approach, which are mentioned below.

Problem 1: Excessive Network Traffic
When you backup a remote resource, significant network traffic is introduced between the CPU and disk, which not only slows down backups but will also slow down your network.

The Rsync algorithm used in Syncrify tries to minimize the network traffic at the cost of local disk I/O. You will see tremendous network activity between machine A and B when the disk is on a different machine.
Problem 2: Permissions
Backup jobs are typically triggered by a service running in the background. This service runs under the Local System Account on Windows. Every Windows machine has a built-in account called SYSTEM and its password is hidden from the user. Since passwords are different across machines, you may not be able to backup folders/files residing on other machine because the OS will deny access. In such case, consider running Syncrify client service (Backup Monitor Service) under a user account that has access to the remote drive AND the passwords are identical on both machines (where Syncrify client is running and where the disk is located)

This permission problem is evident when you try to run a backup manually, which will always work. This happens because operating system asks for the user id/password the first time someone tries to access a remote resource and will then remember those credentials for the rest of the session. Since there is no way for services to prompt for this user id/password and therefore, the machine running Syncrify client will not be granted permission to access the remote machine.
Problem 3: Mapped Drives
You cannot use mapped drives. Drive maps are not available to any service on Windows. You must use UNC style path, for example:

\\RemoteMachine\Path
\\adroot.yourcompany.com\DFS\SharedDocs
Problem 4: VSS will not work
Files that are in use and locked will be skipped. The locked file feature in Syncrify uses VSS on Windows, which is only available for local drives.

Solution

Consider the following two options as an alternative:
  • Install Syncrify client on the machine where disk is local with respect to the CPU
  • Use Simple Copy, which does not use the Rsync algorithm. This will reduce network traffic between machine A and B but will transfer entire file even if a single byte is modified, increasing the traffic between B and C.




Add a comment to this document

Do you have a helpful tip related to this document that you'd like to share with other users?

Important: This area is reserved for useful tips. Therefore, do not post any questions here. Instead, use our public forums to post questions.

Navigation

Social Media

Powered by 10MinutesWeb.com