Proxmox VE Post-Install: Containers, Virtual Machines, Snapshots, and Automated Backups

Logging into the Proxmox VE dashboard at https://<your-ip>:8006 provides a clean node with default storage pools and network bridge vmbr0. Before deploying services, establish three baseline practices: choose the right virtualization method for each workload, take snapshots before configuration changes, and schedule automated backups to external storage.

LXC Containers vs. Virtual Machines: Choosing Your Workload #

Proxmox VE supports two virtualization technologies: Linux Containers (LXC) and Kernel-based Virtual Machines (KVM).

Linux Containers (LXC) #

LXC containers share the host Linux kernel, running isolated user spaces without emulating hardware. A base Debian or Alpine container idles at 30 to 50 MB of RAM and boots in two seconds.

Use LXC for standard Linux network services and lightweight applications:

• Network infrastructure: Pi-hole, AdGuard Home, or Unbound.
• Reverse proxies: Nginx Proxy Manager, Caddy, or Traefik.
• Single-purpose apps: Vaultwarden, Miniflux, or Uptime Kuma.

Proxmox creates unprivileged containers by default. Container root (UID 0) maps to an unprivileged host UID (100000), preventing host root compromise if a container is breached. Keep containers unprivileged unless a workload requires direct host hardware access.

To create an LXC container from the command line, update the appliance catalog and find available Debian templates:

pveam update
pveam available --section system | grep debian-12-standard

Download the template to your local storage using the filename from your search:

pveam download local debian-12-standard_12.7-1_amd64.tar.zst

Create and start the container:

pct create 100 local:vztmpl/debian-12-standard_12.7-1_amd64.tar.zst \
  --hostname pihole \
  --cores 1 \
  --memory 1024 \
  --swap 512 \
  --rootfs local-lvm:8 \
  --net0 name=eth0,bridge=vmbr0,ip=dhcp \
  --unprivileged 1 \
  --password
pct start 100

(Note: Replace local-lvm:8 with local-zfs:8 if you installed Proxmox on ZFS, and substitute vmbr0 if your host uses a different network bridge. Ensure the vztmpl path matches the downloaded template filename. The --password flag prompts for an interactive root password).

To open a root shell in the container from the host CLI without entering a password:

pct enter 100

Virtual Machines (KVM) #

Virtual machines virtualize complete hardware, including BIOS, CPU, storage controllers, and network devices. The guest runs its own independent kernel.

Use virtual machines for:

• Non-Linux operating systems: Windows Server, FreeBSD, TrueNAS CORE, or OPNsense.
• Dedicated Docker hosts: Docker inside unprivileged LXC requires nested virtualization (nesting=1, keyctl=1) and frequently triggers overlay2 conflicts with ZFS and UID mapping. A minimal Linux VM avoids storage driver headaches and bind-mount permissions.
• Appliances: Home Assistant OS (HAOS) and similar images designed for full hardware abstraction.
• PCIe passthrough: passing a GPU or HBA directly to a guest.

Using Snapshots for Safe Maintenance #

A snapshot captures the exact storage state of a container or virtual machine, plus optional RAM state for running VMs.

Snapshots provide quick rollback points. Before running distribution upgrades (apt update && apt dist-upgrade), editing network files, or tweaking databases, take a snapshot. If an upgrade breaks a service, you can revert disk state in seconds.

To snapshot an LXC container:

pct snapshot 100 pre_upgrade_baseline --description "Before system package upgrades"

To revert:

pct rollback 100 pre_upgrade_baseline

For virtual machines, use qm:

qm snapshot 101 pre_kernel_upgrade --description "Before custom kernel testing"
qm rollback 101 pre_kernel_upgrade

(Note: Proxmox snapshot names must start with a letter and contain only alphanumeric characters and underscores [a-zA-Z0-9_]. Hyphens are not permitted in snapshot identifiers).

Snapshots rely on copy-on-write pointers on the same underlying pool (local-lvm or local-zfs) as the active disk. If that physical drive fails, the disk and snapshots are lost together. Snapshots protect against bad updates; external backups protect against hardware failure.

Setting Up Automated 3-2-1 Backups with vzdump #

A reliable backup strategy follows the 3-2-1 rule:

1. Three copies of data: The production workload and two independent backup archives.
2. Two different media: The hypervisor host drive and an external target, such as an NFS or SMB/CIFS share on a NAS.
3. One offsite copy: An offsite destination, such as a remote Proxmox Backup Server (PBS) instance or encrypted cloud sync.

1. Add External Storage #

Never save scheduled backups to the drive hosting your Proxmox installation. Connect an external storage target:

1. In the web interface, navigate to Datacenter -> Storage -> Add.
2. Select NFS, SMB/CIFS, or Directory (for a second physical drive).
3. Under the Content dropdown, select VZDump backup file.

2. Configure the Automated Backup Schedule #

vzdump creates standalone compressed archives of containers and virtual machines.

To configure an automated schedule:

1. In the web interface, navigate to Datacenter -> Backup -> Add.
2. Storage: Select your external target (such as backup-nfs).
3. Selection Mode: Choose All guests or pick specific VM and container IDs.
4. Schedule: Pick an off-peak maintenance window, such as daily at 02:00 (0 2 * * *).
5. Mode: Select Snapshot for live read-only backups with zero guest downtime.
6. Compression: Select ZSTD for fast multi-threaded compression with low CPU overhead.
7. Retention (Prune Settings): Set your retention policy. A practical baseline is keep-daily=7 and keep-weekly=4.

To test the backup job from the command line immediately:

vzdump 100 --storage backup-nfs --mode snapshot --compress zstd --prune-backups keep-daily=7,keep-weekly=4

vzdump freezes guest filesystem writes, snapshots the underlying storage, compresses the archive directly to your external share, and prunes older archives according to your retention rules.

What to Do Next #

Once base workloads, snapshots, and backup schedules are active:

• Set static DHCP reservations in your router for each guest MAC address so hostnames and IP addresses remain predictable.
• Install the QEMU Guest Agent inside virtual machines (apt install qemu-guest-agent, then systemctl enable --now qemu-guest-agent) and toggle VM -> Options -> QEMU Guest Agent to enabled. Power the VM completely off and start it again so Proxmox attaches the virtual serial communications channel. The agent allows Proxmox to coordinate clean filesystem freezes during snapshots and backups.
• Practice restoring from backup. Create a throwaway container, back it up to your external storage, delete the container, and restore it (under your storage’s Backups tab in the web GUI or with pct restore). Verifying your restore workflow now ensures your recovery works when hardware fails later.