Container migration, backups, and security boundary · Proxmox VE

Why this matters in production

Containers are fast to provision and easy to migrate, but their security boundary is weaker than VMs. This lesson covers the operational practices and the honest security model.

Migration

Service impact possiblemove a container to another node— Both forms interrupt the container. --restart stops it, moves it and starts it; without a flag the container must already be stopped. Plan the downtime rather than discovering it.

set -euo pipefail
CTID=200
TARGET=pve-02

# Restart migration: PVE shuts the container down, moves it, starts it again.
# --timeout bounds how long it waits for a clean shutdown before forcing.
pct migrate "$CTID" "$TARGET" --restart 1 --timeout 180

# Offline migration of an already-stopped container.
# pct migrate "$CTID" "$TARGET"

pct config "$CTID" >/dev/null 2>&1 \
|| echo "container now lives on $TARGET"

Container migration is not VM live migration, and planning it as if it were causes outages

qm migrate --online moves a VM’s memory pages while the guest keeps running, and the guest experiences a pause measured in milliseconds. That is possible because the hypervisor owns the guest’s memory and can copy it.

A container’s state is not a memory image the host can hand over. It is processes with open file descriptors, sockets, namespaces and kernel objects on this host. Reproducing that on another host means checkpoint and restore, which is fragile for anything non-trivial. In practice a container migration is a restart migration: shut down, move the storage, start on the target.

The operational consequences:

Node evacuation is not transparent for containers. The procedure in node evacuation assumes guests move without service loss. Containers need their own line in the plan, with their downtime named.
HA failover restarts the container, which is true of VMs too, but for containers it is also true of planned maintenance.
The downtime is the container’s shutdown plus its start, which for a container running a database with a long flush is not small. Measure it once per workload rather than assuming seconds.

Backups

Containers are backed up with vzdump, the same tool used for VMs:

vzdump 200 --storage pbs-main --mode snapshot

The three modes, as the documentation describes them for containers:

Mode	What it does	Downtime	Needs
`stop`	Stops the container for the duration of the backup	The whole backup	Nothing
`suspend`	`rsync` copies the data to a temporary location, then the container is suspended and a second `rsync` copies changed files, then it resumes	The second rsync pass	Free space for the copy, in `--tmpdir`
`snapshot`	Suspends the container briefly to ensure consistency, takes a storage snapshot, archives the snapshot, deletes it	Seconds	A snapshot-capable backend

Two things about these modes that are commonly misstated

suspend mode does not use CRIU and does not checkpoint processes. It is two rsync passes with a suspend between them. That matters for planning: it needs temporary space roughly the size of the container’s data, and its downtime is however long the second pass takes - which on a container with many small files that change constantly can be much longer than expected.

snapshot mode is not zero-downtime either. The documentation is explicit that the container is suspended first, to ensure data consistency, before the storage snapshot is taken. The pause is short - seconds - but it is not nothing, and a latency-sensitive service will notice it.

If a workload genuinely cannot tolerate any pause, the answer is not a different vzdump mode. It is application-level backup from inside the container, or a VM with a guest agent doing an fsfreeze.

Restore:

Data-loss riskrestore a container— Restoring over an existing VMID destroys that container's current disks. Restore into a free ID unless you have deliberately decided otherwise.

set -euo pipefail
NEWID=210

# List what is actually available before choosing a snapshot.
pvesm list pbs-main --content backup | grep '/ct/'

pct restore "$NEWID" \
'pbs-main:backup/ct/200/2026-08-12T02:00:03Z' \
--storage local-zfs

pct start "$NEWID"
pct exec "$NEWID" -- systemctl --failed --no-pager

Security boundary — the honest version

LXC containers provide:

Visibility isolation (namespaces).
Resource isolation (cgroups).
Network isolation (per-interface firewall).

They do NOT provide:

Kernel isolation.
Hardware isolation.
Trust boundary against malicious code.

flowchart TB
  subgraph VM[KVM VM]
    V1[Separate kernel]
    V2[Hardware isolation]
    V3[Independent reboot]
  end
  subgraph CT[Container]
    C1[Shared kernel]
    C2[Namespace isolation]
    C3[Resource limits]
  end

When containers are appropriate

