PebbleRack

Guide 18 of 25 · intermediate

Back up your lab data and keep a recoverable copy elsewhere

Inventory data, schedule backups, protect an offsite copy, and prove a restore.

Source-verified · Not lab-testedOfficial sources checked 2026-09-29. No PebbleRack hardware compatibility claim.

Outcome

You will have a backup plan for VMs, containers, host configuration, and irreplaceable files, plus a tested restore of one disposable item. A backup job reporting success is necessary but insufficient. You must know what was captured, where it is stored, who can delete it, and whether it restores. This is a general procedure for existing equipment, not a validated PebbleRack hardware recipe.

Before you start

Prepare storage physically separate from the primary host and enough capacity for your chosen retention period. If using Proxmox Backup Server (PBS), read its datastore, access-control, sync, pruning, and verification documentation for your installed version. Decide recovery point objective (how much data loss you can tolerate) and recovery time objective (how long restoration may take) for each service. Keep encryption keys and recovery instructions outside the lab; losing the only key can make an intact backup unusable.

Steps

  1. Make a data inventory: VM disks, container volumes, application databases, files stored outside guests, Proxmox host/network configuration, and credentials needed to rebuild. Mark each as reproducible or irreplaceable. Proxmox VM backups do not automatically capture every external mount or external database. Verify each workload's consistency procedure; a database may need an application-aware dump or quiesce step.
  2. Choose a primary backup destination separate from the live disks. In Proxmox VE, add the destination under Datacenter → Storage, then create a scheduled job under Datacenter → Backup for the intended guests. Check the available mode and guest-agent requirements for your version. Start with a small disposable VM and inspect the completed task, size, timestamp, and backup listing before expanding scope.
  3. Choose retention deliberately. Keep enough daily, weekly, and monthly recovery points to cover likely discovery delays, but estimate space before enabling a long schedule. In PBS, use its prune simulator or dry-run before applying retention. Prune removes references and garbage collection frees unreferenced chunks later; neither is a substitute for a capacity plan.
  4. Add another copy away from the primary failure domain: a separate building, offline drive rotated away, or protected remote backup target. If PBS sync is used, review remove-vanished carefully: deletion propagation can defeat the purpose of the second copy. Restrict the primary host's credentials to backup creation where possible; PBS documentation recommends limiting deletion rights and doing pruning on the server.
  5. Enable backup-job failure alerts and PBS verification jobs if using PBS. Record the last successful backup and last successful verification for each important workload. Verification checks stored backup integrity, but it does not prove the restored application operates correctly.
  6. Restore a disposable VM or selected file to an isolated destination. Do not overwrite the production instance. Check that it boots or opens, inspect sample application data, and record elapsed time, backup timestamp, missing dependencies, and exact recovery steps. Repeat after material storage or configuration changes and at a regular cadence.

Check it worked

You can identify at least two distinct copies and their failure domains, a named person can locate encryption keys, and a restored item passed an application-level check. The restore record is dated and names the backup ID and environment. For critical services, the observed recovery time meets the target you wrote down.

If it fails / rollback

A failed backup does not justify deleting old copies to make room until you know why. Inspect the task log, destination health, free space, permissions, and network. A failed restore means the plan is unproven: preserve the backup, try a different point in an isolated destination, and repair the cause. Undo only the new backup schedule or retention rule if it risks existing copies; do not discard evidence.

Safety and data notes

Treat backup archives as sensitive production data. Encrypt offsite copies, limit access, document key recovery, and avoid publishing screenshots of directory names or user records. Rehearse without touching the only live instance. Copy count alone does not imply recoverability.

Sources

Official sources checked 2026-09-29: Proxmox VE administration guide; PBS datastore access and backup protection; PBS backup client and prune dry-run; PBS remote synchronization.

Next guide

Continue with your first local AI runtime.