NAS Backup Best Practices with SyncBack

A NAS is one of the most common destinations our customers use with SyncBackPro. It is fast on a wired LAN, has room to grow, and centralises storage for a household, or small office, in a way that an external USB drive can never match. But a NAS only protects your data as well as the strategy you wrap around it. A box full of disks is not a backup, and choosing the wrong profile type or no versioning at all can leave a NAS owner just as exposed as someone with no backup at all.

This article walks through the practical decisions that make the difference between a NAS that protects you and a NAS that just stores another copy of the same data. It covers profile selection, performance, versioning, ransomware layering, vendor-specific notes, the most common mistakes, and a tour of the NAS misbehaviours SyncBack has accumulated workarounds for over more than twenty years.

A NAS Is Not a Backup

This is the most important section of the article, and the one most often skipped. A NAS improves storage reliability and centralisation, but simply copying files to a NAS does not automatically create a backup. If ransomware encrypts your PC and SyncBack mirrors those changes to the NAS, both copies may be affected. SyncBack's built-in ransomware detection can halt a backup mid-run when it spots a wave of suspicious encryption activity, but no single defence is foolproof and a layered strategy still matters. If a file is accidentally deleted and the deletion is propagated, the NAS copy disappears too.

Three ideas often get conflated and they are not the same thing:

• Replication is not backup. Replication keeps two copies in sync. If something corrupts the source, replication corrupts the destination. A backup, by contrast, captures the state of the source at a point in time and retains it independently.
• RAID is not backup. RAID protects against a single disk failure on the NAS itself. It does not protect against accidental deletion, ransomware, fire, theft or a botched firmware update. See our article RAID is not a backup solution for more on this.
• Availability is not recoverability. A NAS makes data available across the network. Recoverability means being able to restore a known-good copy after something has gone wrong. Those are different problems and they need different solutions.

A NAS is an excellent place to put a backup. It is not, on its own, a backup strategy.

Choosing the Right SyncBack Profile Type

SyncBack offers several profile types, and the wrong choice is one of the most common reasons NAS owners end up disappointed when something goes wrong. The table below summarises when each profile type fits.

For most NAS scenarios the correct choice is Backup with versioning. Mirror feels obvious because the name implies "an identical copy", but the implication is misleading: if a file gets deleted or corrupted on the source, Mirror happily passes that change through to the NAS. Backup with versioning gives you a copy of every recent state, so you can recover a file that was deleted yesterday or corrupted last week.

NAS Performance Considerations

Many users assume a NAS will be as fast as a local drive and are surprised when the first backup takes hours instead of minutes. Two factors usually explain the difference: network throughput, and the cost of touching small files.

Network Speed

The numbers below are realistic real-world throughputs after protocol overhead. Marketing speeds in megabits per second look very different to actual sustained transfers in megabytes per second.

For NAS owners on Wi-Fi, the single biggest performance improvement available is usually plugging the desktop and the NAS into the same switch with Ethernet cables. If the desktop has to stay wireless, schedule the bulk profile for overnight when nothing else is contending for the airwaves.

Small Files vs Large Files

A NAS may transfer a 100 GB movie in under fifteen minutes on gigabit Ethernet and then take several hours to copy half a million small files that add up to a fraction of the size. The reason is that each file carries fixed overhead for the open, write, close and metadata round trips. Small files turn those overheads into the dominant cost.

If a backup is unexpectedly slow, it is almost always because of file count rather than total bytes. A folder of source code, browser cache or email mailboxes can contain hundreds of thousands of tiny files. Where appropriate, packaging such folders into a zip file before the backup runs can produce dramatic speed improvements.

Versioning on a NAS

This is where SyncBack genuinely earns its place on a NAS. Versioning retains older copies of files as they change, so a recent deletion or an unwanted edit is recoverable rather than gone. It is the single feature that turns a NAS copy into something that behaves like a backup rather than a mirror.

Retention should match the value and change rate of the data. The table below offers reasonable starting points.

Versioning is not free in storage terms. Files that change often will produce more versions over time, and the space adds up. For a typical home NAS this is rarely a problem. For a small office backing up large mailboxes or VM images, it is worth doing the arithmetic before settling on a retention period.

NAS Snapshots vs SyncBack Versioning

Many Synology and QNAP users ask whether NAS snapshots replace SyncBack versioning. The honest answer is that they are different tools with different strengths, and many users benefit from running both.

• NAS snapshots capture the entire state of a volume or share at a moment in time. They are extremely fast (often near-instant) because they only record changed blocks. They depend on the NAS supporting snapshots and on storage being configured for them, typically Btrfs on Synology or the snapshot-capable shares on QNAP.
• SyncBack versioning works on any NAS share, regardless of the underlying file system. It is file-level rather than block-level, which makes it portable across vendors and easy to inspect: each version is a real file in a real folder.