Use case	Container?
Linux service, trusted code	Yes
Multi-tenant SaaS with untrusted code	No — use VMs
Windows	No
Sensitive workloads (PCI, HIPAA)	Often no — check compliance
High-density micro-services	Yes (with nesting enabled)

Production considerations

What happens if a container is restored and the service comes up but behaves oddly?

Three causes account for nearly all of it, and they are distinguishable in about two minutes.

1. The data behind a bind mount is missing. The application finds an empty directory where its data should be. Many applications treat that as a first run and initialise fresh state, so there is no error - just a service with no history.

CTID=210
pct config "$CTID" | grep -E '^mp[0-9]+:'
pct exec "$CTID" -- sh -c 'for d in /data /srv /media; do [ -d "$d" ] && printf "%s: %s entries\n" "$d" "$(ls -A "$d" | wc -l)"; done'

2. Ownership is wrong after a privilege change. If the restore changed the privilege mode, files on volume mount points were ID-shifted and files on bind mounts were not. The service runs as an account that can no longer read its own data.

pct exec "$CTID" -- stat -c '%U:%G %n' /data

3. The network is not what the config says. The restore put the container on a node where the bridge means something else, so it has an address on the wrong network - or none. See the bridge-equivalence check in container networking and storage.

The general point: a container that starts is not a container that recovered. pct start returning zero tells you the kernel accepted the configuration and nothing about whether the workload is intact.

Verification that can fail

A green backup job proves a backup ran. These prove a container can be recovered from it.

Service impact possiblequarterly restore drill— Restores into a spare VMID on a test node. Uses a bridge that is deliberately isolated so the restored container cannot collide with the original on the network.

set -euo pipefail
SRC=200
DRILL=9200
SNAP='pbs-main:backup/ct/200/2026-08-12T02:00:03Z'

pct restore "$DRILL" "$SNAP" --storage local-zfs --unprivileged 1
pct set "$DRILL" --net0 name=eth0,bridge=vmbr-isolated,ip=192.0.2.50/24
pct set "$DRILL" --hostname "drill-$SRC"

pct start "$DRILL"
sleep 20

# The four checks that actually distinguish success from "it booted".
pct exec "$DRILL" -- systemctl is-system-running || true
pct exec "$DRILL" -- systemctl --failed --no-pager
pct exec "$DRILL" -- df -h /
pct exec "$DRILL" -- findmnt -no TARGET,SOURCE | grep -vE '^/(proc|sys|dev|run)'

# Time it, write the number in the runbook, then clean up.
pct stop "$DRILL"
pct destroy "$DRILL"

Record the elapsed time. That number, not an estimate, is the container’s contribution to your RTO, and it is the input the RPO/RTO work in RPO, RTO and dependency modelling needs.

Common mistakes

Treating containers as VMs in security reviews.
Running privileged containers without documented justification.
Forgetting to test container restores.
Planning a maintenance window on the assumption that containers live-migrate.
Believing suspend mode checkpoints processes, and sizing --tmpdir accordingly.
Restoring without checking whether the archive’s privilege setting is the one you want.

Key takeaways

Containers are fast and efficient; their security boundary is weaker than VMs.
Container migration is a restart migration: plan the downtime, do not assume a VM-style live move.
The three vzdump modes all pause the container; they differ in how long and in what they need.
Bind and device mount point contents are never in the backup.
A restore is verified by exercising the workload, not by the task turning green.

Knowledge check

Why this matters

Two beliefs about containers cause most of the operational surprises in this area, and both come from reasoning by analogy with VMs.

The first is that containers live-migrate. They do not, and the place this costs you is a planned maintenance window - the evacuation runs, the VMs move transparently, and every container on the node restarts. Nobody planned for that because nobody wrote down that containers behave differently, and the information was never surfaced by any tool.

The second is that a backup of a container is a backup of the container. It is a backup of the volumes PVE manages, which for a container with bind-mounted data can be a small fraction of what matters. The job is green, the archive is real, and the recovery is partial in a way that only becomes visible during a restore.

Both are cheap to defuse and only by writing something down: the measured downtime of a container migration for each workload, and the named mechanism that protects each bind mount. Neither fact is discoverable from the configuration, which is precisely why they belong in the runbook.