JUMP TO SECTIONChoose a lesson section
Think like the technician responsible for recovery.
A backup is a means to an end. The real objective is to recover the right data, at an acceptable point in time, within an acceptable amount of time.
RPO and RTO answer different questions.
Recovery Point Objective (RPO) is how much data loss, measured in time, the business can tolerate. Recovery Time Objective (RTO) is how long the business can tolerate the service being unavailable before recovery should be completed.
If RPO is four hours, the recovery plan must aim to limit lost data to no more than four hours. The backup schedule and replication must support that goal.
If RTO is two hours, a restore process that takes six hours does not meet the objective—even when the latest backup is perfectly healthy.
Example: a file server fails at 4:00 PM. Its last usable point is 9:00 AM. The exposure is 7 hours of potential data loss, not the time until the server starts again. A nightly backup may be fine for one workload and unacceptable for another.
Job completion time isn't necessarily the protected data's exact recovery point. Review the recovery point timestamp, consistency method, and any replication lag before reporting an actual RPO gap.
Each restore point has a dependency story.
Full: contains the complete protected data set at the backup point. Incremental: captures changes since the prior successful backup in the chain. Differential: captures changes since a designated full backup, and typically grows until a new base full. Product implementations and metadata vary.
With a typical Veeam forward-incremental chain, an initial .vbk full is followed by .vib incrementals. A later restore point depends on the full and the intervening incrementals. If a required earlier file is missing or corrupted, downstream points can become unusable. Never hand-delete files just to satisfy retention or free space.
Creates a new full from the protected system. Useful for a fresh base when authorized and when source, network and repository resources are healthy.
Creates a new full using existing backup data. This can reduce source read activity but requires adequate repository capability and resources.
May merge older incrementals into the full as retention advances. Repository space, performance and immutability affect which operations are supported.
Which restore points are truly recoverable?
Use this simplified seven-point forward-incremental chain. Select a recovery date, then simulate damage to Wednesday's incremental. The model shows which files your target depends on, and where the chain stops being usable.
The required full and each preceding incremental are present. This example can assemble the selected Fri restore point. Actual success still requires valid data and a restore test.
Learning model only: no real backups or data are processed. A new independent full backup can establish a new chain; it does not make damaged historical restore points usable. Vendor-specific repair and retention methods differ.
Why deleting “old backups” can be dangerous.
Retention governs which restore points a supported product should keep. In dependent chains, retention can't always remove individual files immediately: preserving newer points may require the older full and incrementals. Capacity planning needs to account for new fulls, transformations, temporary working space, and retention overlap.
Immutability protects backup data against modification or deletion for a defined period. That's intentional protection—not a storage error to bypass. When a hardened repository is nearly full, a safe answer may involve approved capacity expansion, supported offloading, adjusting future policies with change control, or designing a new independent chain—not force-removing locked files.
The 3-2-1-1-0 rule is a useful planning heuristic: three copies, two media or storage types, one offsite, one offline or immutable copy, and zero unverified recovery errors. The exact protection design must still match your organization's RPO, RTO, threat model and budget.
Progress from “job success” to recovery evidence.
Job ran
A job reports success or a warning. Confirm scope, dates and the protected machines.
Data is intact
Review repository health, chain dependencies, integrity checks and missing files.
System can boot
Use an isolated boot/virtualization test, if supported, and review its result.
Service actually works
Validate expected files, data, application services and user workflows.
Datto SIRIS/ALTO screenshot verification performs a local virtualization of a selected recovery point and examines a boot screenshot. That's valuable evidence of bootability, but doesn't necessarily demonstrate all application, service or offsite restore requirements. A screenshot failure also needs diagnosis—it isn't by itself proof that every backup point is unusable.
For virtualized workloads, a safe isolated test can include boot verification, filesystem checks, expected files, required services and an application smoke test. Keep restored systems separated from production networking to avoid duplicate identities, IP conflicts or unintended writes.
A repeatable readiness investigation.
Use the sequence below whether you're responding to a failed Veeam job, a Datto screenshot warning, or an urgent restore request.
Define the recovery goal
Identify the system owner, critical application, recovery point and recovery time objectives.
Establish the last usable point
Read backup sessions and identify dependencies, warning states, offsite copies and actual restore point timestamps.
Inspect capacity and protections
Verify repository space, immutable windows, health alerts and whether any repair needs additional capacity.
Choose an authorized, reversible change
Preserve known-good copies. Document the change, the impact, dependencies and rollback plan.
Prove recovery in isolation
Run a controlled restore/boot test where possible; verify data and applications rather than relying on a green dashboard.
Document new readiness
Record last successful test, tested point, outcome, limitations and next scheduled protection run.
A Veeam job has failed repeatedly, a hardened repository is at 98% utilization, and the latest usable restore point is days old. The correct first move is to gather the evidence and preserve protected points—not to delete files. That's the situation explored in the optional Broken Backup Chain Lab.
Can you explain the why?
01A backup job succeeded last night. Does that prove your recovery time objective is achievable?
No. It proves the job reached its reported state. Test the appropriate restore workflow—including boot, data integrity, application dependencies and elapsed time—to establish recovery confidence.
02Can you delete Tuesday's incremental while keeping Wednesday and Thursday?
Not safely in a dependent forward-incremental chain: later restore points may require every earlier incremental since the base full. Let the backup product enforce supported retention and chain transformations.
03What is the difference between an active full and a synthetic full?
An active full reads protected source data to create a new full. A synthetic full is constructed in the repository from existing backup data. Both create a full restore point, but have different source and repository workloads.
04If Datto screenshot verification passes, have you proved the application works?
No. Screenshot verification is evidence that a recovery point booted far enough to show an expected screen in a local virtualized test. Application consistency, data integrity, user access and offsite recovery still require appropriate validation.
05A repository is 98% full and protected by immutability. What's your first move?
Confirm which jobs failed and which restore points are actually usable, review retention and lock windows, and determine safe capacity options. Don't force-delete chain files or weaken immutability to make the warning disappear.
Go to the source when platform details matter.
Illustrative examples, not vendor certification material. Behavior depends on deployed product version, repository type and backup policy. Always confirm current vendor guidance and approved change procedures before touching production backup data.