A common and sensible combination is to use SyncBack versioning to keep recent file-level history on the NAS, then take occasional snapshots on the NAS itself so that a malicious actor who breaks into a NAS share cannot easily erase your version history. The two layers protect against different failure modes.

Ransomware Protection in Layers

Ransomware is the threat that turns a NAS-only strategy into a regret. If your PC is compromised and the NAS share is mounted, the malware reaches both. A layered approach raises the bar significantly. See our article on ransomware-resilient backups for the full picture; the short version applied to NAS is:

• Better: PC → NAS with SyncBack Backup profile.
• Better still: PC → NAS with versioning enabled.
• Best: PC → NAS + cloud + offline (rotational USB) copy. This is the shape of the 3-2-1-1-0 backup strategy applied to a NAS workflow: three copies, two media types, one offsite, one offline or immutable, zero errors through verification.

A few specific practices that increase NAS resilience:

• Immutable snapshots where the NAS supports them (Synology and QNAP both offer locked snapshots that cannot be deleted before their retention expires).
• A dedicated backup share with its own credentials, separate from the user-facing shares. The malware on the PC is unlikely to have those credentials.
• An offline copy on a rotational external drive that is only connected during the weekly backup window. This is the cheapest air gap available.

Backup Destination Design

A few minutes of folder design saves hours of confusion later. A clean structure also makes it easy to set permissions and snapshot policies per area.

NAS
│
├─ Backups
│   ├─ Desktop-PC
│   ├─ Laptop
│   ├─ Documents
│   └─ Photos
│
├─ Versioning
│   ├─ Desktop-PC
│   └─ Laptop
│
└─ Archive

Putting versioning under its own root makes it trivial to retain it for longer than the live backups, or to take separate snapshots of it. Putting archive (rarely-changing long-term storage) on its own root makes it a candidate for cold storage promotion later.

NAS Quirks SyncBack Already Handles

NAS shares advertise themselves as ordinary Windows drives, but the file system code on the other end of the wire is often a Linux box pretending to be NTFS over SMB. Reality is bumpier than the marketing suggests. Over more than twenty years of customer reports, SyncBack has accumulated workarounds for a wide range of NAS misbehaviours. Most of these are silent: users only see a warning when the underlying problem cannot be papered over. The categories below are worth knowing about so that you can recognise them in the wild and pick a NAS whose firmware is current.

Filesystem metadata that lies

• Files reported as existing when they aren't, or missing when they are. Some NAS firmware returns "already exists" when a file is being copied to a destination where it doesn't exist, or "not found" immediately after a successful copy. SyncBack double-checks with explicit existence and attribute lookups; when the answers disagree, you see the message "The drive/device is incorrectly stating the file exists when it does not" along with a recommendation to update NAS firmware.
• Read-only attribute not preserved across a copy. Some NAS shares quietly drop the read-only flag during a file copy. SyncBack re-applies the source attributes on the destination regardless of whether the user asked for that behaviour, so the protected file stays protected.
• Read-only attribute not cleared during a delete. Some firmware refuses to clear read-only as part of a delete, so the operation fails with access-denied. SyncBack inspects the attribute after the failure and reports it accurately rather than as a generic permissions error.
• Fake NTFS. Many NAS shares advertise NTFS but the underlying file system is not really NTFS. SyncBack runs its own NTFS detection rather than trusting the share's claim, so it only enables NTFS-specific features (such as exact-datetime support) when the share really is NTFS.

Coarse modification-time precision

• Two-second rounding. Many NAS shares store modification times to the precision of the original FAT file system: even-numbered seconds only, two-second granularity. Compared against a source with millisecond precision this produces spurious "modified" results. SyncBack defaults its TimeDiff setting to 2 seconds for non-NTFS volumes and explicitly recommends ignoring differences of 2 seconds or less.

Scanning quirks

• Large-fetch directory enumeration fails. The Windows 7 and later large-fetch directory listing API returns an error on some NAS shares. SyncBack catches that error and silently falls back to the classic enumeration API for the rest of the scan.
• The same file returned twice in a single listing. Broken NAS firmware can list the same filename twice during a single directory enumeration. SyncBack detects the duplicate and reports it as a possible problem with the NAS, rather than processing the same file twice.

Filesystem operation failures

• Extended directory creation rejected. Some NAS shares do not support the extended-attribute variant of directory creation. SyncBack falls back to the plain version automatically.
• Move operations rejected for valid moves. Some NAS devices return access-denied for file moves that the user is fully authorised to perform. The error is treated as a recoverable condition rather than a fatal one.
• Transient invalid-parameter errors. Network blips or internal NAS state changes occasionally produce an invalid-parameter error for an operation that would otherwise succeed. SyncBack retries up to five times before giving up, across the copy, move, rename and delete paths.

