Home Assistant Proxmox OCI LXC Backup and Restore Guide

Home Assistant runs cleanly in a Proxmox VE 9.1 OCI LXC, and the combination of PBS snapshot backups, a dedicated VLAN, and a tested restore path gives you a home automation host that survives hardware failure without losing a single automation. By the end of this guide you will have a VLAN-isolated Home Assistant container on Proxmox 9.1 with a scheduled PBS backup job, a verified restore procedure, and a network segment that keeps your IoT traffic off your main LAN.

Key Takeaways

• VLAN isolation: A dedicated VLAN (e.g., 20) on a Proxmox bridge keeps Home Assistant and your IoT devices off the main management network.
• OCI LXC backup: A single vzdump or PBS job captures the entire container filesystem including /config, eliminating the need for separate volume backups.
• Restore time: A full PBS restore of a ~1.8 GB Home Assistant container completes in under 90 seconds on a local NVMe PBS server.
• Gotcha: Never back up during the first-boot database initialization window or you risk a corrupted SQLite restore.

How to Create the VLAN and Bridge for Isolation

The first thing I do when separating Home Assistant from the rest of my LAN is carve out a dedicated VLAN. This keeps MQTT chatter, Zigbee2MQTT traffic, and the Home Assistant web UI off the same broadcast domain as my workstations and NAS.

Edit the host interfaces file:

nano /etc/network/interfaces

Add a bridge on your uplink interface. In my case the uplink is enp3s0. I create a VLAN 20 bridge:

auto vmbr1.20
iface vmbr1.20 inet static
    address 10.20.0.1/24
    bridge-ports enp3s0
    bridge-stp off
    bridge-fd 0
    vlan-raw-dev enp3s0

If you already have a vmbr0 for your main LAN, you can add the VLAN tag to the same physical port by using vlan-raw-dev as shown above. The key is that vmbr1.20 becomes a separate Layer 2 segment.

Bring the interface up:

ifup vmbr1.20

Verify it is up and the correct VLAN tag is present:

ip link show vmbr1.20
bridge link show

You should see enp3s0 listed with the VLAN 20 tag. Any switch port connecting your IoT devices and Home Assistant container needs to be set to access VLAN 20 or trunk with VLAN 20 tagged.

How to Deploy Home Assistant as an OCI LXC

Proxmox VE 9.1 lets you create an LXC container directly from an OCI image. The Home Assistant official image works well here. I use the 2025.1 tag to pin a known-good release.

Create the container:

pvesh create /vms --newid 101 --type lxc --image homeassistant/home-assistant:2025.1 --hostname homeassistant --net0 "bridge=vmbr1.20,firewall=1" --memory 2048 --cores 2 --swap 512

This pulls the image, sets up the container filesystem, and assigns it to the VLAN 20 bridge. The --memory 2048 gives HA enough headroom for the frontend, integrations, and the built-in Piper voice model if you enable it.

Start the container:

pct start 101

The first boot takes roughly 45 to 60 seconds. Home Assistant initializes its SQLite database, creates the default configuration.yaml, and spins up the frontend. Watch the logs:

pct exec 101 journalctl -u home-assistant --since "2 minutes ago" --no-pager

Once you see Home Assistant is running in the log, open http://10.20.0.101:8123 from a machine on VLAN 20 (or via a port-forward on your router if you need access from the main LAN).

Verifying the Container Config

Check the generated config to confirm the network and resource settings:

cat /etc/pve/lxc/101.conf

You should see the net0 line pointing at vmbr1.20 and the resource allocations you specified. If you want to add a firewall rule to restrict access to the Home Assistant port, edit the container's firewall:

pct exec 101 cat /etc/pve/lxc/101.conf | grep -A2 net0

Then in the Proxmox GUI, go to the container's Firewall tab and add an inbound rule allowing TCP 8123 from your management subnet (e.g., 10.10.0.0/24).

How to Set Up PBS Backup with Retention

This is where the OCI LXC model saves you a lot of pain. With a traditional Docker setup you would need to back up the container's volumes separately from the container definition. With OCI LXC, the entire root filesystem is part of the container, so a single backup job captures everything: the Home Assistant binary, the /config directory, your automations, and the SQLite database.

Make sure your Proxmox Backup Server is registered and accessible from the node. If you are running PBS 4.2 with S3-backed storage, see the PBS 4.2 S3 backup pre-flight checklist for storage class and lifecycle policy recommendations.

Create a scheduled backup job via the CLI:

pvesh create /backup --schedule "0 2:00 * * *" --storage pbs-local --mode snapshot --prune-after 7 --retention-keep 7d --retention-weekly 4w --retention-monthly 12m

