Skip to content

Server Job Requirements

Requirements for File and Folder Protection

Operating System

The following operating systems are supported for files and folders jobs.

  • Windows 2022 and Server Core 2022
  • Windows 2019 and Server Core 2019
  • Windows 2016 and Server Core 2016
  • Windows 2012 R2 and Server Core 2012 R2

Warning

Windows 2022, 2019, and 2016 support are for primary Operating System features. Secondary Operating System features specific to these newer Windows versions, such as Nano Server, Windows Containers, and so on, are not supported.

Warning

DNS updates are not supported for Server Core servers.

File System & Server Configuration Requirements

SyncSafe Replication supports the NTFS file system. On Windows 2016 and later, ReFS is also supported. FAT and FAT32 are not supported. For detailed information on other file system capabilities, see Workload Replication Caveats and Additional Considerations for more details.. The following are requirements for installing the software on a Server.

  1. Microsoft .NET Framework—Microsoft .NET Framework version 4.8 or later is required on the source and target.

  2. The minimum system memory on each server is 1 GB, but 2 GB or greater is recommended.

  3. Disk Space for Installation and Replication - this is the amount of disk space needed for the SyncSafe Replication program files. The amount depends on your operating system version and ranges from 350-500 MB.

  4. The program files can be installed to any volume while the Microsoft Windows Installer files are automatically installed to the operating system boot volume. Make sure you have additional disk space for SyncSafe Replication queuing, logging, and so on.

  5. Server Name - SyncSafe Replication includes Unicode file system support, but your server name must still be in ASCII format. Additionally, all SyncSafe Replication servers must have a unique server name.

    Note

    If you need to rename a server that already has a SyncSafe Replication license applied to it, you should deactivate that license before changing the server name. That includes rebuilding a server or changing the case (capitalization) of the server name (upper or lower case or any combination of case). If you have already rebuilt the server or changed the server name or case, you will have to perform a host-transfer to continue using that license. See the SyncSafe Replication and OpenText Migrate Installation, Licensing, and Activation document for complete details.

  6. Time - The clock on your SyncSafe Replication servers must be within a few minutes of each other, relative to UTC. Large time skews (more than five minutes) will cause SyncSafe Replication errors.

Networking Requirements

The following network and network protocols are required for installation and operation:

  1. Your servers must have TCP/IP with static IP addressing using IPv4.

  2. If you are using SyncSafe Replication over a WAN and do not have DNS name resolution, you will need to add the host names to the local hosts file on each server running SyncSafe Replication.

  3. If your target server only supports DHCP, for example Windows Azure, keep in mind the following caveats:

  4. A target reboot may or may not cause a job error depending on if a new address is assigned by DHCP.
  5. Do not disable the DHCP client service on the source. Otherwise, when failover occurs the DHCP client will not start and an IP address cannot be assigned.
  6. NAT Support — SyncSafe Replication supports IP and port forwarding in NAT environments with the following caveats.
    1. Only IPv4 is supported.
    2. Only standalone servers are supported. Clusters are not supported with NAT environments.
    3. Make sure you have added your server to the SyncSafe Replication Console using the correct public or private IP address. The name or IP address you use to add a server to the console is dependent on where you are running the console. Specify the private IP address of any servers on the same side of the router as the console. Specify the public IP address of any servers on the other side of the router as the console.
  7. DNS failover and updates will depend on your configuration:
    1. Only the source or target can be behind a router, not both.
    2. The DNS server must be routable from the target.
  8. Reverse Lookup Zone - If you are using a DNS reverse lookup zone, then it must be Active Directory integrated. SyncSafe Replication is unable to determine if this integration exists and therefore cannot warn you during job creation if it doesn't exist.

  9. DNS - You can failover Microsoft DNS records so the source server name resolves to the target IP addresses at failover time. To be able to set up and failover Microsoft DNS records, your environment must meet the following requirements.

    1. The source and target servers must be in the same domain.
    2. The target must have WMI/DCOM connectivity to any DNS server that you have configured to be updated.
    3. Each server's network adapter must have the DNS suffix defined, and the primary DNS suffix must be the same on the source and target. You can set the DNS suffix in the network adapters advanced TCP/IP settings or you can set the DNS suffix on the computer name. See the documentation for your specific operating system for details on configuring the DNS suffix.
    4. If you are using a DNS reverse lookup zone, then the forward zone must be Active Directory integrated. SyncSafe Replication is unable to determine if this integration exists and therefore cannot warn you during job creation if it doesn't exist. The zone should be set for secure only updates to allow for DNS record locking.

  10. DNS updates are not supported for Server Core servers

  11. If your servers are joined to a domain, for example CompanyABC.com, but the DNS domain is different, for example CompanyXYZ.com, you may have issues creating a job and will need to make a manual modification to the job after it has started.

