What Is Point-in-Time Recovery?

Point-in-time recovery is the ability to restore a system to exactly the state it was in at a chosen moment — a consistent snapshot of a database, VM or filesystem as it existed at, say, 2:00 a.m. last Tuesday, before an attack or a corruption. Every part of the recovered system reflects the same instant, so the result is internally consistent rather than a patchwork of files from different times.

The distinction that matters most is this: point-in-time recovery is about consistency at a chosen moment, not retrieving individual files. It is the difference most buyers get wrong. Pulling one document back from last night’s backup is file recovery; rolling an entire application back to a coherent state it can actually run from is point-in-time recovery. After ransomware, only the second one gets you a system that boots.

Point-in-time recovery vs. file-level recovery

Both read from backups, but they answer different questions and produce different results.

• File-level recovery retrieves specific objects — a deleted spreadsheet, a folder, a mailbox — as they existed at some past time. It is perfect for “I lost this file,” and it does not require the rest of the system to be consistent.
• Point-in-time recovery restores a complete, consistent state across an entire system. It is what you need when the system itself is broken — encrypted, corrupted or misconfigured — and you must return all of its data to a single coherent moment so it functions.

Retrieving files from a ransomware-encrypted server one at a time gives you a pile of files, not a working system. Point-in-time recovery gives you the server as it ran before the attack.

Why consistency is the whole point

A running system is a web of dependencies: a database has to match its transaction log, an application’s files have to match its configuration, a VM’s disk has to be captured without a write half-finished. Restoring pieces from slightly different moments produces a state that never actually existed — and often will not start.

• Crash-consistent captures a system as if the power was cut: recoverable, but the application may need to replay logs to become usable.
• Application-consistent quiesces the application first (flushing in-flight writes) so the captured state is one the application recognizes as clean and can resume from directly.

Point-in-time recovery depends on backups being captured consistently in the first place. A backup taken mid-transaction can restore to a moment that is technically “point in time” but not usable — which is why recovery has to be proven with restore testing, not assumed.

Choosing the right point in time after an attack

The value of many recovery points is that they let you go back to before the damage. Ransomware often dwells undetected for days or weeks, so the last backup may already be compromised. Effective point-in-time recovery means having enough clean, retained restore points to reach past the intrusion.

• Granularity. How close together your recovery points sit determines how little data you lose — your recovery point objective.
• Retention depth. How far back your points go determines whether you can reach a moment before the attacker was inside. If retention is shorter than the dwell time, every surviving copy is already tainted — the failure mode that retention policy design exists to prevent.
• Integrity of the point. The moment you roll back to is only trustworthy if that copy could not have been altered — which requires immutability and isolation.

Point-in-time recovery and ARTESCA

Scality ARTESCA is object storage you run on standard servers, providing the immutable, retained repository that point-in-time recovery relies on.

• Immutable recovery points. S3 Object Lock in governance and compliance modes keeps each retained point exactly as written, so a rollback target cannot have been tampered with.
• Deep, policy-driven retention. ARTESCA holds enough clean restore points, for long enough, to roll back past an attacker’s dwell time rather than into it.
• Isolation of the repository. CORE5 credential separation and a logical air gap keep recovery points unreachable from a compromised production environment.
• Backup-application native. Point-in-time workflows run through Veeam, Commvault, Rubrik, Cohesity and other partners, with ARTESCA supplying the trustworthy storage layer beneath them.

The result is a set of consistent, unchangeable moments you can actually return a system to — the substance behind the phrase “restore to before the attack.”

Point-in-time recovery FAQs

How is point-in-time recovery different from restoring a file?

Restoring a file retrieves one object as it existed at some past time. Point-in-time recovery returns an entire system to a single consistent moment so it functions as a whole. You use file recovery for a lost document and point-in-time recovery for a broken or encrypted system.

What is a recovery point objective?

The recovery point objective (RPO) is the maximum amount of data, measured in time, you are willing to lose. If backups are taken hourly, your RPO is roughly one hour — the gap between the last recovery point and the moment of failure. Closer recovery points mean a smaller RPO.

Why does consistency matter so much?

Because systems are interdependent. Restoring parts from different moments creates a state that never really existed and frequently will not start. Application-consistent recovery points capture the system in a clean, resumable state, which is what makes the restore usable rather than just present.

Can I always roll back to before a ransomware attack?

Only if you retained enough clean recovery points to reach past the attacker’s dwell time. Ransomware often hides for weeks, so short retention can leave every surviving copy already compromised. Deep retention plus immutability is what makes rolling back to a genuinely clean moment possible.