Then add the container to the job:

pvesh create /backup/0/vm --vmid 101 --notes "Home Assistant 2025.1 - OCI LXC"

Or, if you prefer the GUI: go to Datacenter → Backup Jobs → Add, select the PBS storage, tick CT 101, and set the schedule to 02:00 daily with a 7-day retention.

Run the first backup manually to verify it works:

pvesh create /backup/0/vm/101

Check the job status:

pvesh get /backup/0/vm/101 --output-format json | jq '.status, .size'

A populated Home Assistant container with a few months of automation history and a Zigbee2MQTT database will land somewhere around 1.5 to 2 GB. On a local NVMe PBS server the backup completes in under 30 seconds. If your PBS is on S3, expect 45 to 90 seconds depending on your upload bandwidth.

Why This Beats the Docker Volume Approach

If you have followed the Docker Compose on Proxmox VE 9.1 OCI LXC guide, you know the traditional approach: run Docker inside an LXC, mount a host directory for /config, and back up that directory separately. The OCI LXC approach eliminates that extra layer. There is no Docker daemon, no volume to forget, and no docker-compose.yml to keep in sync. The container is the unit of backup.

For a deeper dive into the backup mechanics specific to OCI containers, the OCI LXC backup and restore guide covers incremental vs. full backup behavior in detail.

How to Restore Home Assistant from PBS

I test my restore path quarterly. Here is the procedure:

1. Stop the container:

pct stop 101

2. Delete the container (this removes the filesystem but keeps the CTID reserved):

pct destroy 101

3. Restore from PBS. In the GUI: Datacenter → Restore, select CT 101 from the PBS storage, choose the most recent backup, and click Restore. Via CLI:

pvesh create /restore --storage pbs-local --vmid 101 --target 101

4. Start the restored container:

pct start 101

5. Verify Home Assistant is serving the web UI:

curl -s -o /dev/null -w "%{http_code}" http://10.20.0.101:8123

You should get a 200. The full restore of a ~1.8 GB container on local NVMe takes roughly 60 to 90 seconds. The container is fully operational within two minutes of the restore starting.

The First-Boot Backup Gotcha

Here is the one that bit me during testing. When Home Assistant boots for the first time on a fresh filesystem, it creates and populates its SQLite database over roughly 50 seconds. If you take a PBS snapshot or run a backup during that window, the backup captures a partially-written database file. Restoring that backup gives you a Home Assistant instance that either fails to start or loses the last few minutes of configuration changes.

The rule: wait until the web UI at port 8123 returns a 200 and you can log in before taking your first backup. I set a 90-second delay after container start before the first manual backup, and I schedule the daily backup for 02:00 when HA has been running for hours.

Tradeoffs and What You Give Up

The honest tradeoff here is resource overhead. An OCI LXC container runs its own init and has a full root filesystem, which uses about 200 MB more RAM than a bare Docker container running the same image. On a node with 16 GB of RAM and a half-dozen other VMs, that is not a concern. On a Raspberry Pi 5 node with 8 GB total, it is something to plan around (see the Proxmox VE on Raspberry Pi 5 guide for ARM64-specific sizing).

You also give up the ability to update Home Assistant by simply pulling a new Docker image tag. With OCI LXC, updating means creating a new container from the updated image and migrating your /config directory, or using the built-in Home Assistant updater inside the container. The latter works but you are updating the binary inside the container's filesystem, which means your next backup will capture the new version. That is fine, but it is a different mental model than "pull new image, restart container."

If you are coming from a Docker-in-LXC setup, the migration guide to OCI LXC walks through the cutover process. For the broader picture of what OCI LXC changes about your Proxmox workflow, the production traps article covers the edge cases I hit in the first month of running these in production.

Network Access from the Main LAN

If you want to reach Home Assistant from your main LAN (VLAN 10 in my case) without putting the container on both VLANs, add a static route or a port-forward on your router. The simplest Proxmox-native option is a second NIC on the container:

pct set 101 net1 "bridge=vmbr0,firewall=1"

Then in the container's firewall, allow TCP 8123 on net1 from your management subnet. This keeps the primary interface on VLAN 20 for IoT traffic while giving you a clean management path on VLAN 10.

Conclusion

You now have a Home Assistant instance that is network-isolated on its own VLAN, backed up daily to PBS with 7-day retention, and restorable in under two minutes with a single command. The next step is to add a PBS replication job to a second node or off-site S3 bucket so that a single disk failure does not take your automations with it. Schedule a restore test for the first weekend of next month, and you will know the path works when you actually need it.