Windows Server Requirements

  1. Windows Firewall - If you have Windows firewall enabled on your servers, there are two requirements for the Windows firewall configuration.

  2. The SyncSafe Replication installation program will automatically attempt to configure ports 6320, 6325, and 6326 for SyncSafe Replication. If you cancel this step, you will have to configure the ports manually.

  3. If you are using the SyncSafe Replication Console to push installations out to your Windows servers, you will have to open firewall ports for WMI (Windows Management Instrumentation), which uses RPC (Remote Procedure Call).

  4. By default, RPC will use ports at random above 1024, and these ports must be open on your firewall. RPC ports can be configured to a specific range by specific registry changes and a reboot. See the Microsoft Knowledge Base article 154596 for instructions.

  5. Additionally, you will need to open firewall ports for SMB (server message block) communications which uses ports 135-139 and port 445, and you will need to open File and Printer Sharing. As an alternative, you can disable the Windows firewall temporarily until the push installations are complete.

  6. Windows Management Instrumentation (WMI) - SyncSafe Replication is dependent on the WMI service. If you do not use this service in your environment, contact technical support.

  7. SyncSafe Replication Version - You must have the same SyncSafe Replication version on the source and target in order to perform a restoration.

  8. Snapshots - Support for SyncSafe Replication snapshots for files and folders jobs is limited. You can take snapshots, however you cannot failover to a snapshot. The snapshots can be accessed and reverted on the target manually using VSS tools and utilities. Additionally,snapshots are not supported if your source and/or target is a cluster. SyncSafe Replication uses the Microsoft Volume Shadow Copy service (VSS) for snapshot capabilities. To use this functionality, your servers must meet the following requirements:
    1. Snapshot Location - Snapshots are taken at the volume level and stored on the target. For example, if your job is protecting D:\data and E:\files, the snapshot will contain all of the data on both the D: and E: volumes. If your job is only protecting D:\data (E:\files exists but is not included in the job), the snapshot will only contain the D: volume. Make sure you have enough space on your target for snapshots.
    2. SyncSafe Replication Installation Location - In order to enable SyncSafe Replication snapshots, SyncSafe Replication must be installed on the system drive. If SyncSafe Replication is not installed on the system drive, snapshots will be disabled when enabling protection.
    3. Server IP Address - If you have specified an IP address as the source server name, but that IP address is not the server's primary IP address, you will have issues with snapshot functionality. If you need to use snapshots, use the source's primary IP address or its name.
    4. Snapshot Limitations:
      1. Sometimes taking a snapshot may not be possible. For example, there may not be enough disk space to create and store the snapshot, or maybe the target is too low on memory. If a snapshot fails, an Event message and a SyncSafe Replication log message are both created and logged.
      2. There are also limitations imposed by Microsoft Volume Shadow Copy that impact SyncSafe Replication snapshots. For example, different SyncSafe Replication job types create different snapshot types, either client-accessible or non-client-accessible. VSS only maintains 64 client-accessible snapshots, while it maintains 512 non-client-accessible snapshots. If the maximum number of snapshots exists and another one is taken, the oldest snapshot is deleted to make room for the new one.
      3. Another example is that SyncSafe Replication snapshots must be created within one minute because Volume Shadow Copy snapshots must be created within one minute. If it takes longer than one minute to create the snapshot, the snapshot will be considered a failure.
      4. You must also keep in mind that if you are using extended functionality provided by Volume Shadow Copy, you need to be aware of the impacts that functionality may have Chapter 5 Files and folders protection 86 on SyncSafe Replication. For example, if you change the location where the shadow copies are stored and an error occurs, it may appear to be a SyncSafe Replication error when it is in fact a Volume Shadow Copy error. Be sure and review any events created by the VolSnap driver and check your Volume Shadow Copy documentation for details.
      5. You can use Volume Shadow Copy for other uses outside SyncSafe Replication, for example Microsoft Backup uses it. Keep in mind though that the driver for Volume Shadow Copy is started before the driver for SyncSafe Replication. Therefore, if you use snapshots on your source and you revert any files on the source that are protected by your job, SyncSafe Replication will not be aware of the revert and the file change will not be replicated to the target. The file change will be mirrored to the target during the next mirroring process.
      6. Volume Shadow Copy snapshots are associated with the volume they belong to. Since SyncSafe Replication mirrors and replicates the data on the volume and not the volume itself, snapshots taken on the source cannot be used on the target's volume. Therefore, snapshots taken on the source are not mirrored or replicated to the target.
  9. Clusters - If you are using a cluster, make sure your cluster meets the following requirements:
    1. Best Practices - You should carefully review Microsoft documentation and resources for properly configuring your cluster before implementing SyncSafe Replication on a cluster. There are many resources available on the Microsoft TechNet web site.
    2. Networking - The following networking requirements apply to your cluster.
    3. You must have TCP/IP connections between nodes.
    4. Multiple networks are recommended to isolate public and private traffic.
    5. The private network should be a unique subnet so that SyncSafe Replication will not attempt to use an unreachable private network.
  10. Your network can contain direct LAN connections or VLAN technology.
  11. The source cluster IP must be accessible from the target.
  12. Domain - The cluster nodes must be members of the same domain.
  13. DNS - Forward and reverse lookups must be implemented on the primary DNS server for the cluster name and individual nodes.
  14. SyncSafe Replication Disk Queue - Ensure that the disk queue is not on a Physical Disk resource.
  15. Volumes - The source and target should have identical drive mappings.
  16. Owning Nodes - In a cluster configuration, if you add a possible owning node to the protected network name after a job has started, you must stop and restart the job. If you do not, the records for the new node will not be locked. This could cause problems with DNS records if the source cluster nodes are rebooted or the resources are otherwise cycled on the new owning node.
  17. Licensing - Each node in the cluster must have a valid SyncSafe Replication license key.
  18. Resource Registration - In some cases, the SyncSafe Replication cluster resources may not be registered automatically when SyncSafe Replication is installed. You can manually register the resources by running DTResUtility.exe, which is installed in the \Windows\Cluster directory.
  19. Third-party storage - Third-party storage resources are not supported.
  20. If you are using a Cluster Shared Volume (CSV), you cannot protect any data, including a virtual machine, residing on the CSV. If you want to protect a CSV virtual machine, you must run SyncSafe Replication from within the guest operating system of the virtual machine and create the job within the guest. Data can be written to a target CSV.

