Proxmox Backup to NAS: NFS vs SMB Setup and Restore Checklist
Preparation date: September 17, 2026. Scope: This is a documentation-based implementation and verification guide, not a claim about a completed customer incident. It covers ordinary Proxmox VE VZDump backups written to NAS storage. A Proxmox Backup Server datastore is a different architecture and is called out separately.
The short answer is: choose NFS when Proxmox is the main consumer and your NAS can restrict the export to the Proxmox node addresses. Choose SMB/CIFS when the same share must also fit a Windows-oriented operating model or your NAS administration is already built around named users and SMB permissions. The protocol choice matters, but the restore test matters more. A green backup task proves that an archive was written; it does not prove that you can recover a VM on replacement storage.
Environment and assumptions
This guide assumes one or more Proxmox VE nodes, a NAS on a trusted management or storage network, and enough separate capacity for retention. Record the Proxmox VE version, NAS model and firmware, share name, protocol version, node addresses, expected backup size, retention target, and recovery objective before changing storage. If those details are unknown, treat this article as a worksheet and do not copy commands blindly.
Decide first whether you are using direct VZDump archives or Proxmox Backup Server. Proxmox VE can store VZDump backup files on NFS and CIFS storage. Proxmox Backup Server instead uses datastores, incremental transfers, deduplication, verification jobs, pruning, and its own permission model. Do not mix instructions for these two designs merely because both eventually use NAS disks.
NFS vs SMB: the practical decision table
| Decision point | NFS | SMB/CIFS |
|---|---|---|
| Best fit | Linux-first Proxmox environment with NAS export controls | Windows-oriented administration or an existing SMB identity model |
| Access control | Usually host/subnet export rules plus filesystem ownership | Named credentials, share permissions, and filesystem ACLs |
| Common failure | Export allowlist, root mapping, ownership, or stale mount | Credential, domain/workgroup, signing, dialect, or share ACL mismatch |
| Security caution | Do not export broadly to an entire untrusted network | Do not enable SMB1 or disable signing as a generic workaround |
| Operational preference | Usually simpler when only Proxmox nodes write backups | Useful when administrators also need controlled Windows access |
There is no universal performance winner. NAS CPU, disks, network, signing/encryption, mount behavior, concurrent jobs, and archive compression all affect throughput. Measure your own full backup and restore time instead of copying a benchmark from unrelated hardware.
Preflight checklist before adding the share
- Create a dedicated backup share or export. Do not point Proxmox backups at a general family or office file share.
- Restrict access to the required Proxmox node addresses or a dedicated backup identity.
- Confirm DNS and time synchronization. Authentication and audit trails become harder to diagnose when hosts disagree about names or time.
- Set a storage quota or monitoring threshold so failed retention cannot consume the whole NAS.
- Document who can delete backups. A backup writable by every normal account is vulnerable to accidental deletion and ransomware.
- Decide how you will restore if the original Proxmox node is unavailable. Keep the NAS address, export/share name, credential recovery process, and any encryption key outside the failed host.
Add NFS storage safely
In the Proxmox interface, open Datacenter → Storage → Add → NFS. Enter a stable storage ID, the NAS server address, and the exported path. Limit Content to VZDump backup file unless the share has another deliberate purpose. Select only the nodes that should use it.
Before scheduling jobs, create a small test backup. If the export is visible but writes fail, check the NAS export allowlist, filesystem ownership, root-mapping behavior, and whether the Proxmox node is reaching the expected NAS address. Do not fix an NFS permission problem by opening the export to every client.
Add SMB/CIFS storage without weakening security
Open Datacenter → Storage → Add → SMB/CIFS, give the storage a stable ID, enter the server and share, then use a dedicated backup identity with only the permissions it needs. Again, limit the content type to VZDump backup files.
When SMB fails, capture the exact error before changing policy. Verify the username format, share name, NAS ACL, DNS resolution, protocol support, and whether the server requires signing. Microsoft explains that SMB signing protects integrity and helps prevent relay and spoofing attacks. Disabling signing or enabling SMB1 may make an old device connect, but it is not a safe general fix. Escalate incompatible NAS firmware instead of quietly reducing the security baseline.
Create the backup job
Go to Datacenter → Backup and create a job that targets the NAS storage. Start with one noncritical VM or container. Set the selection scope, schedule, compression, retention, and notification behavior deliberately. Snapshot mode is convenient, but application-consistent recovery may still require guest-agent support or application-specific backup steps.
| Check | Pass condition | Evidence to keep |
|---|---|---|
| Storage connection | Share is active on every intended node | Storage status and node list |
| First backup | Task ends OK and archive appears on NAS | Task log, archive timestamp, archive size |
| Retention | Old archives are pruned according to policy | Job configuration and free-space trend |
| Notification | A forced failure produces an alert | Alert message and recipient |
| Restore | Isolated restored guest boots and critical service starts | Restore log and validation notes |
The restore test that proves the backup
Choose a recent backup of a noncritical guest and restore it with a new VM or container ID. Restore to storage with enough free capacity and keep the network interface disconnected or isolated until you avoid duplicate IP addresses, hostnames, and scheduled jobs. Confirm that the restore task completes, the guest boots, the filesystem is readable, and the application or service you actually care about starts.
Record restore duration and any manual steps. If recovery depends on a password, NAS setting, encryption key, or undocumented network path that exists only in one administrator's memory, the recovery plan is not finished. For Proxmox Backup Server, use its verification facilities as an additional integrity check, but still perform periodic restores.
Symptoms, evidence, and safe troubleshooting
| Symptom | Evidence to collect | Safe next check |
|---|---|---|
| Storage shows inactive | Exact task error, DNS result, route, NAS service status | Confirm server address and protocol service before changing permissions |
| NFS mounts but backup cannot write | Export rule, client address, directory owner, root mapping | Test a dedicated export with scoped access |
| SMB authentication fails | Username format, NAS audit log, dialect/signing error | Correct identity or firmware; do not enable SMB1 |
| Backup succeeds but restore fails | Restore task log, target free space, archive availability | Repeat with a known-small guest and separate target storage |
| Jobs become slow | NAS latency, disk utilization, network errors, concurrent jobs | Test one job at a time before changing MTU or compression |
Rollback and safety notes
If the new NAS storage is unreliable, disable or retarget the backup job first. Do not delete the storage definition while a job is running. Removing a Proxmox storage entry should not be treated as deleting the backup data, and deleting NAS directories should never be part of a connection rollback. Preserve at least one known-good previous backup target until the new target has passed a restore test.
Escalate when errors suggest filesystem corruption, repeated NAS disconnects, unexplained archive changes, failed verification, credential exposure, or recovery-key loss. Security bypasses, broad export permissions, fixed jumbo-frame advice, and blanket firewall changes are not acceptable substitutes for evidence.
Final operating decision
Use NFS for a straightforward Linux-first Proxmox-to-NAS path with tightly scoped export rules. Use SMB when named credentials and Windows-compatible administration are operational requirements. If you need deduplication, incremental transfer, verification jobs, datastore permissions, and sync workflows, evaluate Proxmox Backup Server rather than stretching a direct VZDump share into a role it was not designed to fill.
The completion condition is not “the scheduled task is green.” It is: the backup is present, retention and alerts work, the recovery information is stored outside the original host, and an isolated restore has booted successfully.
Comments
Post a Comment