Veeam v13: NAS Backup Configuration
- NAS Backup Architecture Overview
- Two Approaches: File Share vs NAS Filer Integration
- Required Infrastructure: Cache Repository and Proxy
- Adding an SMB File Share
- Adding an NFS File Share
- Adding an Enterprise NAS Filer (Storage Snapshots)
- Creating a File Backup Job
- Storing NAS Backups in Object Storage
- Restoring Files and Folders
- Upgrading from v12
NAS Backup Architecture Overview
Veeam NAS backup protects unstructured data on SMB (CIFS) and NFS file shares, Windows and Linux file servers, NAS filers, and in v13 even S3-compatible and Azure Blob object storage sources. It is a distinct backup pipeline from VM backup - it uses different components, different job types, and has its own set of infrastructure requirements.
The backup architecture for NAS involves three components working together. A general-purpose backup proxy reads data from the source file share. A cache repository acts as a staging area for metadata and temporary data during the backup process - it must be located as close to the NAS source as possible to avoid excessive network traffic. A backup repository is where the actual backup data lands - this can be a standard backup repository, a SOBR, or in v13, an object storage repository directly.
NAS backup uses a synthetic incremental approach: after an initial full backup, subsequent runs only process changed files. Veeam tracks changes using either change detection (comparing file attributes) or, for supported enterprise NAS filers, native snapshot integration that identifies changed files directly from the storage system without needing to scan.
Two Approaches: File Share vs NAS Filer Integration
How you add your NAS source to Veeam depends on what you are protecting and whether your storage system is supported for native snapshot integration.
The file share approach is the simpler path. You add the SMB or NFS share directly as a file share object in the Veeam inventory. Veeam scans the share to detect changed files between backup runs. This works for any SMB or NFS source regardless of the underlying storage system. The tradeoff is that change detection requires scanning, which adds load to both the NAS source and the network. For large shares with millions of files, scan time can become significant.
The NAS filer integration approach uses native snapshot capabilities of supported enterprise storage systems - NetApp Data ONTAP, Dell PowerScale (Isilon), Lenovo ThinkSystem DM/DG Series, and Nutanix Files in v13. When a supported filer is added to Veeam's infrastructure as a NAS filer, Veeam can trigger storage snapshots and use the snapshot's change tracking to identify modified files without scanning. This is faster and puts less load on the production storage, making it the preferred approach for enterprise NAS environments.
| Approach | Best For | Change Detection Method |
|---|---|---|
| SMB/NFS File Share | Any SMB or NFS source, generic NAS, Windows/Linux file servers | File attribute scan at each backup run |
| NAS Filer Integration | NetApp ONTAP, Dell PowerScale, Lenovo DM/DG, Nutanix Files | Native storage snapshots - no scan required |
Required Infrastructure: Cache Repository and Proxy
Before adding any NAS source, you need two pieces of infrastructure in place: a cache repository and a general-purpose backup proxy assigned to NAS processing.
The cache repository is a Windows or Linux server with local or attached storage. It stores temporary metadata that Veeam uses during the backup process - file index data, change tracking state, and working files. It must be network-adjacent to the NAS source, ideally on the same LAN segment. Putting the cache repository close to the source reduces the amount of traffic that has to traverse the network during change detection. The cache repository cannot be a SOBR or a hardened repository - it must be a standard backup repository configured for this purpose.
The general-purpose backup proxy for NAS backup reads data from the source file share and sends it to the backup repository. It is distinct from VMware and Hyper-V backup proxies. A server is added as a general-purpose proxy in Backup Infrastructure > Backup Proxies by selecting the General-Purpose Backup Proxy type. For NAS backup specifically, place the proxy as close to the source NAS as network topology allows - it will be doing the actual data reads.
Both components are added in Backup Infrastructure before you add any NAS sources. Add the cache repository first as a standard backup repository with a descriptive name that makes its purpose clear, then add the general-purpose proxy.
The cache repository assignment is specific per NAS filer or file share. If you change the cache repository for a NAS source that has existing backups in object storage, Veeam will prompt you to either attach migrated metadata, copy metadata from the old cache repository, or download metadata manually. Do not change the cache repository assignment on a production NAS source without understanding this workflow and planning for potential job disruption.
Adding an SMB File Share
SMB file shares are added through the Inventory view in the VBR console. Navigate to Inventory > File Shares, right-click and select Add SMB File Share.
Specify the Share Path
Enter the UNC path to the SMB share, for example \\fileserver\data. If the share requires credentials, provide a service account with read access to all files on the share. For shares that use guest access or have open permissions, credentials may not be required.
If you plan to use a dedicated proxy for this share, you can specify it at this step. Otherwise, Veeam selects an available proxy automatically based on proximity and load.
Configure Processing Settings
Select the cache repository for this share. This should be the repository you set up on the same LAN segment as the file server. Set the Backup I/O control slider - this limits how many parallel threads the proxy uses to read from the share, controlling how aggressively Veeam accesses the source NAS. Start conservatively and increase based on observed performance and source load.
Configure Inclusion and Exclusion Rules
Specify which folders within the share to include or exclude from backup. This is particularly important if you are adding a share root and only want to protect specific subdirectories. Exclusions are evaluated first - a path matched by an exclusion rule is excluded even if also matched by an inclusion rule. Use explicit paths rather than wildcards where possible for predictable behavior.
Adding an NFS File Share
NFS file shares are added via Inventory > File Shares > Add NFS File Share. The process parallels the SMB workflow with a few NFS-specific considerations.
Provide the NFS server IP or hostname and the export path. The proxy machine must have NFS client capability and read/write permissions to the NFS export, along with root access. For Linux-based proxies, ensure the NFS client package is installed before attempting to add the share - on Debian-based systems this is nfs-common, on RHEL-based systems it is nfs-utils.
The cache repository selection and I/O control settings work identically to the SMB workflow. Configure inclusion/exclusion rules the same way.
For both SMB and NFS file shares, Veeam detects changed files by scanning file attributes at each backup run. This scan can generate significant load on the source NAS for large shares. If your NAS source is an enterprise filer from a supported vendor, consider using the NAS Filer integration path instead to avoid repeated full scans.
Adding an Enterprise NAS Filer (Storage Snapshots)
For supported enterprise filers - NetApp Data ONTAP, Dell PowerScale, Lenovo ThinkSystem DM/DG, and Nutanix Files - Veeam can integrate at the storage level rather than the file protocol level. This requires adding the storage system to Veeam's infrastructure first, then configuring the NAS filer role on it.
Add the Storage System
In Backup Infrastructure > Storage Infrastructure, add your storage system using the appropriate wizard for the vendor - NetApp Data ONTAP, Dell PowerScale, and so on. Provide management credentials with sufficient rights to trigger snapshots and enumerate volumes. This step varies by vendor - consult the Veeam help center documentation for vendor-specific requirements.
Enable the NAS Filer Role
After adding the storage system, edit its properties and enable the NAS filer role. Select the protocols the storage uses for file access - NFS, SMB, or both. Only volumes accessible via the selected protocols will be available for NAS backup. Also configure which storage volumes to analyze for file shares. Limiting this to only the volumes you need to protect reduces storage system load during Veeam's discovery process.
Add the NAS Filer to the File Share Inventory
In Inventory > File Shares > Add Enterprise Storage System as NAS Filer, select your configured storage system. Veeam discovers the file shares present on the configured volumes. Select the shares you want to protect. Assign the cache repository and I/O control settings as with standard file shares.
With NAS filer integration enabled, Veeam triggers a snapshot on the storage system at backup time, mounts it, and reads changed data directly from the snapshot rather than from the live share. This eliminates scanning and reduces production impact.
Creating a File Backup Job
File backup jobs are created from the Home view by selecting Backup Job > File Share Backup. The wizard steps through source selection, backup target, schedule, and retention.
Select the File Shares to Protect
Add the SMB shares, NFS shares, or NAS filer shares you added to the inventory. One file backup job can cover multiple shares from different sources. Group shares with similar retention requirements and backup windows in the same job for easier management.
Configure the Backup Repository
Select the backup repository where NAS backup data will be stored. Standard repositories, SOBR performance extents, and in v13 object storage repositories directly are all supported targets. Object storage as a direct target is a significant v13 improvement - it allows NAS backups to land in S3, Wasabi, or Azure Blob without needing SOBR as an intermediary tier.
Set the restore point retention. NAS backups use a GFS (Grandfather-Father-Son) retention model by default, allowing you to set daily, weekly, monthly, and yearly restore point counts independently.
Configure the Schedule
Set the backup schedule. Unlike VM backup jobs, file backup jobs support continuous backup mode in addition to scheduled backup. Continuous backup runs repeatedly on a short interval - useful for shares with frequently changing data where hourly or more frequent restore points are required. For most environments, a scheduled daily backup with the cache repository providing fast local access for recent file restores is sufficient.
Storing NAS Backups in Object Storage
In v13, NAS backup data can be sent directly to object storage as the primary backup target without needing a SOBR intermediary. This covers AWS S3, Wasabi, Azure Blob Storage, and S3-compatible targets. The metadata required to navigate and restore from the backup still lives in the cache repository - the object storage holds the actual data blocks.
Configure object storage as the backup target by selecting an object storage repository at the backup target step of the file backup job wizard. Ensure the cache repository is on a machine that has good network connectivity both to the NAS source and to the object storage endpoint, since it coordinates both the read side and the write side of the process.
When backing up NAS data directly to object storage, the restore workflow differs from standard repository restores. The metadata in the cache repository is required to initiate a restore. If you lose the cache repository and its metadata, restores from object storage require downloading and reconstructing the metadata index, which is a time-consuming process. Back up the cache repository machine itself, or at minimum ensure its metadata directory is covered by a separate backup mechanism.
For long-term NAS archive to cloud object storage, consider enabling immutability on the target bucket if your object storage provider supports it. Veeam NAS backups in object storage can be protected with object lock on S3-compatible targets, giving you the same ransomware protection available for VM backups in SOBR Capacity Tier.
Restoring Files and Folders
File restores from NAS backups are initiated from the Home view. Right-click the file backup in the Backups > Disk or Backups > Object Storage node and select Restore file share data. Select the restore point date and time, then browse the backup to find the specific files or folders to recover.
Restored files can be written back to the original location (overwriting current files), to an alternate path on the same share, or to a different share entirely. For large-scale restores where the cache repository metadata is intact, restore from recent backup dates is fast. Restore from older points that have been moved to object storage adds retrieval time for data blocks.
For NAS filer backups with multiple shares per job, each share restores independently - you do not need to restore all shares in a job together. Select the specific share and the specific restore point when initiating recovery.
Upgrading from v12
Existing NAS backup jobs from v12 carry forward to v13 without reconfiguration. File shares added to the inventory, cache repository assignments, and job schedules all survive the upgrade. Existing backup data is readable without conversion.
The primary new capability to evaluate post-upgrade is direct object storage targets for NAS backup jobs. In v12, landing NAS data in object storage required a SOBR with a Capacity Tier. In v13, object storage can be the direct target, simplifying the architecture for environments that want cloud-native NAS backup storage without the SOBR overhead.
For teams upgrading from the SMB/NFS file share approach on a supported enterprise NAS platform, v13 is also a good point to evaluate whether NAS filer integration makes sense. If your filer is a supported model and your shares are large, switching from file scan to snapshot-based change detection can meaningfully reduce backup window duration and NAS load. This requires adding the storage system to the infrastructure and converting the existing file share inventory entries, which involves running a PowerShell cmdlet to update the backup format.
- Added a cache repository on the same LAN segment as the NAS source for staging metadata
- Added a general-purpose backup proxy configured for NAS file share processing
- Added SMB or NFS file shares to the inventory with appropriate credentials and I/O controls
- Optionally integrated an enterprise NAS filer for snapshot-based change detection
- Created a file backup job covering the target shares with schedule and retention configured
- Verified the first backup run completed and restore points are visible in the Home view
- Confirmed the cache repository is itself being backed up or its metadata directory is protected
NAS backup is often the component that gets added reactively - after something is lost from a file server. Getting the cache repository placement right at the start is the configuration decision that determines long-term performance. A cache repository on the wrong network segment is not catastrophic, but it causes unnecessary traffic and slower change detection at every backup run. Put it close to the data, keep it backed up, and treat it with the same care as any other piece of Veeam infrastructure.