Requirements for Full Server Protection

These are the requirements for full server protection. Keep in mind that a target server may meet these requirements but may not be suitable to stand-in for a source in the event of a source failure. See Target Compatibility List at the end of this section for additional information regarding an appropriate target server for your particular source.

  • Operating system—The following operating systems are supported for full server jobs.
    • Windows 2022 and Server Core 2022
    • Windows 2019 and Server Core 2019
    • Windows 2016 and Server Core 2016
    • Windows 2012 R2 and Server Core 2012 R2

Warning

Windows 2022, 2019, and 2016 support are for primary Operating System features. Secondary Operating System features specific to these newer Windows versions, such as Nano Server, Windows Containers, and so on, are not supported.

Warning

DNS updates are not supported for Server Core servers.

  1. Operating System Language - Your servers must be running the same Windows localized version. For example, if your source is running an English language version of Windows, your target must also be running an English language version of Windows. If your source is running a Japanese language version of Windows, your target must also be running a Japanese language version of Windows. This applies to all localized languages.

  2. Boot Mode - The boot mode can be EFI/UEFI or BIOS.

  3. Source and target preparation:

    1. Uninstall any applications or operating system features that are not needed from both your source and target. For example, unused language packs will slow down failover since there are thousands of extra files that need to be examined.
    2. Ideally, your target should be as clean and simple a configuration as possible. During failover, SyncSafe Replication cannot add protocol stacks and specific installations to a target that does not already have them. For example, VPN stacks, communication stacks, and services such as Microsoft RRAS (Routing and Remote Access Service) must be pre-installed on the target.

  4. File System - SyncSafe Replication supports the NTFS file system. On Windows 2016 and later, ReFS is also supported. FAT and FAT32 are not supported.

  5. Microsoft .NET Framework - Microsoft .NET Framework version 4.8 or later is required on the source and target.
  6. System memory - The minimum system memory on each server is 1 GB.
  7. Disk Space For Program Files - This is the amount of disk space needed for the SyncSafe Replication program files.
  8. Source Storage - If you will be enabling reverse protection, the source must have enough space to store, process, and apply the target's system state data. See the disk space requirements in the Target Compatibility section for details on the space requirements for various operating systems.
  9. Server Name - SyncSafe Replication includes Unicode file system support, but your server name must still be in ASCII format. Additionally, all SyncSafe Replication servers must have a unique server name.
  10. Time - The clock on your SyncSafe Replication servers must be within a few minutes of each other, relative to UTC. Large time skews (more than five minutes) will cause SyncSafe Replication errors.

