Home | Contact
whichnas.com

Set Up Snapshot Replication for NAS Disaster Recovery

A NAS can turn storage failure, accidental deletion or ransomware into a long recovery project. Snapshot replication creates a block-level recovery point on the primary system and transfers it to another NAS, giving you a way to restore shared folders after an outage or malicious change.

This guide covers QNAP and Synology setup, network design and restore testing for Australian homes and small organisations. It also explains where snapshot replication fits alongside immutable backups and the local legal and infrastructure realities that affect recovery.

Understand What Snapshot Replication Protects

Snapshot replication and conventional file backup answer different questions. A snapshot records the state of a volume or storage pool at a chosen time, while replication keeps a copy of that state on a second system. Together, they support rapid rollback and failover, but both copies can still be affected by a shared administrator mistake or compromised credentials.

Set two measurable targets. The recovery point objective (RPO) is the acceptable amount of data loss, expressed as time; the recovery time objective (RTO) is the acceptable time to restore service. An hourly task with a one-hour RPO is a reasonable starting point for office documents, while accounting or booking systems may need a shorter interval. These targets should dictate the schedule, retention and network capacity rather than follow the defaults.

Use the 3-2-1 principle as a guide: three copies, two storage types and one copy away from the main location. The Australian Cyber Security Centre recommends isolating important backups from day-to-day systems. Snapshot replication can supply an off-site copy, but it should sit beside a versioned or immutable backup that cannot be deleted through the primary NAS.

Plan the Recovery Path Before Configuring

Choose compatible hardware and reserve enough space. Buy through an Australian supplier with a practical warranty and replacement process, then check the vendor's compatibility list for your QNAP model, operating system, firmware and destination device. A Synology snapshot normally needs a Btrfs shared folder as its source, and the receiving NAS needs suitable Btrfs storage. Allow headroom for changed blocks, retained versions and a temporary restore instead of filling the replica to its advertised capacity.

Plan the network path around Australian connectivity. Many premises use NBN fixed-line services: FTTP provides an Ethernet handoff, while FTTN and HFC use different last-mile infrastructure and can depend on external equipment. A 4G or 5G router can provide a backup path when the primary WAN fails, although mobile coverage and upload speeds are not assured. A home connection may also carry video calls, streaming and cloud backups simultaneously, so schedule replication outside those peaks. A site-to-site VPN over stable broadband is usually preferable to exposing either NAS administration interface to the internet.

Decide how the second site will support the first. For example, a Brisbane replica may add distance from a Melbourne office, but test latency and make sure it is not exposed to the same flood or bushfire risk. Record who can authorise a failover, how access credentials are stored and which services must restart first. Store a printed recovery runbook with the NAS, not only in an account that depends on the failed system.

Configure the Replica on QNAP

On QNAP, update QTS or QuTS hero, confirm the source volume supports snapshots and create a test snapshot before building the remote task. Open Storage & Snapshot or Snapshot Manager, depending on your release, and use the Snapshot Replication workflow to select the source volume and destination NAS, authenticate the remote device, choose the destination repository and define a schedule. Use a dedicated least-privilege service account where the release supports it.

Set a schedule that can survive the available upload speed. For example, retain hourly points for a day, daily points for a week and weekly points for a month, then adjust that policy to match the RPO. Initial transfers can be substantial, while later runs generally move changed blocks. Configure alerts for a missed or failed task, and avoid enabling so many versions on the receiving NAS that routine maintenance creates a storage emergency.

Prepare the network with outbound VPN access, firewall rules and a stable address on each side. Certificates, trusted endpoints and time synchronisation must match; an expired certificate can stop replication even when both NAS units are online. Test the wizard's connectivity check, then restore one replica to a temporary folder and compare sample files, permissions and timestamps before relying on the task.

Configure the Replica on Synology

For Synology, use a DSM release and model that support the required replication functions. On DSM 7.2-capable hardware, prepare a Btrfs shared folder and open Snapshot Replication from the DSM interface. Add the destination Synology NAS, select the source folder and choose incremental replication where available. The destination needs enough capacity for retained versions, and the two devices should run compatible, tested firmware.

Hyper Backup and Snapshot Replication serve different purposes. Hyper Backup can create file-level or application-aware backups with its own retention controls; Snapshot Replication is suited to fast volume-level recovery and, on supported releases, LUN recovery. Use both if your risk assessment requires independent backup copies. Configure the receiving task, network route and schedule, then confirm that health notifications reach a monitored address rather than an unattended personal inbox.

Databases and virtual machines need special attention. A block snapshot taken during heavy writes can be recoverable but not logically consistent, so quiesce the application or use a supported application-aware mechanism. Test restoring the database and checking its integrity, not merely opening a file. Also export DSM configuration and package settings separately, because replicated user data does not recreate every package licence, service setting or firewall rule.

Test Restores and Monitor the System

Run a controlled restore drill. On the replica, select a recent recovery point and restore it to a separate test share or staging location. Check representative documents, photographs, archives and application files, including ownership, sharing permissions and metadata. Practise the full sequence: detect the failure, choose the version, start the service and verify the result. Keep the original volume untouched until the recovered copy has passed its checks.

Monitor task status, free capacity, WAN latency and UPS condition, then review those trends after each firmware update. A healthy dashboard is not evidence of recoverability. Schedule recurring restore tests, including a test during a simulated loss of the primary link, and update the runbook whenever staff, applications or network paths change.

Australian legal duties make recovery evidence especially valuable. The Australian Consumer Law provides consumer guarantees and requires suppliers to honour stated warranties, but a working NAS does not automatically guarantee the recovery of damaged data. For a covered organisation, the Privacy Act 1988 and Australian Privacy Principles may require reasonable security and an assessment of notification duties after a data breach. Keep records of tests, access rights and corrective actions.

Build an Australian Recovery Checklist

Before calling the setup complete, work through the operational checks below and assign an owner to every item.

Infrastructure readiness

Recovery readiness

Run the first restore drill now, then repeat it quarterly and after any major hardware, software or network change. Record the recovery time, confirm the chosen RPO is being met and keep the off-site copy, runbook and responsible contacts ready for the next outage.