Lost connections and safe-copy

• Safe-copy temp file appears locked after a reconnection. SyncBack's safe-copy mechanism writes to a temporary filename and renames it on success. When the NAS connection silently drops and re-establishes as a new session, the temp file can appear locked to the new session. SyncBack regenerates the temp filename with a random extension and retries.
• Recoverable, not fatal. The engine treats a dropped network connection as something to reconnect through, not something to abort over. The retry count is configurable, and the network-related profile settings (described below) let you tailor the behaviour for your environment.

Vendor-specific anomalies

• ASUStor and Btrfs parent-folder appearing as a file. On ASUStor NAS devices using Btrfs, the parent folder of a target file can appear as a regular file rather than a directory when SyncBack is not running elevated. SyncBack detects this case explicitly and emits a Btrfs-specific warning so the user can adjust the run mode.

Settings that exist because of NAS misbehaviour

Several SyncBack profile settings exist precisely because of these quirks. They are worth knowing about even if the defaults are fine for most users:

• Connect to share first, Don't disconnect, Don't use default credentials, Force disconnect. Eight settings (source and destination) that address NAS shares which authenticate intermittently, drop connections, or get confused by the Windows credential cache.
• Disable the large find-first cache. A pre-emptive switch for known-broken NAS firmware.
• Recommend UNC over mapped drives. SyncBack offers to rewrite a mapped drive path into a UNC path automatically. Mapped drive letters are tied to the Windows user session and do not survive scheduled tasks that run under a different account, while UNC paths always work.

If you only take one practical thing away from this section, make it the UNC recommendation. A scheduled task running under SYSTEM or a service account simply cannot see a drive letter mapped from your interactive session, and this catches new users out regularly.

Notes by Vendor

Brief notes on the most common NAS families used with SyncBack. None of this is exhaustive: it is the kind of practical context users tell us they wish they had read before starting.

• Synology. Btrfs volumes support snapshots with optional immutability. Use Btrfs rather than ext4 if you can; Synology's snapshot tools work properly only on Btrfs. The default "Backup" shared folder template is a sensible starting point.
• QNAP. Snapshots are configurable per shared folder and can be made immutable for a retention period. Make sure the share you back up to has snapshot space allocated; without it, the snapshot policy is silently ignored.
• TrueNAS. ZFS-based, with snapshot and replication features that are powerful but require more attention than Synology or QNAP. SMB share permissions need to be set carefully to avoid mismatches between the ZFS dataset, the share, and the Windows-side ACL.
• ASUStor. Btrfs is the file system to choose for snapshot support. Watch for the elevated-permission Btrfs quirk described above if backups appear to fail with unexpected parent-folder errors.
• TerraMaster. A budget-friendly option that benefits especially from versioning and a layered strategy, since the firmware feature set is more basic than the vendors above.

Common Mistakes

The same handful of mistakes appears in customer support tickets every month. None of them is exotic.

1. Single-disk NAS treated as safe. One disk is one failure away from total loss. Use redundancy on the NAS and a second copy somewhere off the NAS.
2. Mirror profile when Backup with versioning is what was needed. Mirror cheerfully passes deletions and corruptions through to the destination.
3. No versioning. Without versions, recovering a file deleted last Tuesday is not possible.
4. Backups tested but restores never tested. A backup that has never been restored from is a hopeful guess.
5. Backing up over Wi-Fi and wondering why it is slow. Wi-Fi caps throughput well below wired Ethernet and is far more variable.

Test Your Restores

A backup is only as good as the restore. Restoring from a backup covers the mechanics; the discipline is the bit that gets skipped. A simple cadence that works for most users:

• Restore one file every month.
• Restore a complete folder every three months.
• Restore an entire profile once or twice a year, into a scratch location.

The point is not to find that the backup works (that is the happy case). It is to discover, in a controlled environment, the things that you did not realise were missing, broken or hard to retrieve. Permissions issues, application-specific quirks (databases, vector stores, email archives) and forgotten dependencies all surface most cheaply during a restore test, not during an emergency.

Conclusion

A NAS is one of the most useful pieces of hardware a SyncBack user can own, but only when paired with the right profile type, the right schedule, and a strategy that recognises a NAS as one tier in a layered backup rather than the whole answer. Backup profile, versioning on, UNC paths, wired networking where possible, and a copy that lives somewhere the NAS does not.

Ready to put a real strategy around your NAS? Create a SyncBackPro Backup profile pointed at a dedicated share, turn versioning on, and schedule a restore test for next month. The NAS will repay the small amount of design work many times over the first time something needs recovering.