Networking

  1. Protocols and Networking - Your servers must meet the following protocol and networking requirements.
    1. Your servers must have TCP/IP with static IP addressing.
    2. Only IPv4 Addresses are supported in the US Signal Environment.
    3. If you are using SyncSafe Replication over a WAN and do not have DNS name resolution, you will need to add the host names to the local hosts file on each server running SyncSafe Replication.
    4. If your source or target server only supports DHCP, for example Windows Azure, keep in mind the following caveats:
    5. You will be unable to utilize reverse protection functionality.
    6. A target reboot may or may not cause a job error depending on if a new address is assigned by DHCP.
    7. Do not disable the DHCP client service on the source. Otherwise, when failover occurs the DHCP client will not start and an IP address cannot be assigned.
  2. Network Adapters - Microsoft NIC teaming for Windows 2012 is supported, however no third party NIC teaming solutions are supported.
  3. NAT Support - SyncSafe Replication supports IP and port forwarding in NAT environments with the following caveats:
    1. Only IPv4 is supported.
    2. Only standalone servers are supported.
    3. Make sure you have added your server to the SyncSafe Replication Console using the correct public or private IP address. The name or IP address you use to add a server to the console is dependent on where you are running the console. Specify the private IP address of any servers on the same side of the router as the console. Specify the public IP address of any servers on the other side of the router as the console.
  4. DNS failover and updates will depend on your configuration:
    1. Only the source or target can be behind a router, not both.
    2. The DNS server must be routable from the target.
  5. Reverse Lookup Zone - If you are using a DNS reverse lookup zone, then it must be Active Directory integrated. SyncSafe Replication is unable to determine if this integration exists and therefore cannot warn you during job creation if it doesn't exist.
  6. DNS - You can failover Microsoft DNS records so the source server name resolves to the target IP addresses at failover time. To be able to set up and failover Microsoft DNS records, your environment must meet the following requirements:
  7. The source and target servers must be in the same domain.
  8. The target must have WMI/DCOM connectivity to any DNS server that you have configured to be updated.
  9. Each server's network adapter must have the DNS suffix defined, and the primary DNS suffix must be the same on the source and target. You can set the DNS suffix in the network adapters advanced TCP/IP settings or you can set the DNS suffix on the computer name. See the documentation for your specific operating system for details on configuring the DNS suffix.

  10. If you are using a DNS reverse lookup zone , then the forward zone must be Active Directory integrated. SyncSafe Replication is unable to determine if this integration exist sand therefore cannot warn you during job creation if it doesn't exist. The zone should be set for secure only updates to allow for DNS record locking.

  11. If your servers are joined to a domain, for example CompanyABC.com, but the DNS domain is different, for example CompanyXYZ.com, you may have issues creating a job and will need to make a manual modification to the job after it has started.

