How to Set Up Windows Server Backup to a Network Share

Windows Server Backup (WSB) is free, built-in, and good enough for a lot of smaller environments, but its network share support has one quirk that catches people out: scheduled backups to a network share only keep a single backup at a time, overwriting the previous one, unlike backups to a dedicated local or attached disk which keep a rolling history.

• Windows Server Backup is a feature you install, not enabled by default
• Scheduled backups to a network share overwrite the previous backup. There’s no version history
• For version history, back up to a dedicated local disk or use a supported third-party backup product
• The network share must allow the backup server’s computer account (or specified credentials) write access

Step 1: Install the Windows Server Backup feature

Install-WindowsFeature Windows-Server-Backup

Step 2: Run a one-off backup to validate the share works

Before scheduling anything, run a manual backup to confirm permissions and connectivity are correct:

wbadmin start backup -backupTarget:\\FileServer01\Backups -include:C: -quiet

If this fails with an access denied error, check that the account WSB is running as (or the credentials you’ll supply for the scheduled job) has write access to the share and underlying NTFS permissions, not just share-level permissions.

Step 3: Create the scheduled backup

Use the Windows Server Backup GUI (or wbadmin enable backup) to configure a daily schedule targeting the network share. You’ll be prompted for credentials with write access to the share. Use a dedicated service account rather than your personal admin credentials.

Understand exactly what “overwrite” means here

Each scheduled run to a network share target replaces the entire previous backup. There is no rolling history of multiple restore points like you get with a dedicated local disk target. If you need to restore from three days ago and the schedule has run since then, that backup is simply gone. If point-in-time history matters for your recovery requirements, either back up to a dedicated local or iSCSI-attached disk instead (which does retain multiple versions), or supplement WSB with a proper backup product designed for versioned retention.

Test your restore, not just your backup

A backup you haven’t test-restored is a hypothesis, not a backup. Periodically run through wbadmin get versions and a test restore of at least individual files to confirm the backup set is actually usable when you need it.

For official guidance, see Microsoft’s Windows Server documentation.