Backing up NAS and file shares: NDMP, SMB, changed-file detection and permissions

About this article: AI-assisted writing, reviewed against the cited sources. This is source research, not a lab validation of the procedures. Check the stated versions and your own recovery requirements before making changes.

A file share backup has to answer three questions: which path moves the data, how changes are found, and whether permissions come back. NDMP (Network Data Management Protocol) moves data under the storage system's control, and on ONTAP's dump engine it reads from a snapshot. An SMB copy is an ordinary client reading files one at a time, so it inherits every limit of being a client.

Changed-file detection is where backups go quietly wrong. Timestamps can be set by applications, notification buffers can overflow, and journals can lose old records. Each method needs a validated gap response; metadata scans alone cannot detect every content change.

Identifiers are examples. Validate copy and restore behaviour on isolated data. ONTAP is the NDMP example; other NAS products differ.

Interpretations are editorial; no lab testing was performed.

Why it matters

The failure that hurts is not a failed job. It is a restore that finishes successfully and leaves the data unusable: files present, but owned by nobody, readable by everyone, or missing the alternate streams an application relied on.

Permissions are data on a file server. Treat them with the same care as contents, and test them in the restore.

Connection failures after Windows upgrades also require checking SMB signing compatibility.

How it works

NDMP: who does what

NDMP separates control from data. The Data Management Application, or DMA, controls the session and is responsible for all state and for media management, while the NDMP service keeps only local running state. The DMA is your backup product.

Two points follow from the protocol. First, NDMP data streams carry implementation-specific backup data, and file positions in the file history are in a format specific to the data service, opaque to the DMA. NDMP standardises control, not the backup format. Plan on restoring a stream to a compatible system from the same vendor, and confirm it with that vendor before relying on anything else.

Second, the protocol is a 2003 Internet-Draft, not an RFC. Implementations and extensions vary, so "supports NDMP" is not a compatibility statement. ONTAP says only NDMP version 4 is supported.

The layouts are worth naming, because they decide where backup traffic runs. In a local configuration the tape is attached to the storage system and the data connection stays inside it; in a three-way configuration data crosses a TCP network to another storage system or a network-attached library.

ONTAP's two engines

ONTAP offers two different backups over NDMP, and they answer different needs.

Dump is snapshot-based, so the volume stays online. If you do not name a snapshot, the engine creates one and deletes it afterwards. That gives a consistent file system view, which an SMB client cannot produce on its own.

Levels run from 0 to 31, each based on the most recent lower-level backup. A sequence such as 0, 2, 3, 1, 4 creates two chains, so a level chosen casually changes what a restore needs. Your backup product normally manages this; check what it sends.

Two settings matter for restore. HIST=Y sends file history to the backup application, and turning it off speeds backup at the cost of that index. DIRECT=Y fast-forwards to the file's location rather than scanning the whole tape, if the application supplies positions. Enhanced direct access recovery is described as on by default, and may affect backup speed, because an offset map is written to tape. The variables page lists ENHANCED_DAR_ENABLED with a default of N, and requires HIST=Y during the backup, ndmpd.offset_map.enable on, and the variable set to Y during restore. The two pages need reconciling on your release. Turning off HIST for speed also removes enhanced recovery.

Size a backup window from the engine limit, not the server limit. ONTAP's dump and restore sessions are limited by memory to 4 below 16 GB, 16 from 16 GB to below 24 GB, and 32 at 24 GB or more. Its NDMP server limits are the higher figures of 8, 20 and 36, and one ndmpcopy uses two sessions. SVM-scoped NDMP is recommended, node-scoped NDMP is deprecated, and the two cannot be configured on the same cluster. However, if the backup application does not support Cluster Aware Backup, node-scoped is the only option.

SMB: a client reading files

A backup through a share opens each file like any other client. The account's permissions then limit what can be read, unless backup semantics apply.

SeBackupPrivilege grants read access to any file regardless of its ACL, and SeRestorePrivilege grants write access and lets the holder set any valid user or group as owner. They take effect through FILE_FLAG_BACKUP_SEMANTICS. Robocopy's /b is backup mode, and /zb is restartable mode that switches to backup mode on access denied.

The U in the copy flags used later needs a third right: access to auditing information is granted only if SE_SECURITY_NAME is enabled, which is the "Manage auditing and security log" right. And on a NAS the check happens at the server. SMB's backup-intent flag says the server "can check" that the caller can override security, so the result depends on how that NAS honours it. Our reading is that the account needs the rights on the NAS itself, so confirm that per product.

Warning: an account with these privileges can read and overwrite everything those privileges reach. Keep it dedicated, deny interactive sign-in, and do not let it hold a mailbox or browse the web.

A Windows backup with an agent can coordinate through VSS, the service that creates consistent shadow copies with writers from applications. A plain file copy through a share has no part in that, so a set of related files can be captured at different moments. For a NAS, read from a storage snapshot where the product exposes one, and check its documentation for how.

How changed files are found

The table is our summary; the detail and sources follow it.