Windows Server Requirements

  1. Windows Firewall - If you have Windows firewall enabled on your servers, there are two requirements for the Windows firewall configuration.

  2. The SyncSafe Replication installation program will automatically attempt to configure ports 6320, 6325, and 6326 for SyncSafe Replication. If you cancel this step, you will have to configure the ports manually.

  3. If you are using the SyncSafe Replication Console to push installations out to your Windows servers, you will have to open firewall ports for WMI (Windows Management Instrumentation), which uses RPC (Remote Procedure Call). By default, RPC will use ports at random above 1024, and these ports must be open on your firewall. RPC ports can be configured to a specific range by specific registry changes and a reboot. See the Microsoft Knowledge Base article 154596 for instructions. Additionally, you will need to Chapter 5 Files and folders protection 85 open firewall ports for SMB (server message block) communications which uses ports 135-139 and port 445, and you will need to open File and Printer Sharing. As an alternative, you can disable the Windows firewall temporarily until the push installations are complete.

  4. Windows Management Instrumentation (WMI) - SyncSafe Replication is dependent on the WMI service. If you do not use this service in your environment, contact technical support.

  5. SyncSafe Replication Version - You must have the same SyncSafe Replication version on the source and target in order to perform a restoration.

  6. Snapshots - Support for SyncSafe Replication snapshots for files and folders jobs is limited. You can take snapshots, however you cannot failover to a snapshot. The snapshots can be accessed and reverted on the target manually using VSS tools and utilities. Additionally,snapshots are not supported if your source and/or target is a cluster. SyncSafe Replication uses the Microsoft Volume Shadow Copy service (VSS) for snapshot capabilities. To use this functionality, your servers must meet the following requirements:

  7. Snapshot Location - Snapshots are taken at the volume level and stored on the target. For example, if your job is protecting D:\data and E:\files, the snapshot will contain all of the data on both the D: and E: volumes. If your job is only protecting D:\data (E:\files exists but is not included in the job), the snapshot will only contain the D: volume. Make sure you have enough space on your target for snapshots.
  8. SyncSafe Replication Installation Location - In order to enable SyncSafe Replication snapshots, SyncSafe Replication must be installed on the system drive. If SyncSafe Replication is not installed on the system drive, snapshots will be disabled when enabling protection.
  9. Server IP Address - If you have specified an IP address as the source server name, but that IP address is not the server's primary IP address, you will have issues with snapshot functionality. If you need to use snapshots, use the source's primary IP address or its name.
  10. Snapshot Limitations:
    1. Sometimes taking a snapshot may not be possible. For example, there may not be enough disk space to create and store the snapshot, or maybe the target is too low on memory. If a snapshot fails, an Event message and a SyncSafe Replication log message are both created and logged.
    2. There are also limitations imposed by Microsoft Volume Shadow Copy that impact SyncSafe Replication snapshots. For example, different SyncSafe Replication job types create different snapshot types, either client-accessible or non-client-accessible. VSS only maintains 64 client-accessible snapshots, while it maintains 512 non-client-accessible snapshots. If the maximum number of snapshots exists and another one is taken, the oldest snapshot is deleted to make room for the new one.
    3. Another example is that SyncSafe Replication snapshots must be created within one minute because Volume Shadow Copy snapshots must be created within one minute. If it takes longer than one minute to create the snapshot, the snapshot will be considered a failure.
    4. You must also keep in mind that if you are using extended functionality provided by Volume Shadow Copy, you need to be aware of the impacts that functionality may have Chapter 5 Files and folders protection 86 on SyncSafe Replication. For example, if you change the location where the shadow copies are stored and an error occurs, it may appear to be a SyncSafe Replication error when it is in fact a Volume Shadow Copy error. Be sure and review any events created by the VolSnap driver and check your Volume Shadow Copy documentation for details.
    5. You can use Volume Shadow Copy for other uses outside SyncSafe Replication, for example Microsoft Backup uses it. Keep in mind though that the driver for Volume Shadow Copy is started before the driver for SyncSafe Replication. Therefore, if you use snapshots on your source and you revert any files on the source that are protected by your job, SyncSafe Replication will not be aware of the revert and the file change will not be replicated to the target. The file change will be mirrored to the target during the next mirroring process.
    6. Volume Shadow Copy snapshots are associated with the volume they belong to. Since SyncSafe Replication mirrors and replicates the data on the volume and not the volume itself, snapshots taken on the source cannot be used on the target's volume. Therefore, snapshots taken on the source are not mirrored or replicated to the target.
  11. Clusters - If you are using a cluster, make sure your cluster meets the following requirements:
  12. Best Practices - You should carefully review Microsoft documentation and resources for properly configuring your cluster before implementing SyncSafe Replication on a cluster. There are many resources available on the Microsoft TechNet web site.
  13. Networking - The following networking requirements apply to your cluster.
  14. You must have TCP/IP connections between nodes.
  15. Multiple networks are recommended to isolate public and private traffic.
  16. The private network should be a unique subnet so that SyncSafe Replication will not attempt to use an unreachable private network.
  17. Your network can contain direct LAN connections or VLAN technology.
  18. The source cluster IP must be accessible from the target.
  19. Domain - The cluster nodes must be members of the same domain.
  20. DNS - Forward and reverse lookups must be implemented on the primary DNS server for the cluster name and individual nodes.
  21. SyncSafe Replication Disk Queue - Ensure that the disk queue is not on a Physical Disk resource.
  22. Volumes - The source and target should have identical drive mappings.
  23. Owning Nodes - In a cluster configuration, if you add a possible owning node to the protected network name after a job has started, you must stop and restart the job. If you do not, the records for the new node will not be locked. This could cause problems with DNS records if the source cluster nodes are rebooted or the resources are otherwise cycled on the new owning node.
  24. Licensing - Each node in the cluster must have a valid SyncSafe Replication license key.
  25. Resource Registration - In some cases, the SyncSafe Replication cluster resources may not be registered automatically when SyncSafe Replication is installed. You can manually register the resources by running DTResUtility.exe, which is installed in the \Windows\Cluster directory.
  26. Third-party storage - Third-party storage resources are not supported.
  27. If you are using a Cluster Shared Volume (CSV), you cannot protect any data, including a virtual machine, residing on the CSV. If you want to protect a CSV virtual machine, you must run SyncSafe Replication from within the guest operating system of the virtual machine and create the job within the guest. Data can be written to a target CSV.

