Backing up SMB shares
with Restic, done right

Restic does not speak SMB - so you mount it

There is no built-in SMB backend in Restic. The approach is: mount the SMB share, then run Restic against the local mount point. This works on Linux (cifs-utils), macOS (built-in SMB client), and Windows (native).

The tricky part is not the mounting. It is the permission model, the stat latency, and the "what happens when the share disappears mid-backup" edge case. Done naively, you get slow backups that occasionally corrupt themselves.

First: can you skip SMB entirely?

If the SMB share is hosted by a Linux box running Samba, or a NAS you can SSH into, run Restic on the SMB server, not the client. You get:

• No network latency per file stat
• Real POSIX permissions, not SMB's translated view
• Proper symlink handling
• Filesystem snapshots (LVM, ZFS, Btrfs) for consistent backup

Mount-based SMB backup is the right answer only when you cannot run Restic on the source - e.g. a locked-down corporate file server or a commercial NAS with no shell access.

Linux: mount.cifs + Restic

Install cifs-utils on the backup host:

apt install cifs-utils   # Debian/Ubuntu
dnf install cifs-utils   # Fedora/RHEL

Store credentials in a root-only file:

sudo install -m 600 /dev/null /etc/smbcreds
sudo tee /etc/smbcreds <<EOF
username=backupuser
password=yourpassword
domain=WORKGROUP
EOF

Mount with options tuned for backup workloads:

sudo mkdir -p /mnt/smb-backup
sudo mount -t cifs //fileserver/share /mnt/smb-backup \
  -o credentials=/etc/smbcreds,ro,vers=3.0,cache=strict,noserverino,iocharset=utf8

Why those flags:

• ro - read-only mount. Backups do not need write access; removing it reduces the blast radius of mistakes.
• vers=3.0 - force SMB 3.0 for encryption and performance. Avoid vers=1.0.
• cache=strict - aggressive client-side cache, safe for read-only mounts.
• noserverino - do not trust server inode numbers. Required on some NAS devices or Restic will see ghost changes every run.
• iocharset=utf8 - correct filename encoding.

Then run Restic normally:

export RESTIC_REPOSITORY=sftp:vaultuser@vault.servercrate.net:22150:/data
export RESTIC_PASSWORD=your-repository-password
restic backup /mnt/smb-backup --tag smb-fileserver

Handling the "share disappeared mid-backup" case

If the SMB server reboots or the network blips, the mount goes stale. Restic will error partway through. Wrap the backup in a script that verifies the mount before proceeding:

#!/bin/bash
set -euo pipefail

MOUNT=/mnt/smb-backup

if ! mountpoint -q "$MOUNT"; then
  mount "$MOUNT" || exit 1
fi

# Sanity check: can we actually read?
if ! ls "$MOUNT" > /dev/null 2>&1; then
  echo "Mount is stale, remounting"
  umount -l "$MOUNT"
  mount "$MOUNT"
fi

restic backup "$MOUNT" --tag smb-fileserver
umount "$MOUNT"

macOS: native SMB client

On macOS, mount via Finder (Go → Connect to Server → smb://fileserver/share) or the command line:

mkdir -p /Volumes/fileserver-share
mount_smbfs //backupuser@fileserver/share /Volumes/fileserver-share
restic backup /Volumes/fileserver-share --tag smb-fileserver-mac

macOS's SMB client is generally well-behaved but does not expose as many tuning knobs as Linux. For a one-off Mac backing up a single share, this is fine.

Windows: UNC paths or mapped drives

Restic for Windows accepts UNC paths directly - no mounting required:

restic backup \\fileserver\share --tag smb-fileserver-win

Or via a mapped drive:

net use Z: \\fileserver\share /user:backupuser yourpassword
restic backup Z:\ --tag smb-fileserver-win

Windows-side, the bigger gotcha is VSS (Volume Shadow Copy). For files that might be locked, use Restic with VSS support or pause the application that holds the locks.

The performance problem: SMB is stat-heavy

Restic backup is bottlenecked on two things: hashing changed files, and scanning every file to detect changes. The scan is a stat() per file. On a local filesystem, a stat is microseconds. On SMB, it is a network round-trip - single-digit milliseconds on a LAN, tens of milliseconds over VPN.

A million-file share that scans in 10 seconds locally takes 10 minutes over LAN SMB and hours over WAN SMB. For large shares, run the backup host as close to the SMB server as possible. A small Linux VM on the same switch as the SMB server, doing the SMB mount and then pushing to ServerCrate over SFTP, is the standard architecture.

Permissions and metadata

SMB translates NTFS ACLs into POSIX-style permissions. Restic captures what it sees, which is the translated view. If you restore to a non-SMB filesystem, you get POSIX permissions, not the original NTFS ACLs.

If preserving ACLs matters - corporate file servers, multi-user permission structures - run Restic on the SMB server directly where it can read the native ACLs, not through a mount.

Pointing Restic at a ServerCrate vault

Your Restic repository target and the SMB source are independent. Once the SMB share is mounted locally, the repository can be anywhere Restic supports:

# ServerCrate SFTP vault
export RESTIC_REPOSITORY=sftp:vaultuser@vault.servercrate.net:22150:/data

# Or another backend
# export RESTIC_REPOSITORY=b2:bucket-name:/
# export RESTIC_REPOSITORY=s3:s3.amazonaws.com/bucket-name

The ServerCrate vault is Restic-native, zero-knowledge, and SFTP-accessible. Encryption happens on the backup host before upload - the server cannot read what you backed up, whether it came from an SMB share or anywhere else.

Full working example

# /usr/local/bin/backup-smb-share.sh
#!/bin/bash
set -euo pipefail

source /etc/restic/env  # RESTIC_REPOSITORY, RESTIC_PASSWORD
MOUNT=/mnt/smb-backup

# Ensure mount
mountpoint -q "$MOUNT" || mount "$MOUNT"

# Verify mount is live
ls "$MOUNT" >/dev/null

# Back up
restic backup "$MOUNT" \
  --tag smb-fileserver \
  --exclude '*.tmp' \
  --exclude 'Thumbs.db' \
  --exclude '~$*'

# Keep reasonable history
restic forget \
  --tag smb-fileserver \
  --keep-daily 7 \
  --keep-weekly 4 \
  --keep-monthly 12 \
  --prune

restic check --read-data-subset=5%