⌚ About 2 min read

Backup Intermediate. 15-30 min

This BAOI guide provides a structured method for how to dimension an immutable backup without multiplying unnecessary changes.

Avant de commencer : adaptez toujours les commandes et manipulations à votre environnement. Sur un système de production, prévoyez une backup ou un retour arrière lorsque l’action peut modifier la configuration.

Étapes à suivre

1

Set perimeter

Identify the equipment, service, affected users and start time.
2

Collect Elements

Record the exact messages, logs and useful settings.
3

Test methodically

Start with the basic dependencies before the application components.
4

Apply correction

Change only the identified parameter or component.
5

Validate

Rewrite the full scenario and document the result.

À retenir

Keep the initial values for a backwards.
Avoid multiple simultaneous changes.
Compare with a functional configuration when possible.

Technical deep dive

Backup: chain, immutability and capacity must be calculated together

Technical checkpoints

A synthetic full rebuilds a full from data already in the repository; it therefore depends on chain integrity and storage performance.
Immutability must cover the retention window and enough time to hold fulls/incrementals without early deletion.
Production capacity, change rate, compression/deduplication and growth headroom must be included in sizing.

Simple sizing

Start with protected data × change rate × restore points, then apply measured real ratios and headroom.

Capacity ≈ usable full + Σ(incrementals) + operational headroom + growth

Topic-specific pitfalls

Sizing only from the last full often underestimates immutable retention.
A successful synthetic full is not proof of restore capability; perform restore tests.

How to validate

The chain passes health checks and a restore test succeeds.
Remaining capacity covers immutable retention and forecast growth without a saturation window.

Operational context

Immutable backup sizing must include protected data, daily change rate, retention, full-backup strategy, growth, repository overhead and the immutability window. Sizing only today’s source data creates a repository that becomes unsafe before retention objectives are met.

Step-by-step checks

Measure current protected data and a realistic daily change rate from recent backup sessions.
Model retention and full/incremental policy, including synthetic or active full behavior and any GFS restore points.
Add expected business growth, filesystem/repository overhead and operational headroom for merges, health checks or temporary restore activity.
Verify that capacity exhaustion cannot force deletion of still-immutable restore points before the retention policy allows it.

How to validate the result

The capacity model must cover the complete retention and immutability windows under expected growth while retaining a defined free-space safety margin.

Evidence to keep

Keep source size, daily change rate, retention/GFS rules, immutability period, assumed reduction ratio, growth rate and resulting raw/usable capacity.

Frequently asked question

Is source data size enough to size an immutable repository?

No. Retained change data, full cycles, growth, repository overhead and immutable restore points can require substantially more capacity than the live source dataset.

Related BAOI resources: IT tools · procedures · IT dictionary.