This article explains the best practices to follow when configuring self-hosted StorageServers and MirrorServers for connection to the Redstor Storage Platform. The practices are similar to those described for a standalone self-hosted Storage Platform (see Article 1061), and you may be migrating from this configuration to use Redstor’s AccountServers.
Page contents
Public IPs and DNS
Public IPs
Your StorageServers will require public IP addresses so the Redstor AccountServers can connect to them. Connectivity using private IP addresses is not available.
It is also recommended to implement public IP addresses for your MirrorServers, for the following reasons:
- Clients connecting over the internet will be able to restore from the mirror.
- In the event of a failover scenario for your StorageServer, changes can be made to more easily allow backups to continue to the promoted mirror.
Network address translation is supported (see below for details).
DNS
It is strongly recommended to use fully qualified domain names (FQDNs) to identify the StorageServers when connected to the Redstor Storage Platform. Using public IP addresses only is not recommended, as this prevents the effective use of trusted certificates (see below).
There have been some cases where host-file-based name resolution of public IP addresses has been implemented on Redstor’s AccountServers, but this is no longer recommended.
Some Redstor services require the StorageServer to be publicly resolvable – if this is not the case, they will not be able to use the StorageServer, and data cannot be sent to or retrieved from it by the server.
Trusted certificates
It is recommended to install trusted certificates, as described in Article 1511.
If Software-as-a-Service (SaaS) backups are being sent to your StorageServer(s) and you do not have trusted certificates installed, errors may be encountered (including during the restore process), and can prevent the software from operating as expected.
Network configuration
You have two options for network configuration: with network address translation (NAT), and without. These are considered the only valid configurations, and deviations from these are considered problematic, as described below.
Option 1: Private IP address using NAT
If you wish to run your StorageServer(s) using a private IP address within a LAN or DMZ, NAT must be used to make the platform publicly accessible.
The StorageServer also requires DNS names that are resolvable on the public internet, to the public IP of the StorageServer (as described above), and optionally on the private LAN to the private static IP of the appliance.
The separate “private side” DNS resolution can be achieved using a DNS server on your site, or using host file entries on the machines you wish to back up.
This configuration will provide optimal network performance, as backup data for on-site Agents can be sent over the private network and does not need to be sent over the public internet.
If you decide to use a private IP address without a DNS server on site (or without the custom record), the traffic on your private network may have to traverse your gateway router to the internet, only for traffic to return over the same link. This may adversely affect backup performance.
However, from an administrative perspective, not creating the private DNS records may be desirable, as it keeps the environment simpler.
Note: Domain name resolution override can also be achieved using entries in the host file on each on-site Agent, although this requires greater administrative effort.
Option 2: Public IP address without NAT
The alternative to using a private IP address is to configure the Titanium appliance with a public IP address and connect it to your public or DMZ network. No local DNS record or port forwarding would be required in this instance.
Invalid or problematic configurations
- Private IP addresses only (not supported).
- Private name resolution to public IP address (no longer supported).
- Public IP addresses without an FQDN.
- FQDNs without trusted certificates.
Comms testing
For help testing comms between Agents and the Platform, see Article 436.
Was this article helpful?
That’s Great!
Thank you for your feedback
Sorry! We couldn't be helpful
Thank you for your feedback
Feedback sent
We appreciate your effort and will try to fix the article