Short answer: if the NAS supports Time Machine, turn that on in the NAS settings and add the share as a backup disk on the Mac.
If it does not, or you would rather not depend on it, back up to a plain shared folder instead. Any tool that writes to a folder can use it.
Most NAS software has a Time Machine option: it creates a share, usually with a size quota, and advertises it so your Mac can find it. On the Mac, System Settings, General, Time Machine, Add Backup Disk, and the share appears.
What to know:
rsync over SSHIf the NAS runs SSH, copy straight to it without mounting anything:
rsync -aE --delete ~/Documents/ [email protected]:/volume1/backup/Documents/Faster than going through a mounted share, and it does not silently do nothing when the mount is missing: if the NAS is unreachable, the command fails visibly.
Set up a key first so it does not sit waiting for a password on a schedule:
ssh-keygen -t ed25519
ssh-copy-id [email protected]Same caveats as anywhere else: rsync is a mirror, not history, and it encrypts nothing at rest.
The full rsync guide covers both.
Mount the share in Finder and it appears under /Volumes like any other disk. Anything that
writes to a folder can then use it, including Copy Shelter, which gives you versions,
encryption before anything leaves the Mac, and a read-back that checks every piece against its hash.
Encrypting before the write matters more on a NAS than people assume. A NAS is a small computer with an operating system, a web interface, and often a port forwarded to the internet by a past version of you. Bytes it cannot read are bytes that stay yours when it is compromised.
This is the failure that makes network backups different from every other kind, and it is the one the forum threads are full of.
When a share goes away cleanly, the mount disappears and a write fails immediately. Fine. What
happens more often is that the share stops responding without disconnecting: the NAS went to sleep,
the switch dropped a link, the Mac woke up faster than the network did. The mount point is still
there, ls still lists it, and a write to it blocks.
Not fails. Blocks. The process sits in an uninterruptible wait for as long as the client is configured to keep trying, which by default can be a very long time. A backup job in that state is not failing and not finishing, and anything watching for a non-zero exit code sees neither.
You can spot it:
mount | grep smbfs
timeout 5 ls /Volumes/Backup >/dev/null || echo "share is not answering"The practical defences are a hard timeout around every operation, treating "no answer" as "destination unreachable" and not as an error to retry forever, and never letting a stalled
destination hold up the others. If you are scripting this yourself, wrap the whole job in
timeout and make the failure loud.
On a local disk, fsync() returning success means the bytes are on the platter or in
the flash. Over SMB it means whatever the server decided it means, and that varies by firmware: some
NAS software acknowledges a flush the moment it has the data in RAM, and a power cut in the following
seconds loses writes that every layer above reported as complete.
You cannot fix this from the Mac. What you can do is stop treating "the copy finished" as "the copy is safe", which means reading the backup back afterwards and checking it, on the share, as a separate pass. That is the only thing that distinguishes a write the server really persisted from one it merely accepted.
SMB shares map Unix ownership onto whatever the NAS thinks you are, and the mapping is frequently not what you expect. Two symptoms worth knowing:
._filename companion files instead, or discard them. rsync -aE asks for
them; whether they survive is the server's decision.ls -l on the share. Finder reports a cached size.Some SMB servers report volume capacity incorrectly, or report the capacity of the underlying pool, ignoring your share and its quota. A backup tool that trusts that number will happily fill a share it was told had terabytes free.
The safe reading is that absent or implausible capacity means unknown, never infinite. Check by hand before a first large backup:
df -h /Volumes/Backupsmb:// and the NAS name, and sign in as that user.Yes, when the NAS offers an SMB share with Time Machine support turned on. Synology, QNAP, TrueNAS and most other current NAS systems have that setting.
Usually the share disconnected during sleep, or the Time Machine disk image on the NAS was damaged. Keep the Mac on power during the first backup, and see the guide on the disk image error if it keeps happening.
Usually the Time Machine service is not switched on for that share, or the NAS is advertising over AFP only. Check the NAS side first, then connect to the share in Finder once so macOS has the credentials, then look again.
Yes. Give each Mac its own share or its own quota, so one machine cannot fill the space the other needs.
For incremental backups on gigabit, comfortably. The first full backup is the slow part, so do that one over a cable.
Almost never. A NAS reachable from the internet is a small server you are now responsible for patching. If you want off-site, a folder in a cloud account you already pay for is safer and usually simpler. How to use that space properly.
No. RAID handles one kind of failure, a dead disk, and none of the others. Every deletion, every mistake and every piece of ransomware reaches all the disks at once.
Related: backing up a Mac to an external drive.