How to set up a passive-active failover between two NAS units
A passive-active NAS arrangement keeps one storage system serving users while a second unit maintains a synchronised copy in standby. If the primary NAS fails, the standby can be promoted, allowing file shares, applications, and selected services to return with less interruption than a restore from backup.
This design suits a small business, studio, medical practice, or home office where downtime is costly but a full enterprise cluster is out of reach. It can be built with Synology, QNAP, or other NAS hardware, although the exact high-availability features depend on the model, operating system, storage layout, and licensing.
The key distinction is between replication and failover. Replication copies data to another NAS; failover changes where users connect. A reliable design needs both, along with a clear method for preventing the two units from accepting changes at the same time.
Australian conditions make planning especially important. A short NBN outage in a suburban Melbourne office, a power event during a Brisbane storm, or a long drive to a regional site can turn a minor storage fault into a serious interruption. The standby NAS should therefore be tested locally and managed with a practical recovery runbook.
What passive-active operation means
In normal operation, the active NAS owns the production shares and responds to SMB, NFS, iSCSI, or application requests. The passive NAS receives replicated data but does not present the same production services to users. Keeping the standby quiet reduces the risk of conflicting edits and makes ownership clear.
When the active unit becomes unavailable, an administrator or high-availability system promotes the passive unit. This may involve assigning a virtual IP address, moving a DNS record, starting shared folders, enabling applications, and reconnecting clients. Some vendor systems automate these actions, while a basic two-NAS arrangement may use a documented manual process.
A failover is not a substitute for backup. If ransomware encrypts files on the active NAS and the change is replicated immediately, the encrypted files may reach the standby. Use snapshots, an offline copy, cloud storage, or removable media as a separate recovery layer.
Check hardware and software compatibility
Start by confirming that both NAS units support the same replication and high-availability method. Synology High Availability generally expects compatible models with matching system versions and suitable network connections. QNAP offers different approaches across QTS and QuTS hero, so features such as shared storage, snapshot replication, and service migration should be checked against the exact models.
Ideally, the systems should have similar processors, memory, drive capacity, RAID protection, and network interfaces. They do not always need to be identical, but a much slower standby can become a bottleneck during resynchronisation or failover. Matching drive sizes also avoids awkward capacity limits.
Use supported drives where possible, particularly in a business environment. A two-bay consumer NAS may replicate files well but lack the cluster controls required for automatic service failover. Read the current vendor compatibility list rather than assuming that two units from the same product family can form a high-availability pair.
Prepare the network and storage path
Give both units stable management addresses and reserve a separate virtual IP for the production services. If the NAS systems support link aggregation, that can improve resilience, but it does not replace a reliable switch, UPS, or independent network path. A dedicated replication link is valuable when large datasets or frequent snapshots could compete with user traffic.
Keep the NAS units on the same low-latency LAN where possible. A pair split between Sydney and Perth may protect against a site outage, but ordinary synchronous-style failover is unsuitable across a high-latency connection. For a remote standby, use asynchronous replication and plan for some recovery point loss.
Before configuring anything, complete these checks:
- Install matching or compatible NAS operating system versions and firmware.
- Place both units behind a UPS and test safe shutdown behaviour.
- Confirm that the switch supports the required VLANs, jumbo frames, and failover addresses.
- Synchronise time with a dependable Australian or global NTP service.
- Record administrator access, encryption keys, licence details, and recovery contacts.
Configure replication before switching services
Create the storage pools and shared folders on the standby NAS before copying production data. Snapshot replication is usually preferable to a simple scheduled file copy because it can preserve point-in-time versions, permissions, and changes more efficiently. Configure a sensible retention policy so the destination does not fill unexpectedly.
Start with a full baseline replication while users are working as little as possible. After it completes, monitor the replication queue and check that permissions, file ownership, extended attributes, and application data are preserved. Database-backed services often require vendor-supported replication rather than copying their files while they are running.
For Mac environments, NAS storage can also act as a Time Machine destination, but the backup share needs correct quotas and access permissions. The guidance on Time Machine target setup is useful when adding Apple laptops to the wider protection plan. Treat those backups as another recovery source, not as a replacement for NAS replication.
Set replication intervals according to the business requirement. A fifteen-minute schedule may be adequate for office documents, while a media production team could need more frequent snapshots and a faster 10GbE connection. Measure the actual recovery point objective rather than selecting a frequency by guesswork.
Define failover triggers and safeguards
Automatic failover sounds attractive, but an incorrect decision can cause split-brain operation. If both NAS units believe they are active, users may write different versions of the same files. Reconciliation can be difficult or impossible, especially for databases and virtual machine storage.
Use a witness, quorum mechanism, or vendor-supported cluster service where available. If the platform cannot determine whether the peer is genuinely offline, manual approval is safer. The operator should first isolate or power down the failed primary, then promote the standby.
Document exactly what counts as a failover event:
- Hardware failure, storage pool failure, or an unresponsive operating system.
- Extended network loss confirmed from an independent device.
- Power, cooling, or site damage that makes the primary unsafe to run.
- A planned maintenance window requiring service migration.
- Replication corruption, ransomware, or a bad update that requires rollback instead.
A good runbook includes the order of actions, expected warnings, user communication, and the person authorised to approve promotion. In a small Perth consultancy, that may be the owner and one IT provider; in a larger Melbourne office, it may involve a service desk and infrastructure team.
Move client access cleanly
Users should connect through a stable name rather than the primary NAS hostname. A DNS alias such as files.example.local, a virtual IP, or a vendor-managed cluster address allows the backend unit to change without requiring every workstation to be reconfigured. Test how Windows, macOS, Linux, mobile apps, and mapped drives handle the transition.
Not every service will follow the file shares automatically. Check print services, Plex or Jellyfin libraries, Docker containers, surveillance recording, virtual machines, LDAP integration, and cloud-sync jobs individually. Applications may store the NAS hostname, IP address, certificate name, or local database path in their configuration.
A controlled failover should follow a repeatable sequence:
- Announce a short maintenance window and stop active file or database writes.
- Confirm the latest replication status and record the last usable snapshot.
- Isolate the primary or confirm that the cluster has fenced it.
- Promote the standby and attach the production IP address or DNS name.
- Test representative files, permissions, applications, and remote access.
Keep the old primary offline until its cause is understood. Rebuilding it as the new passive unit is often safer than immediately allowing it to rejoin and overwrite newer data.
Test recovery and measure the result
Run a planned failover at least twice a year, and after major firmware, network, or storage changes. Include a test during the sort of conditions that affect the site: UPS operation, switch restart, internet loss, and a full power cycle. An office in Adelaide should know how local staff work if cloud authentication or remote support is temporarily unavailable.
Measure the time from declaring an incident to restoring normal user access. Also record the latest replicated snapshot, missing files, application downtime, and any manual repairs. These measurements reveal whether the arrangement meets its recovery time objective and recovery point objective.
| Approach | Recovery speed | Administration | Main risk | Suitable use |
|---|---|---|---|---|
| Manual standby promotion | Minutes to hours | Simple, runbook-led | Human error or forgotten steps | Home office and small business |
| Vendor high-availability pair | Usually fastest | More structured | Model and licensing limits | Critical file services |
| Scheduled file replication | Variable | Straightforward | Incomplete application state | Secondary copy and archives |
| Snapshot replication | Fast point-in-time recovery | Moderate | Replicated corruption | Business files and shared folders |
| Off-site asynchronous replica | Depends on link and distance | More involved | Data lag during an outage | Site disaster protection |
Document the result in plain language. Avoid a runbook that only an installer can understand, particularly when the installer may be unavailable during an incident. Include screenshots, IP addresses, service names, backup locations, and the exact command or menu used to reverse the failover.
Keep the arrangement secure and maintainable
Protect replication traffic with a dedicated VLAN or trusted network segment, strong administrator authentication, and encrypted connections where supported. Do not expose NAS management interfaces directly to the internet. Restrict remote access through a properly configured VPN and review administrator logs regularly.
Apply updates to the passive NAS first when the vendor supports that sequence. Watch replication health after every change, and verify that snapshots are completing rather than assuming a green dashboard means the data is recoverable. Replace failing disks promptly, but allow the array and replica to resynchronise before performing another disruptive task.
A practical Australian setup may combine a primary NAS in a Sydney office, a nearby passive unit, and encrypted cloud or off-site backups for bushfire, flood, theft, and building loss. That layered approach costs more than two boxes on a shelf, but it protects against different failure types instead of treating every incident as a simple disk failure.
Build the pair, test a controlled promotion, and keep the recovery notes beside your backup records. A properly maintained passive-active design gives users a clear path back to work while preserving the separate backups needed for accidental deletion, malware, and site-wide disasters.