This article describes the local and off-site networking requirements and best practices for Datto Business Continuity & Disaster Recovery (BCDR) appliances and the Datto Cloud Continuity for PCs solution.
- Datto SIRIS
- Datto ALTO
- Datto NAS
- Datto Cloud Continuity for PCs
- Network link speed requirements
- Network architecture considerations
- WAN uplink considerations
- Network MTU considerations
- Port access and IP whitelist requirements
- Internet access requirements for protected machines
- Virtual SIRIS considerations
- Additional Resources
Network link speed requirements
A 100 Mbps network cannot efficiently transfer large datasets between the protected machines and a Datto appliance. You must have a gigabit network connection between all protected machines and the Datto appliance over your LAN.
Datto strongly recommends placing the Datto appliance and all protected machines on the same LAN. If you must set up backups over a WAN, you will need a 50 Mbps dedicated uplink for every terabyte of protected data. Otherwise, backups will not be reliable. Even if you meet this requirement, the latency between endpoints will significantly decrease backup throughput. The higher the latency, the lower the performance.
Any device function performed through a site to site VPN/MPLS will be subject to degraded performance.
Network architecture considerations
Datto expects that you will deploy BDR appliances in a secure LAN environment. Inbound access from untrusted WAN hosts should be blocked at the edge of the network (via the router/firewall) to limit the accessibility of appliance network daemons and services. For more information, see Secure Deployment Best Practices For Datto Appliances.
WAN uplink considerations
To reliably synchronize with the Datto Cloud, ensure that your connection is at least 1 Mbps (125 KBps) uplink per terabyte of protected data stored locally on the Datto device. To check how much data your Datto appliance is currently protecting, see this article.
For every 1 Mbps of upload capacity that you dedicate to off-site traffic, you will be able to upload approximately 10 GB of change per day.
- 2 Mbps of upload capacity would net approximately 20 GB of change uploaded per day.
- 10 Mbps of upload capacity would net approximately 100 GB of change uploaded per day.
- 100 Mbps of upload capacity would net approximately 1 TB of change uploaded per day.
Offsiting 1 TB of change over a 1 Mbps uplink will take approximately 100 days. For images this large, Datto recommends using the RoundTrip service to send the original base image offsite.
Network MTU considerations
The Datto appliance will most reliably communicate with our monitoring servers when you set the router's MTU size to 1500 bytes. Since the Datto appliance is also using a 1500 byte MTU size, this will prevent packet fragmentation, which can cause issues with communication to our monitoring servers.
Port access and IP whitelist requirements
Ports 25566 and 25568 (listed as 6001-47000 when WinNAT is enabled) must be open.
Depending on your network security configuration, you may need to whitelist python.map.fastly.net for optimal device communication.
Additional port access requirements will vary, depending on the type of agent deployed. See the following resources for more information.
For networking requirements specific to Datto's various agent and agentless backup solutions, see the following articles:
- Getting started with the Datto Windows Agent
- Getting started with the ShadowSnap Agent
- Getting started with the Datto Linux Agent
- Getting started with the Datto Mac Agent
- Getting started with agentless backups
Internet access requirements for protected machines
- The Datto appliance must have access to the Datto Cloud for backup replication and remote device management. Also, all ICMP packets must be allowed through the firewall.
- Datto recommends disabling any application-layer filtering of traffic destined for or originating from your Datto appliance.
For device management, to synchronize time, and to download operating system updates, all backup appliances must be able to resolve the following Datto sites in the local DNS:
For operating system maintenance, the Datto appliance must also be able to resolve the following community sites in the local DNS:
- ntp.ubuntu.com - Ubuntu managed Network Time Portal server, used to synchronize time
- us.archive.ubuntu.com - Ubuntu managed application repository
- security.ubuntu.com - Ubuntu managed application repository
- ppa.launchpad.net - Ubuntu managed application repository
All Datto appliances must have outbound access the following IP ranges for Cloud infrastructure, DNS failback, and device management:
|18.104.22.168||443||TCP||Image / package server|
|22.214.171.124/24||443 and 80||TCP||Device Web|
|80, 2200, and 443||TCP||Device Web and cloud storage|
The Datto appliance must have outbound access to port 22 (TCP) for data synchronization and port 1194 (TCP) for hybrid virtualizations, as well as VPN tunneling and off-site storage. Depending on your country, the Datto appliance will require outbound access to the following IP address ranges:
- 126.96.36.199/23 (Pennsylvania)
- 188.8.131.52/24 (Pennsylvania)
- 184.108.40.206/24 (Pennsylvania)
- 220.127.116.11/24 (Pennsylvania)
- 18.104.22.168/24 (Pennsylvania)
- 22.214.171.124/24 (Pennsylvania)
- 126.96.36.199/24 (Pennsylvania)
- 188.8.131.52/24 (Pennsylvania)
- 184.108.40.206/24 (Pennsylvania)
- 220.127.116.11/23 (Pennsylvania)
- 18.104.22.168/24 (Utah)
- 22.214.171.124/24 (Utah)
- 126.96.36.199/23 (Utah)
- 188.8.131.52/24 (Utah)
- 184.108.40.206/24 (Toronto)
- 220.127.116.11/24 (Calgary)
- 18.104.22.168/24 (Toronto)
- 22.214.171.124/24 (UK)
- 126.96.36.199/24 (Iceland)
- 188.8.131.52/24 (Germany)
- 184.108.40.206/24 (Germany)
- 220.127.116.11/24 (Germany)
ANZ (Australia and New Zealand)
- 18.104.22.168/24 (Sydney, Australia)
- 22.214.171.124/24 (Melbourne, Australia)
To learn which Cloud storage node your Datto device uses, open the backup appliance's GUI. On the Overview screen, you will see replication information similar to the example shown in Figure 1.
Virtual SIRIS considerations
When performing an off-site hybrid virtualization on a virtual device bridged to your local network, ensure you have enabled promiscuous mode and forged transmits on the port group or virtual switch to which the vSIRIS is connected.