Mapped drives for user repository

When a user is created in Syncrify, you have to specify a repository path where backup files are stored. Often users want to specify a remote folder or a mapped drive for user repository. In such case 3 machines get involved in the backup process:

1. Client machine
2. Server machine - where Syncrify server is running
3. Storage disk -this is where the actual backed file will reside

Before you configure Syncrify to run in such configuration, following important information should be kept in mind

• Syncrify runs as a service on Windows. Mapped drives are usually NOT available to a service. Therefore, rather than using mapped drives use UNC path.
  
  
• The user account that is used to run Syncrify service must have permission to access the remote machine. By default, Syncrify service runs under Local System Account. Consider changing this to a local user who also has permission on the remote machine.

Regardless of the method (UNC path or using a different account), these methods are discourage since they make the disk remote to the CPU.

Disadvantages of using a third machine

Although, using a third machine is possible, its use is discouraged. Syncrify's backup algorithm tries to minimize network traffic at the cost of local disk I/O. When you use a remote repository, you are increasing unnecessary network traffic between the machine where Syncrify server is running and the actual disk is stored. Refer to the image below.



When a network storage is used, three machines get involved:

• Syncrify client - this is where the original file stored
  
• Syncrify server - this is where the Syncrify server assumes the target file resides
  
• Storage disk - this is where the actual file is located. This could be a Windows machine or a NAS device
  

The most important design goal in Syncrify is to reduce network traffic. This goal is achieved by using the rsync algorithm, which is used between machine 1 and 2. When a third machine is involved, this goal gets skewed and therefore, is discouraged.

Often administrators believe that using a fast network connection will eliminate such delays. This is not correct. Following side-effects occur when the repository is on a different machine:

• Syncrify server computes file delta again on the server side when versioning is enabled. The rsync protocol will generate a lot of network traffic while deltas are computed, resulting in longer backup times.
• The temporary folder most likely won't be on the remote machine. As a result, files cannot be renamed. After receiving delta from the client, a new version of the file is rebuilt in the TEMP folder. Then, Syncrify renames the file replacing the actual one. When repository is on a different machine, the entire file gets copied again.
• It is very common to lose network connections temporarily that occurs due to overloaded routers or machines. A slight glitch in the network will result in I/O errors. Such network errors will make the software (Syncrify in this case) think the disk is no longer available.

As a solution, consider installing Syncrify on the machine where the disk is local. You can even use a USB drive for the repository.