Backing Up and Migrating Proxmox VMs and LXCs to NFS

After building my new three-node Proxmox cluster, I needed a practical way to protect the virtual machines and LXC containers stored on each node’s local LVM-Thin storage.

My goal was simple:

Proxmox node
    ↓
Full vzdump backup
    ↓
Shared TrueNAS NFS storage
    ↓
Restore on any cluster node

The TrueNAS dataset, NFS user, permission mapping and export configuration are already covered in my earlier article:

TrueNAS NFS on Proxmox — Mounting a Share and Passing it into LXC Containers

This follow-up focuses on the Proxmox side: adding the backup storage, choosing the correct backup mode, configuring notes and retention, restoring guests, and using backup and restore as a migration method.

The backup design

My Proxmox nodes use local storage for active workloads:

local-lvm

The backup files are written to a separate NFS share:

TN-NFS-BU

The resulting layout is:

pve-hp01 ─┐
pve-hp02 ─┼── Full backups ──> TrueNAS NFS
pve-hp03 ─┘                    └── dump/

This provides one shared backup location that can be accessed by all cluster nodes.

It is important to understand that this is not high availability. A failed guest does not restart automatically from its backup. The backup must first be restored onto an available node.

Adding the NFS backup storage to Proxmox

Once the TrueNAS NFS export has been prepared, open:

Datacenter
└── Storage
    └── Add
        └── NFS

Example configuration:

ID:       TN-NFS-BU
Server:   192.1.178.5
Export:   /mnt/WD16TB/pve-backups
Content:  Backup
Enabled:  Yes

I selected only the content type:

Backup

This prevents active VM disks, containers, ISO images or templates from being placed accidentally on a storage target intended only for backups.

The resulting storage configuration looks similar to:

nfs: TN-NFS-BU
        export /mnt/WD16TB/pve-backups
        path /mnt/pve/TN-NFS-BU
        server 192.1.178.5
        content backup

Because Proxmox stores this definition in /etc/pve/storage.cfg, it is distributed automatically across the cluster. However, every node still mounts the NFS export independently, so the TrueNAS share must authorize every Proxmox node that uses it.

Verify the storage

Run this on each Proxmox node:

pvesm status

The storage should report:

TN-NFS-BU    nfs    active

Proxmox mounts it under:

/mnt/pve/TN-NFS-BU

For backup content, Proxmox creates the normal directory:

/mnt/pve/TN-NFS-BU/dump

A quick write test is:

touch /mnt/pve/TN-NFS-BU/write-test
rm /mnt/pve/TN-NFS-BU/write-test

If Proxmox reports that it cannot create the dump directory, the problem is normally on the TrueNAS side: the mapped NFS account does not have write permission on the dataset. The dataset ownership and Mapall configuration are explained in the earlier TrueNAS NFS article.

Creating a manual backup

Select a VM or LXC in the Proxmox interface:

Guest
└── Backup
    └── Backup now

Choose:

Storage:      TN-NFS-BU
Mode:         Snapshot or Stop
Compression:  ZSTD

An LXC backup produces a file such as:

vzdump-lxc-201-2026_08_05-09_04_07.tar.zst

A VM backup produces a file such as:

vzdump-qemu-301-2026_08_05-10_15_00.vma.zst

The filename identifies:

the guest type
the VMID
the date
the time

The guest name is stored as metadata rather than included in the filename.

Snapshot versus stop mode

Snapshot mode

Snapshot mode keeps the guest running while Proxmox creates the backup.

Use it for normal scheduled backups where downtime should be avoided.

Advantages:

no planned shutdown
suitable for most routine backups
the resulting archive is independently restorable

The backup represents a running system. Applications such as databases may therefore need to replay journals or transaction logs after a restore, similar to recovering from an unexpected restart.

Stop mode

Stop mode shuts down the guest, creates the backup and starts it again afterward.

Use it when:

downtime is acceptable
maximum consistency is more important than availability
creating the final backup before a migration
preparing to delete or reinstall the source node

The disadvantage is that the guest remains offline for the duration of the backup.

Practical choice

For my setup:

Normal scheduled backup     → Snapshot
Final migration backup      → Stop
Important pre-upgrade copy  → Stop

For databases, a Proxmox backup should ideally be complemented by an application-native backup such as pg_dump or mariadb-dump.

Snapshot mode still creates a full backup

The term snapshot describes how Proxmox reads the guest while creating the backup.

It does not mean incremental.

With normal NFS storage, both of these are full backups:

Snapshot mode → Full vzdump archive
Stop mode     → Full vzdump archive

Each backup file is self-contained and can be restored independently.

For example:

Monday     vzdump-lxc-201-....tar.zst
Tuesday    vzdump-lxc-201-....tar.zst
Wednesday  vzdump-lxc-201-....tar.zst

The Wednesday backup does not require the Monday or Tuesday file.

Incremental and deduplicated backups require Proxmox Backup Server. Traditional vzdump files written to NFS are full backups.

What is included?

An LXC backup normally includes:

container configuration
root filesystem
installed packages
application configuration
container users and permissions
included Proxmox-managed volumes

A VM backup normally includes:

VM configuration
included virtual disks
EFI and TPM state disks where configured
cloud-init disk where relevant

