A completed backup is not the same thing as a recovery plan

Why a backup job is not the whole answer

A backup is a separate copy intended to help after an accident, failed disk or mistaken change. It is different from storage redundancy: a NAS may survive one failed drive and still instantly preserve an accidental deletion across the remaining drives. Snapshots can restore an earlier version quickly, but a snapshot on the same physical device cannot help if that device is lost.

A virtual-machine backup can be convenient because it captures an entire working environment. Backing up only an application's data can use less space and make individual files easier to retrieve. Neither choice covers everything by default: shared files, credentials held outside the machine and the order in which services must return may need separate planning.

The best approach depends on the failure you intend to survive. A quick rollback after a bad update calls for a different copy than recovery after losing the original storage device. Writing that goal down prevents a completed scheduled job from masquerading as a complete plan.

The comforting green check mark

Proxmox can run several services separately. That makes maintenance easier, but it creates several things that may need protection. Scheduled backups can run automatically and report whether each job completed.

It is tempting to see a row of successful jobs and mentally promote that into a complete recovery plan. The jobs ran, the status is green and other problems need attention.

The weakness in that logic is that a completed job does not prove the destination is healthy, the backup includes everything needed or somebody could restore the services in a sensible order while already having a bad day.

A green backup result is evidence. It is not a rehearsal.

What the Proxmox backup actually contains

Proxmox can back up a virtual machine or container with its configuration and included storage. That is a strong starting point because a service can be restored as a unit rather than rebuilt from a handwritten list of packages and settings. Check the job's storage options; not every attached or external location is included automatically.

The boundary still matters. Data stored outside the virtual machine or container may not be inside that backup. If large shared files live on a separate NAS, backing up the service that uses them does not magically create another copy of the NAS.

This distinction is easy to miss because the application presents everything as one working service. The backup system sees storage locations, mount points and boundaries. Recovery follows the second view, not the first.

Questions to answer before relying on a backup

Ask what would be needed if the main server failed completely. Could the newest usable backup be located without the server that normally displays it? Could it be restored to replacement storage? Which service must return first? Which pieces depend on the NAS, network or another service?

Separate inconvenience from permanent loss. Reinstalling a monitoring tool may be annoying. Recreating years of unique data may be impossible. Those risks should not receive the same backup effort simply because both appear as boxes in the same interface.

• What is included in each backup?
• What important data is stored somewhere else?
• Is the backup destination separate from the system being protected?
• How many older copies are kept?
• Can I identify a known-good backup?
• What must be restored before dependent services can start?
• What settings or secrets require a separate protected record?

A backup beside the original is a weak second copy

A backup stored on the same physical system as the original may help with an accidental deletion or a bad software change. It is much less helpful if the hardware, storage pool or entire location is lost.

The farther a backup is separated from the original failure, the more kinds of failure it can survive. That does not mean every home service needs an elaborate enterprise arrangement. It means the destination should be chosen deliberately instead of wherever there happened to be free space on setup day.

A practical priority is to protect unique, difficult-to-recreate information more carefully than replaceable data or a service that could be rebuilt. Perfect protection for everything is expensive. Pretending everything has equal value is cheaper and considerably less useful.

Why retention matters

Keeping only the newest backup can preserve a mistake perfectly. If corruption, accidental deletion or a bad configuration change is not noticed immediately, the latest backup may already contain the same problem.

Older restore points provide a way to go back before the problem began. They also consume space, so the number and age of retained copies need to reflect how quickly a problem is likely to be noticed and how much data can reasonably be stored.

This is not a contest to accumulate the greatest number of backup files. A sensible retention policy keeps several recent choices and some older checkpoints without quietly filling the destination until future backups fail. Storage systems enjoy turning protection into a capacity problem when left unsupervised.

The restore order is part of recovery

Services in a homelab are not independent just because they live in separate containers. Storage must be reachable before storage-dependent applications can work. Network services may need to return before dashboards and automation can reach anything useful.

A sensible recovery plan starts with the foundation: hardware, local storage, core networking and access to any required shared storage. Then restore shared functions, followed by the applications that depend on them. The exact order must reflect the actual system, not a public example.

Starting everything at once creates a wall of errors from programs that are behaving correctly: they cannot reach dependencies that do not exist yet. Those errors add noise precisely when a calm sequence would be more useful.

Testing without manufacturing a crisis

A restore test does not need to begin by destroying the working service. A spare location, isolated test environment or non-critical container can confirm that the backup can be read and the restoration process is understood.

The test should verify more than a successful import. The restored service needs to start, retain the expected settings and reach the dependencies it is supposed to use. A restored box that opens but cannot perform its job is an attractive museum exhibit.

The purpose of the test is also to expose missing instructions. If the process depends on one setting remembered only by the person who built it, that setting should be recorded while it is still available and nobody is holding a failed drive.

A private recovery note for each important service

Keep a private record of where each important backup is stored, what it includes, what the service depends on and the basic order for bringing it back. It does not need to be a fifty-page manual. It needs to remain understandable six months after the last maintenance session.

The record must avoid publishing private settings or credentials, but the private version should identify anything that would block recovery. Public documentation and private recovery instructions serve different audiences and should not be carelessly combined.

Automation still matters. Scheduled backups reduce the chance of postponing the job until shortly after a failure. The improvement is to stop treating automation as proof that the rest of recovery has been solved.