Timestamps. Comparing size and modified time is the simple approach. Microsoft is blunt: the only guarantee is that a file time is correct when the handle making the change is closed, and SetFileTime changes times without changing content. A program that restores the old time after writing will be missed by a timestamp comparison. Resolution can vary too: FAT write time has two-second resolution, which is why robocopy has /fft for FAT-style destinations.

Archive attribute. Applications typically use it to mark files for backup or removal. That is a convention with no enforcement, and two tools sharing it interfere with each other.

Directory notifications. SMB has a CHANGE_NOTIFY request for watching a directory. The Win32 equivalent shows the weak point: if the buffer overflows, the call still returns true, the entire buffer is discarded, and the byte count is zero. It fails if the redirector or target file system does not support the operation. Microsoft also notes it requires an application running at all times. Changes made while the watcher is down are invisible. The call can also fail with ERROR_NOTIFY_ENUM_DIR when the system could not record every change, and Microsoft says to enumerate the directory or subtree. Over a network, a buffer above 64 KB fails with ERROR_INVALID_PARAMETER. Treat a zero-byte result, ERROR_NOTIFY_ENUM_DIR or a restart as "rescan".

USN change journal. The pages cited here were written for NTFS, though ReFS also lists USN journal support. On NTFS, every change to a file or directory adds a record with its reason. Microsoft describes it as much more efficient than timestamps or notifications. But it is local: operations need membership of the Administrators group and a handle to the volume itself, opened as \\.\ plus the drive letter. Through a share, you cannot use it, so this method means an agent on the file server.

Three behaviours need handling:

• NTFS may delete old records to save space. If the position you saved is gone, do a full scan.
• The journal identifier changes when existing records are or may be unusable. Store it with the position and compare on every run.
• Repeated changes may collapse into one record. It tells you that a file changed, and you still need to read the file.

To inspect a volume:

fsutil usn queryjournal D:
fsutil usn readdata D:\Data\report.xlsx

The first reports the journal, its records and its capacity, and the second reads the USN data for one file. Comparing the journal's identifier and oldest available position with what your backup product saved shows whether its next run can trust the journal.

Size matters: the journal is trimmed once it exceeds MaximumSize plus AllocationDelta. Running createjournal on a volume that already has one updates those values. Size it to outlast your longest backup gap, including a missed weekend.

Warning: do not run fsutil usn deletejournal to clear a problem. Microsoft's caution says deleting it forces the File Replication Service and the Indexing Service into a complete scan of the volume. Other journal users are likely to need the same (our broader reading), and the operation walks every file on the volume and persists across restarts.

Storage engines. ONTAP's dump shows why this row deserves attention. A changed ctime makes a file eligible for an incremental backup, and some applications such as virus scanners change it when nothing else has changed, so incrementals grow. The setting IGNORE_CTIME looks like the fix.

Warning: ONTAP warns that setting IGNORE_CTIME to true can cause data loss: files moved across qtrees are deleted during a volume-level incremental restore or ndmpcopy, so it must be false for those.

What to choose and why

Validate the selected change-tracking method and schedule an independent comparison appropriate to its gaps. A size-and-time rescan cannot detect a content change that preserves both values; content comparison or validated storage-level tracking is needed for that case.

Permissions: what actually comes back

Windows and SMB

Robocopy's default is DAT: data, attributes and timestamps, and not security. A default copy does not copy the source security descriptor; destination permissions may be inherited or retained. S adds the NTFS ACL, O the owner and U the auditing information, and /copyall is all of them. Directory timestamps need /dcopy:DAT, since the default is only DA.

A reviewed copy specification should name a unique isolated destination, a consistent source view, the required DATSOU file metadata and directory timestamps, retry bounds and a retained log. Copying into an existing path can overwrite earlier content even without mirror deletion. Validate metadata and data recovery before treating that job as backup protection.

Four settings and behaviours need checking in that implementation.

Set /R and /W. The defaults are one million retries, 30 seconds apart, which is roughly 347 days on one locked file.

Read the exit code properly. Any value of 8 or more means at least one failure, while 0 means nothing needed copying and 1 means files copied successfully. A scheduler that treats every non-zero result as failure raises false alarms.

The destination must be able to hold what you copy. The server, filesystem and copy path must represent and preserve the required permissions. Samba can store NT ACLs in extended attributes, so check the actual mapping and restore result rather than assuming the underlying filesystem needs a native NT ACL model.

Junctions need a decision too. Robocopy says they are normally included by default, and /xj excludes them, so an unattended copy can follow one out of the intended tree. ONTAP's dump backs up junction paths as symbolic links.

Warning: /mir and /purge delete destination items that no longer exist at the source. Encryption can overwrite good destination content, while source deletions can remove destination files at the next mirror run, so a single mirror is not a backup with history.

Alternate data streams also matter. A file can hold named streams beside its default unnamed one. Robocopy's X flag skips them, and is ignored under /B or /ZB. ONTAP's dump restores Windows NT streams. BackupRead handles file data together with security information, though the SACL needs ACCESS_SYSTEM_SECURITY on the handle.

