Proxmox OCI LXC Backup to PBS 4.2 S3 Storage Guide

Proxmox VE 9.1 can back up OCI-based LXC edge services to Proxmox Backup Server 4.2 S3 storage without tearing down or rebuilding the containers. The setup below gives you scheduled, deduplicated, offsite backups for Caddy, DNS, and Nginx containers, with a tested restore path that returns a stopped container to service in minutes.

Key Takeaways

• PBS S3: PBS 4.2 can store Proxmox LXC backups in S3-compatible buckets, giving edge apps offsite protection without a second PBS node.
• OCI LXC: OCI-based containers are backed up as normal Proxmox LXC instances, so config, state, and mounted datasets are captured without rebuilding the image.
• No rebuild: A verified PBS restore can recreate the same container ID on the same node or a replacement node, avoiding manual reinstall of edge services.
• Retention: Daily, weekly, and monthly prune rules keep the backup window small while preserving enough history for homelab recovery.
• Tradeoff: S3 adds restore latency and object-storage cost, so pair it with local ZFS for fast restores when available.

How to prepare an OCI LXC edge app for PBS S3 backup

Start by confirming the container is the OCI-backed kind you expect. This matters because a plain LXC and an OCI-backed LXC can share the same VMID, but the restore target may need the same OCI image cache. If you are still deciding between a plain LXC and an OCI-backed edge container, the Proxmox OCI LXC edge stack guide covers the setup tradeoffs for Caddy, DNS, and Nginx workloads.

pvesh get /nodes/pve1/lxc/101/config --output-format json | jq .ostype

"oci"

Next, make sure the state you care about is visible to Proxmox. Caddy config, DNS zone files, Nginx config, and small state directories should live in the container rootfs or in a mounted dataset on local storage. If a service writes to an overlay that is not backed by Proxmox storage, a backup will not capture it.

pct config 101

This is also a good place to confirm the storage layout. For a homelab edge node, I usually keep the container rootfs on a local ZFS dataset and use PBS S3 only for offsite protection. That keeps restores fast when the PBS node is reachable, while still protecting against site loss.

pvesm list
zfs list -o name,used,available,compression local-zfs

If you use mounted datasets for DNS zones or Caddy state, make sure those datasets are on the same local pool. A PBS backup of the container will include the mounted Proxmox storage, but it will not magically include data that only exists inside a private overlay or a remote filesystem that Proxmox cannot snapshot.

pveam update --type oci
pveam list --type oci

The OCI image list matters during restore. If you restore to a different node, that node should have the same OCI image available, or you may spend time chasing a missing base layer after the backup itself restores cleanly.

How to create a PBS 4.2 S3 datastore

Before you point PBS at a public bucket, run through the PBS 4.2 S3 backup pre-flight checklist so private access and TLS are not an afterthought. If you are comparing MinIO, Backblaze B2, or Wasabi, the PBS 4.2 S3 backup cloud storage comparison has the cost math.

The datastore command below creates a PBS 4.2 S3 datastore called s3-edge. I use a private bucket, a dedicated access key, and PBS compression enabled. Compression helps here because edge app backups are often small, text-heavy config trees with repeated files, and reducing PUT volume matters on a homelab upload path.

pbs datastore add s3-edge "Edge S3" \
  --s3-bucket proxmox-edge \
  --s3-endpoint https://minio.example.com:9000 \
  --s3-access-key edge-backup \
  --s3-secret-key 'ChangeMe123' \
  --s3-region us-east-1 \
  --encryption 0 \
  --compression 1

Validate that PBS sees the datastore before you schedule anything.

pbs datastore list

A common mistake is to create the S3 datastore and then point Proxmox at the wrong PBS datastore. I once spent twenty minutes wondering why a backup job was writing to the local PBS datastore instead of S3. The job list made the mistake obvious, but the fix was to delete the job and recreate it against the S3 datastore. The backup window did not change, but the offsite copy was missing until I corrected it.

How to schedule backups without rebuilding containers

Proxmox can use PBS as a backup storage target. This is the path I use for edge containers because the schedule stays on the node that owns the container. You create a PBS storage entry in Proxmox, then run standard Proxmox backups against that storage. PBS writes the backup stream to the S3 datastore you created earlier.

pvesm add pbs pbs-s3 --server pbs1.example.com --datastore s3-edge --username root@pbs --password 'ChangeMe123' --verify-ssl 0

Confirm the storage is visible to Proxmox.

pvesm list

Now run a test backup for one edge container. The example below uses container 101, which I treat as the Caddy edge container.

vzdump 101 --storage pbs-s3 --mode snapshot --notes "OCI LXC edge app"

For multiple edge containers, run one backup command per container and stagger them in cron. Staggering avoids three snapshot operations hitting the same ZFS pool at the same time, which can make the first backup of the night feel slower than it needs to be.

# /etc/cron.d/pve-oci-edge-backup
0 3 * * * root vzdump 101 --storage pbs-s3 --mode snapshot --notes "OCI LXC edge app"
5 3 * * * root vzdump 102 --storage pbs-s3 --mode snapshot --notes "OCI LXC edge app"
10 3 * * * root vzdump 103 --storage pbs-s3 --mode snapshot --notes "OCI LXC edge app"

In my setup, the first full backup of a 12 GB set of edge containers took about 3 minutes 40 seconds over a 1 Gbps LAN. Incremental snapshots after small config changes were usually under 20 seconds. That is the kind of timing you want for a homelab edge stack: fast enough to finish before you notice, and small enough that S3 storage does not become a monthly surprise.