Warning

Only the following types of configurations are compatible with Full Server protection jobs:

  1. One To One - Active/Standby
  2. One To Many
  3. Standlone to Standalone

Other configuration types may only be used with File and Folder replication protection jobs.

Target Compatibility

This section describes the Target Compatibility requirements for Full System Replication jobs. Please review these carefully prior to implementing system for Full Server Protection.

  1. Operating System Version - The source and target must have the same operating system. For example, you cannot have Windows 2016 on the source and Windows 2012 on the target. The two servers do not have to have the same level of service pack or hotfix. The Windows edition (Standard, Enterprise, and so on) does not have to be the same.

  2. Operating System Language - Your servers must be running the same Windows localized version. For example, if your source is running an English language version of Windows, your target must also be running an English language version of Windows. If your source is running a Japanese language version of Windows, your target must also be running a Japanese language version of Windows. This applies to all localized languages.

  3. Source And Target Preparation - Uninstall any applications or operating system features that are not needed from both your source and target. For example, unused language packs will slow down failover since there are thousands of extra files that need to be examined. Ideally, your target should be as clean and simple a configuration as possible.

  4. During failover, SyncSafe Replication cannot add protocol stacks and specific installations to a target that does not already have them. For example, VPN stacks, communication stacks, and services such as Microsoft RRAS (Routing and Remote Access Service) must be pre-installed on the target.

  5. Windows Azure - Because Windows Azure uses remote desktop (RDP) for console connections to virtual machines running on Azure, if your target is running on Windows Azure, you must have remote desktop enabled on the source or the target will be inaccessible after failover. Also because Windows Azure only supports DHCP, you will be unable to reverse a full server job.

  6. Server Role - The target cannot be a domain controller. Ideally, the target should not host any functionality (file server, application server, and so on) because the functionality will be removed when failover occurs.

  7. If your source is a domain controller, it will start in a non-authoritative restore mode after failover. This means that if the source was communicating with other domain controllers before failover, it will require one of those domain controllers to be reachable after failover so it can request updates. If this communication is not available, the domain controller will not function after failover. If the source is the only domain controller, this is not an issue. Additionally, if your source is a domain controller, you will not be able to reverse protection.

    Note

    It is best practice to use multiple redundant domain controllers with native Active Directory replication and a Pilot Light Domain Controller in diverse locations to protect active directory systems. This allows normal replication and Microsoft recommended steps regarding the movement of FSMO roles in a domain during an event. Replicating and failing over Active Directory servers through third party tools is not recommended.

  8. Processors - There are no limits on the number or speed of the processors, but the source and the target should have at least the same number of processors. If the target has fewer processors or slower speeds than the source, there will be performance impacts for the users after failover.

  9. Memory - The target memory should be within 25% (plus or minus) of the source. If the target has much less memory than the source, there will be performance impacts for the users after failover.
  10. Network Adapters - You must map at least one NIC from the source to one NIC on the target. If you have NICs on the source that are not being used, it is best to disable them. If the source has more NICs than the target, some of the source NICs will not be mapped to the target. Therefore, the IP addresses associated with those NICs will not be available after failover. If there are more NICs on the target than the source, the additional NICs will still be available after failover and will retain their pre-failover network settings.
  11. File System Format - The source and the target must have the same NTFS or ReFS file system format on each server. FAT and FAT32 are not supported.
  12. Logical Volumes - There are no limits to the number of logical volumes, although you are bound by operating system limits. For each volume you are protecting on the source, the target must have a matching volume. For example, if you are protecting drives C: and D: on the source, the target cannot have drives D: and E:. In this case, the target must also have drives C: and D:. Additional target volumes are preserved and available after failover with all data still accessible. You will be unable to reverse protection if the target has more drives than the source.
  13. System Path - The source and the target must have the same system path. The system path includes the location of the Windows files, Program Files, and Documents and Settings.
  14. SyncSafe Replication Version - If you will be using the reverse feature with your full server job, your source and target must be running the same SyncSafe Replication version.
  15. Disk Space - The target must have enough space to store the data from the source. This amount of disk space will depend on the applications and data files you are protecting. The more data you are protecting, the more disk space you will need. The target must also have enough space to store, process, and apply the source's system state data. If you will be enabling reverse protection, the source must have enough space to store, process, and apply the target's system state data. In either case, the size of the system state will depend on the operating system and architecture.
  16. A copy of the source system state data will be staged on the target boot volume in a folder called Staging-SSM. For reverse protection, the target system state will be staged on the source boot volume also in a folder called Staging-SSM. You can predict (approximately) how much space you will need in this staging folder by calculating the size of the following folders on your boot volume:
    1. Documents and Settings
    2. Program Files
    3. Program Files (x86)
    4. Program Data
    5. Windows
    6. Users
    7. Any other folders you manually select for staging.
  17. If the target's boot volume does not have enough space to accommodate the source data and the staging folder, the job will become stuck in a retrying state and will be unable to complete synchronization. You should also have approximately 2-3 GB or more additional space on the target boot volume (beyond your calculation above) to ensure there is enough space for failover processing.
  18. The following are rough estimates for the free space needed for the staging folder for different operating systems:
    1. Windows 2012 R2—at least 15 GB
    2. Windows 2016—at least 25 GB
    3. Windows 2019—at least 23 GB
    4. Windows 2022—at least 26 GB
  19. These minimums are for a clean operating system installation. Operating system customizations, installed applications, and user data will increase the disk space requirement.
  20. Antivirus/EDR Software - Review with your Antivirus/EDR Software Vendor whether there are any compatibility concerns or potential issues with performing a Full System Replication and Restore function.