External data is different.

For example:

LXC
├── /etc
├── /var/lib/application
└── /mnt/media  → TrueNAS bind mount

The container backup includes the container-owned data, but not the content of the external TrueNAS bind mount.

The mount definition may remain in the container configuration, but the actual files must be protected through TrueNAS snapshots, replication or another backup method. This behaviour is also described in the earlier NFS and LXC article.

Add useful backup notes

The standard filename does not include the guest name:

vzdump-lxc-201-2026_08_05-09_04_07.tar.zst

Use the Notes template field instead:

{{guestname}} - {{node}} - VMID {{vmid}}

Example result:

LXC-Ansible - pve-hp01 - VMID 201

This keeps the standard filename while making the backup easy to identify in the Proxmox GUI.

Avoid manually renaming the archive because Proxmox expects the normal vzdump naming format.

What does Protected mean?

A backup marked as Protected is excluded from normal Proxmox deletion and pruning.

Useful examples include:

the final backup before a migration
a known-good baseline
a backup before a major upgrade
the last copy before removing a node

Protected does not mean that the backup is:

encrypted
immutable on TrueNAS
replicated
safe from manual deletion outside Proxmox

It only prevents routine removal through Proxmox until the protection flag is removed.

Configure retention

Full backups consume storage quickly, so retention should be configured from the beginning.

A simple policy is:

Keep last: 7

A more balanced policy could be:

Keep last:     3
Keep daily:    7
Keep weekly:   4
Keep monthly:  6

Retention can be configured at the storage level or inside an individual backup job.

For test guests, a small policy such as keep-last=3 may be enough. More important services can retain daily, weekly and monthly restore points.

Protected backups are kept separately from the normal pruning rotation.

Scheduled backup job

Open:

Datacenter
└── Backup
    └── Add

Example:

Node:            All
Storage:         TN-NFS-BU
Schedule:        03:00
Selection mode:  All
Mode:            Snapshot
Compression:     ZSTD
Retention:       Keep last 7

For larger environments, stagger the jobs to avoid every node reading local disks and writing to TrueNAS at the same time.

For example:

01:00  Infrastructure LXCs
02:00  Application LXCs
03:00  Virtual machines

Restoring an LXC or VM

Open the backup storage:

Datacenter
└── TN-NFS-BU
    └── Backups

Select a backup and click:

Restore

Choose:

Target node:     pve-hp01, pve-hp02 or pve-hp03
Target storage:  local-lvm
VMID:            Original or new ID

Using a new VMID is useful for testing:

Original guest:  201
Test restore:    901

Before starting the restored guest, check:

IP address
hostname
MAC address
network bridge
external mounts
bind-mount source paths
passthrough devices
application ports

Do not start the original and restored guest simultaneously if they use the same network identity.

Using backup and restore for migration

Backup and restore is also a practical migration method, especially when the guests use local LVM-Thin storage.

Although each node has storage named:

local-lvm

these are separate physical thin pools:

pve-hp01/local-lvm
≠
pve-hp02/local-lvm
≠
pve-hp03/local-lvm

This is why a cross-node clone may fail with:

can't clone CT to node 'pve-hp03'
CT uses local storage

The reliable migration workflow is:

Source guest
    ↓
Stop-mode backup to TN-NFS-BU
    ↓
Restore on target node
    ↓
Verify application
    ↓
Remove original guest

Migration procedure

Shut down or use Stop mode for the final backup.
Store the backup on TN-NFS-BU.
Restore it onto the target node and local-lvm.
Verify network settings and external mounts.
Start and test the restored guest.
Keep the backup until the migrated guest has operated successfully.
Remove the old guest only after verification.

The same-cluster Migrate function may also copy a guest between local storages. However, migration moves the workload; it does not create a retained recovery copy.

I therefore prefer to create a backup before any direct migration.

Backup versus migration

Backup and restore	Direct migration
Creates a retained recovery copy	Does not create a backup
Works well between local storages	Copies storage directly
Can restore onto another node later	Intended to move the current guest
Makes test restores easy	Usually faster
Suitable across independent hosts	Normally used inside one cluster
Usually more downtime	May reduce downtime

For my initial cluster migration, backup and restore was slower but easier to verify and provided a rollback copy at the same time.

Final checks

After creating the backup system, verify:

pvesm status

Then perform at least one test restore.

A successful backup task confirms that an archive was created.

A successful restore confirms that the backup is useful.

Final design

Proxmox cluster
├── pve-hp01
├── pve-hp02
└── pve-hp03
        │
        │ Full vzdump backups
        ▼
TrueNAS NFS
└── pve-backups
    └── dump/

The active guest disks remain on each node’s local LVM-Thin storage. TrueNAS provides a shared backup location from which any guest can be restored onto any cluster node.

The most important lessons were:

NFS vzdump backups are full backups.
Snapshot mode does not mean incremental.
Stop mode is useful for a final migration copy.
External bind-mounted data is not included automatically.
Backup notes are better than changing archive filenames.
Protected backups are excluded from routine pruning.
Retention should be configured before storage fills up.
Migration is not a replacement for backup.
The backup process should always be tested with a real restore.