Proxmox VE / Intermediate: data, identity and policy / Lesson 9

Backup consistency and retention

Design recovery copies from application data requirements, backup scope and failure domains rather than equating a completed job with recoverability.

About 4 min readContent reviewed 2026-10-28

On this page

Lesson goals

Separate crash consistency, filesystem quiescing and application consistency.
Map included disks and external data sources.
Connect retention and copy location to recovery objectives.

Start with recovery objectives

Recovery point objective describes acceptable data loss in time, while recovery time objective describes acceptable time to restore useful service. A backup schedule supports those objectives but does not establish them by itself. Failed jobs, long runtimes, inaccessible archives and slow restoration can widen the actual gap. Define which application state matters and whether all of it is inside the guest. For a synthetic catalog, product data may be local while uploaded media lives elsewhere. A VM archive cannot protect that external media merely because the application references it.

Understand consistency boundaries

A crash-consistent image resembles storage after sudden interruption and may rely on guest recovery at boot. Filesystem freeze through supported guest integration can coordinate writes at the filesystem boundary, but does not automatically give every multi-service application a transactionally consistent recovery point. Databases and external services may need application-aware procedures. Backup mode and guest type also affect interruption and scope. The first record names these claims explicitly. It does not run a backup, freeze a filesystem or promise that a particular mode is suitable for every workload.

text Backup contract record

copy scope: selected managed guest disks
consistency claim: explicitly reviewed crash/filesystem/application boundary
external data: separately owned media store
acceptance evidence: isolated restore + application integrity check

The record distinguishes desired evidence from a captured backup result. No archive or guest is accessed.

Account for retention and growth

Retention determines which recovery points remain available, not merely how many successful jobs occurred. Capacity planning must include change rate, compression or deduplication behavior where applicable and verification overhead. Do not assume a constant compression ratio for arbitrary application data. The second example uses full-sized synthetic copies to demonstrate a conservative arithmetic model: six copies of 12 GiB require 72 GiB before overhead. Real backup formats may store data differently, so measure the chosen system instead of presenting this multiplication as a Proxmox Backup Server sizing formula.

python Synthetic retention arithmetic

copy_gib = 12
retained_copies = 6
print(copy_gib * retained_copies)
print("before overhead; no deduplication modeled")

Expected output

72
before overhead; no deduplication modeled

The model assumes independent full-sized copies. It is deliberately not a measurement of any backup engine.

Separate copy location and trust

A backup stored only on the same failed host or pool may be unavailable precisely when needed. Consider storage failure, deletion, credential compromise and administrative mistakes as distinct scenarios. Proxmox Backup Server is a separate product with its own datastore, verification, retention and access model; connecting it does not remove the need to design those responsibilities. Encryption can protect contents but creates a key-recovery obligation. Public course examples use no keys or endpoints. Document who can delete copies, who can restore them and how recovery remains possible if the primary management system is lost.

Verify recoverability

A successful backup task establishes only the scope of that task’s report. Recoverability needs an independently reviewed restore, expected files and application-level integrity evidence in an isolated authorized environment. Keep restoration from accidentally joining production networks or reusing active identities. Compare achieved recovery time and recovery point with the objectives, and record excluded data explicitly. This course executes no backup, datastore verification or restore. Its retention program validates multiplication only. The learning outcome is a complete backup contract whose remaining operational checks are named rather than silently assumed.

Common errors and fixes

Job success is reported as proven recoverability

Why it happens: Restoration and application integrity were never checked.
How to fix it: Plan an isolated restore and explicit data/application acceptance evidence.
Prevent it next time: Track backup execution and recovery validation separately.

External application data is absent from the recovery copy

Why it happens: Guest visibility was mistaken for backup inclusion.
How to fix it: Map all data sources to their own recovery owner and copy.
Prevent it next time: Review backup scope whenever application storage changes.

The only backup shares the failed primary pool

Why it happens: Retention count was considered without failure-domain location.
How to fix it: Design independent access and copy availability for the required failures.
Prevent it next time: Review deletion, access and key recovery alongside storage location.

Check your understanding

1. A guest filesystem is frozen during backup. Does this prove database transaction consistency?

Show worked solution

No. Filesystem coordination is a narrower boundary than application transaction consistency, especially across several services or external data sources. Consult the application’s supported backup method and verify recovery integrity. Record exactly which consistency claim the chosen integration supports instead of promoting a filesystem action into a universal database guarantee.

2. Why can six daily recovery points still fail a four-hour RPO?