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.