Backup Strategy for Corporate Networks: DNS Names vs. IP Addresses

Anyone planning a backup strategy for a corporate network will quickly face a fundamental decision when configuring UNC paths: Should the backup destinations be accessed via their DNS name (e.g. , \\backup-server\share) or directly via the IP address (e.g. , \\100.114.188.7\share)?

From an IT architecture perspective, the answer is clear, but there is an important nuance to consider in the event of an emergency.

The clear favorite: UNC paths with DNS names

In modern corporate networks, the use of Fully Qualified Domain Names (FQDN) or local hostnames is considered the absolute best practice standard. The advantages lie primarily in flexibility and IT security:

• Hardware migrations without downtime: If the backup server crashes or a hardware replacement is due, the new server does not have to laboriously inherit the same IP address. It is sufficient to update the entry in the central DNS server to the new IP. All backup scripts and client applications continue to run immediately without any code changes.
• Compatibility with DHCP: In dynamic networks where IPs are assigned flexibly, the DNS automatically detects IP changes following router reboots.
• Secure authentication: Modern Windows networks rely on the Kerberos protocol for secure authentication. Kerberos requires hostnames. If only IP addresses are used, Windows often falls back on the outdated and less secure NTLM method.

Resolving network drives (Z:) in code: The UNC requirement for automated backups

A common pitfall in practice: A mapped network drive is specified as the destination in the backup script configuration (e.g., Z:\Backup). What works smoothly on the administrator’s PC during testing almost always leads to errors in automated operation.

The reason: Windows manages network drives on a per-user basis. If the backup later runs as a scheduled task or as a system service in the background, this process does not "see" the letter Z: at all.

Automatic UNC Conversion

Professional backup software prohibits the use of drive letters or automatically converts them to actual UNC paths in the background when the backup job is created.

For those using custom backup scripts: Windows API functions (such as WNetGetConnection) can be used in the code to determine the actual network path behind Z:. Z:\Backup is thus automatically converted to the stable and universally valid \\backup-server\share\Backup. Only this conversion ensures that the backup runs without errors, regardless of the logged-in user and their current drive mappings.

In exceptional cases, use the IP address as a "Plan B"

The direct IP address has a single, yet crucial advantage in the event of a disaster: independence.

If the company’s DNS server fails (e.g., due to a cyberattack, a misconfiguration, or a router malfunction), no computer on the network can resolve names anymore. A backup script that only searches for \\backup-server will immediately abort with an error. The direct IP address works even in a completely "blind" network.

Best Practice: The Hybrid Strategy (The Professional Approach)

Don’t rely on just one approach. Professional backup software and well-written scripts use a combination of both:

1. Primary Path (DNS): By default, the system attempts to perform the backup using the DNS name.
2. Automatic Fallback (IP): If DNS resolution fails (e.g., timeout or API error), the script switches to a hard-coded fallback IP in the background within seconds.

Path Cleaning

No matter which method you use: Pay close attention to clean paths. A common error in automated systems or when reading configuration files is the inclusion of special characters.

A path like \\100.114.188.7\backup; (with a trailing semicolon) is not valid in either Windows or Linux and causes network APIs to crash abruptly in many programming languages. Robust pre-cleaning in the code is therefore mandatory.

For daily operations and clean maintenance, there is no way around using DNS names. However, those seeking maximum reliability for the worst-case scenario should implement a DNS query in the code with an automatic, validated fallback to the direct IP address.