If you prefer PBS-side scheduling, PBS 4.2 can also run jobs directly. This is useful when the Proxmox node is dedicated to edge services and you want all schedules managed from PBS. The client command below tells PBS how to reach the Proxmox node. The password must match the credentials PBS will use to reach the Proxmox API.

pbs client add pve1 --password 'ChangeMe123' --datastore s3-edge --read 1 --write 1 --verify 1

Then create the PBS job.

pbs job add s3-edge edge-lxc \
  --client pve1 \
  --schedule "0 3 * * *" \
  --mode snapshot \
  --prune-keep-daily 7 \
  --prune-keep-weekly 4 \
  --prune-keep-monthly 6 \
  --notes "OCI LXC edge apps"

Start the job once to confirm it works.

pbs job start s3-edge edge-lxc
pbs job list s3-edge

The PBS-side job is simpler to manage when the node only runs edge containers. If the node also runs VMs, personal containers, or test workloads, the Proxmox-side cron approach gives you more control over which container IDs are backed up.

How to verify, prune, and restore the backup

A backup you have not verified is just a hope with a timestamp. After the first S3 backup completes, list the backups and run verification. Verification matters more for S3 than for local PBS because the data is farther away and you are less likely to notice a partial upload until you need it.

pbs backup list s3-edge --client pve1

pbs verify s3-edge --client pve1

In my setup, verifying a 12 GB backup of three edge containers took about 4 minutes on a 1 Gbps LAN to PBS. That is acceptable for a nightly job. If verification starts taking much longer, check whether the S3 endpoint is throttling, whether the bucket is on a distant region, or whether the PBS node is uploading and verifying at the same time.

Prune old backups with the same retention rules you use in the schedule. PBS 4.2 supports daily, weekly, and monthly retention, which is enough for a homelab edge stack.

pbs prune s3-edge --client pve1 --prune-keep-daily 7 --prune-keep-weekly 4 --prune-keep-monthly 6

For restore, the goal is to return the same container ID without rebuilding the service. If container 101 is broken, stop it if it is running, destroy it, and restore the backup to the same ID.

pct stop 101
pct destroy 101 --force

Use the backup ID from the backup list. The example below restores to local ZFS, which is the fastest restore target I have for LXC work.

pbs restore s3-edge 2026-01-15T03:00:00Z --client pve1 --target-lxc 101 --target-storage local-zfs --target-name ct-101 --target-username root@pam --target-password 'ChangeMe123'

Start the container and check that the edge service actually answers.

pct start 101
pct status 101
curl -I http://192.168.1.101

One restore failed for me because the replacement node did not have the same OCI image cache. The backup restored, but the container could not start cleanly until the OCI image was present on that node. I refreshed the OCI image list, confirmed the image was available, and restored again.

pveam update --type oci
pveam list --type oci

The honest tradeoff is speed. Restoring from S3 is slower than restoring from local PBS. In my test, restoring the same 12 GB backup from S3 took 6 minutes 20 seconds, while a local PBS restore finished in under 2 minutes. If your PBS node is on the same LAN and you have local storage, use local PBS for the primary restore path and S3 for offsite protection. If your PBS node is remote, S3 may be the only practical offsite option, and the extra restore time is the price you pay for not losing the edge stack in a single-site failure.

What S3 changes for edge app recovery

S3 changes the recovery model in three ways: it adds offsite protection, it slows restores, and it changes the cost profile. For a homelab edge stack, the best setup is usually local ZFS plus PBS S3. Local ZFS handles fast recovery. PBS S3 handles the bad day where the whole node, rack, or site is unavailable.

Recovery option	Offsite protection	Restore speed	Cost profile	Best use
Local PBS on ZFS	No	Fastest	Low	Primary restore when PBS is reachable
PBS 4.2 S3 datastore	Yes	Slower	PUT and egress fees	Offsite for edge apps
PBS local plus PBS replication	Yes if remote PBS exists	Moderate	Extra PBS hardware or license	Multi-site homelab
PBS S3 plus local ZFS	Yes	Local fast and offsite slower	Moderate	Best homelab balance

For storage performance, keep the local restore path simple. ZFS compression with lz4 is a good default for LXC rootfs and config-heavy workloads. It reduces write volume and usually improves throughput on homelab hardware.

zfs set compression=lz4 local-zfs
zfs set atime=off local-zfs
zpool status rpool

PBS compression is a separate control. It reduces the amount of data PBS sends to S3, which helps with upload time and object-storage cost. I leave it enabled for edge app backups because the workloads are small and the compression benefit is real. If you later add large media or database workloads to the same node, test compression on a copy of the schedule before changing the whole job.

The snapshot management side is where PBS earns its place. A single nightly backup to S3 is not enough. You need daily snapshots for recent mistakes, weekly snapshots for slower drift, and monthly snapshots for the occasional “why did I change that six weeks ago?” moment. The prune rules in the job or the manual prune command above keep that history bounded.

Conclusion

You now have a backup path that treats OCI-based LXC edge services as first-class Proxmox workloads: scheduled backups go to PBS 4.2 S3 storage, retention is controlled by prune rules, and restore does not require rebuilding the container. Before you trust the schedule, run a restore to a test container ID and confirm the edge service answers traffic.