Skip to content

Storage and Backups

This page documents the verified storage targets and the practical restore path for the current infrastructure.

For the current disaster recovery procedure, use these runbooks first:

The older sections below remain useful background, but the scripted restore and backup paths above are the current operator entry points.

Minimal Documentation Backup

Use this backup when the goal is to preserve the documentation source and the shareable Proxmox/pfSense reference material without Git history or old logs. It is not a replacement for a Proxmox guest backup or a raw pfSense recovery export.

python3 scripts/create_minimal_docs_backup.py \
  /secure/backup/it-docs-minimal-YYYYMMDD.tar.gz

The archive contains:

  • MkDocs source, configuration, dependencies, and documentation assets
  • Proxmox and pfSense documentation
  • documentation maintenance and redaction scripts
  • the canonical redacted pfSense export, config.redacted.xml

The archive excludes:

  • .git, generated site/ output, caches, and .DS_Store
  • logs/, log/, *.log, and rotated log files
  • old archives and files ending in .bak, .old, or .tmp
  • duplicate XML exports and all raw, unredacted pfSense exports

Keep the raw pfSense export separately in restricted storage when disaster recovery requires a directly restorable configuration.

For a clean Proxmox installation that recreates guests instead of restoring their disks, start with the clean rebuild plan, then execute the pre-reinstall migration checklist.

Verified Storage Targets

Target Type Notes
local Proxmox directory storage ISO, template, and local backup storage
local-lvm LVM-thin VM and container disks
DIR01 Local Proxmox-backed storage Historical target; not present in pvesm status on July 1, 2026
network-backup-syn CIFS backup storage Historical target from 192.168.100.250:/vm_backup; not present in pvesm status on July 1, 2026
media CIFS share Historical target from 192.168.100.250:/homes subdir /dorothea/Drive; not present in pvesm status on July 1, 2026

What Is Known

  • Proxmox also has local storage available for backup and template use
  • Docker stack configuration lives on the Docker host under /root/<project>
  • The pfSense configuration can be exported and redacted before sharing or archiving

What Still Needs Verification

  • Exact Proxmox backup job schedule
  • Exact retention policy
  • Whether Docker data is backed up by file copies, volume exports, or both
  • Whether the NAS target is also the restore source for other application data
  • Current NAS IP address and route. On July 1, 2026, 192.168.100.250 did not respond to ping from pve, and 192.168.100.1 identified as Starlink.

Proxmox Backup and Restore

Backup path

The Proxmox host is the backup control point for VM and LXC content. The current documentation confirms these storage targets:

  • local
  • local-lvm

Historical storage targets DIR01, network-backup-syn, and media require recapture before use.

Restore path

Use the Proxmox UI or the guest CLI depending on what was backed up.

VM restore

  1. Locate the backup archive in the backup storage target.
  2. Restore the VM from the Proxmox UI or with qmrestore if using the CLI.
  3. Verify the VM ID, bridge mapping, and disk layout after restore.
  4. Start the VM and confirm network access.

LXC restore

  1. Locate the container backup archive.
  2. Restore the container from the Proxmox UI or with pct restore if using the CLI.
  3. Verify mount points, unprivileged settings, and network config.
  4. Start the container and confirm the expected service comes back cleanly.

Restore validation

  • Confirm the guest appears in qm list or pct list
  • Confirm the guest gets the expected IP
  • Confirm the service or workload starts without additional manual changes

Docker Backup and Restore

What should be backed up

For Docker stacks, back up:

  • the compose file
  • the .env file
  • any bind-mounted data directory under /root/<project>
  • any application-specific export or database dump needed for restore

What should be treated as source of truth

  • docker-compose.yml
  • .env
  • the matching data directory for the stack
  • redacted exports under redacted/docker/ when a secret-bearing config needs to be shared

Restore path

  1. Recreate or restore the stack directory on the Docker host.
  2. Restore the compose file and .env.
  3. Restore any required data directories or volumes.
  4. Bring the stack up with docker compose up -d.
  5. Check docker ps and docker logs.
  6. Confirm the Traefik route or published port is available.

Restore validation

  • Confirm the container comes up cleanly
  • Confirm the expected FQDN resolves if the service is public
  • Confirm the backend database or dependency is healthy
  • Confirm there is no restart loop

pfSense Backup and Restore

Backup path

The live pfSense export should be kept as:

  • a dated raw export in restricted storage outside this repository
  • config.redacted.xml as the shareable redacted copy

Restore path

  1. Keep a backup export before making firewall changes.
  2. Restore from the pfSense UI if the config needs to be rolled back.
  3. Re-check WAN, LAN, DMZ, DNS interception, and WireGuard after restore.
  4. Confirm the gateway group and alias rules are still correct.

Restore validation

  • Confirm WAN1/WAN2 gateway health
  • Confirm LAN clients still use Pi-hole
  • Confirm DNS redirect and proxy redirect rules still exist
  • Confirm WireGuard and logging still match the documented state
  1. Proxmox handles guest and host-level backups.
  2. Docker handles stack-level config backups and data exports.
  3. pfSense handles firewall export backups.
  4. Redacted artifacts are what should be shared or committed when documentation needs to reference the live state.

Restore Checklist

Before you declare a restore complete:

  • Verify the service or guest starts
  • Verify the expected IP and route are present
  • Verify the expected backup target still has the data
  • Verify the docs still match the restored state

Operational Notes

  • network-backup-syn is historically the most important backup target, but it was not present in pvesm status on July 1, 2026.
  • The backup policy still needs a verified schedule, retention period, owner, and restore-test record.
  • The backup page should be updated if the NAS layout or Proxmox storage targets change.