Exporting ACLs separately is a useful second copy. icacls /save stores DACLs for later /restore, with a real limit: a DACL is the permission list only, so owner and auditing settings are not in that file (our reading of "stores DACLs").

icacls D:\Data\* /save E:\Acl\data.acl /t /c

Warning: /restore applies the saved permissions to the live tree. A stale export takes away access granted since it was made, so use a reviewed restore procedure against an identified isolated target and validate the resulting access before any production permission change.

Samba

Linux has no native NT ACL, so Samba can store one elsewhere. vfs_acl_xattr keeps it in the security.NTACL extended attribute, containing Windows SIDs. Two consequences:

• A backup that does not carry that attribute loses the Windows permissions, even when POSIX ownership looks correct. It is not shown by getfattr -d, so ask for it by name: getfattr -n security.NTACL filename. Samba calls it a protected location, not accessible to normal users outside Samba, so run the backup as root. acl_xattr:security_acl_name can rename it, so check your configuration. GNU tar is a trap here: with --xattrs all names are stored, but only the user namespace is extracted by default. A restore therefore needs an explicit --xattrs-include='security.NTACL' (our reading, so test it).
• The mapping from users and groups to SIDs must stay consistent. A rebuilt server with different ID mapping changes what restored permissions mean.

From a client, smbcacls --save stores DACLs in SDDL, without SACLs, owner or integrity labels.

Mixed security on ONTAP

Restoring across security styles has documented catches, and the one that matters most for a Windows share is this: a file with only Windows NT permissions restored to a UNIX-style qtree gets that qtree's default UNIX permissions.

The reverse case has two different answers in ONTAP's documentation. The restore page says a file with only UNIX permissions restored to an NTFS qtree has no Windows ACL, and only UNIX permissions apply until one is created. The backup page says the file gets the default Windows permissions for that qtree. Test it on your release.

For direct access recovery, RECOVER_FULL_PATHS defaults to N, needs DIRECT and ENHANCED_DAR_ENABLED, and when set does not restore permissions and ACLs for directories that already exist. A direct access restore over existing folders can therefore return files beneath the old folder permissions. The page does not describe the ordinary restore case.

ONTAP's restore also ignores mandatory and advisory locks on the destination. Restore to a new location unless you have stopped users.

Proving a restore

Restore one representative folder to a test location, then compare it with the original. This sequence is our design.

1. List differences without changing anything. Robocopy's /l lists files only, with no copy, delete or timestamp change. It compares file size and time, so as the timestamps section explains, it does not prove the contents match:

robocopy D:\Data\Finance E:\Restore\Finance /E /L /LOG:E:\Logs\compare.log

2. Compare contents on a sample of files, including some your applications rewrite. Get-FileHash computes a hash for each side:

(Get-FileHash D:\Data\Finance\report.xlsx -Algorithm SHA256).Hash -eq (Get-FileHash E:\Restore\Finance\report.xlsx -Algorithm SHA256).Hash

3. Export DACLs from both trees with icacls /save and compare the two files. Microsoft's page does not document the export format, so try the comparison on a small folder first and see whether paths need normalising.
4. Inspect owners and auditing separately, because the DACL export does not cover them.
5. Check named streams on a file known to have them. FindFirstStreamW and FindNextStreamW enumerate streams.
6. Open files as a normal user who should have access, and again as one who should not. A correct ACL on paper proves little if the group's SID has changed.

Record the result and the date. A restore that was only proved to finish has not proved the permissions.

Risks and limits

• Domain dependence. ACLs hold SIDs, so a restored share in a rebuilt domain needs those identities or a translation step. icacls has /substitute for replacing SIDs in a restore.
• Long-term format. NDMP streams are implementation specific, so a retained tape depends on being able to read that format later.
• Share-level permissions. Permissions on the share are separate from those on the files. The sources here cover file ACLs. Record share definitions as configuration.
• Vendor coverage. We read ONTAP only. Check the same questions against your NAS vendor's documentation.

Sources

Opened 10 November 2026.

• NDMP version 4 Internet-Draft
• ONTAP: tape backup overview
• ONTAP: NDMP configuration
• ONTAP: common NDMP topologies
• ONTAP: dump backup
• ONTAP: how dump backs up
• ONTAP: how dump restores
• ONTAP: increment chains
• ONTAP: environment variables
• ONTAP: enhanced direct access recovery
• ONTAP: NDMP session limits
• ONTAP: dump backup and restore session limits
• ONTAP: SMTape unsupported features
• Change journals
• Change journal records
• Using the change journal identifier
• Creating, modifying and deleting a change journal
• fsutil usn
• File times
• File attribute constants
• File streams
• ReadDirectoryChangesW
• MS-SMB2: CHANGE_NOTIFY request
• Privilege constants
• SACL access right
• MS-SMB2: SMB2 CREATE request
• ReFS overview
• Get-FileHash
• CreateFile
• BackupRead
• robocopy
• icacls
• Volume Shadow Copy Service
• Samba vfs_acl_xattr
• Samba smbcacls
• GNU tar: extended file attributes

This article was originally published on 10 November 2026.