What Is Instant Recovery?

Instant recovery is the ability to run a workload directly from backup storage — booting a virtual machine or mounting a database straight off the backup repository — so it is usable in minutes rather than waiting for a full restore to complete. The data is later migrated back to production storage in the background while users are already working.

The distinction that matters most is this: instant recovery changes where the workload runs during recovery, not just how fast bytes copy. It answers the question “how quickly can the business use this system again?” rather than “how quickly can I move all the data back?” That difference is what makes it central to ransomware response, and it is also what makes it entirely dependent on how fast your backup storage can serve live I/O.

How instant recovery works

A conventional restore reads every block from the backup repository and writes it to production storage before the workload can start. For a large VM that can mean hours. Instant recovery inverts the order:

• Boot from backup. The backup application presents the backup image as a live datastore, and the hypervisor powers the VM on directly from it.
• Serve reads on demand. As the running workload requests blocks, they are read from the backup repository in real time.
• Redirect writes. New writes go to a temporary differencing area or to production, so the backup copy itself stays unchanged and immutable.
• Migrate in the background. A live migration (for example, Storage vMotion) moves the workload onto permanent production storage without downtime.

Because the VM is running against the backup repository the whole time, recovery-time performance is governed by that repository’s throughput and latency, not by the speed of a bulk copy.

Instant recovery vs. traditional restore

Both end at the same place — a workload running on production storage — but they trade differently between speed-to-usable and load on the backup system.

• Traditional restore. Full copy first, run second. Simple and predictable, but the recovery time objective is the copy time, which scales with data size.
• Instant recovery. Run first, copy second. The workload is usable almost immediately; the migration happens later. The cost is sustained random-read pressure on the backup repository while the workload runs live.

For a handful of critical systems after an outage or ransomware event, instant recovery collapses recovery time objectives from hours to minutes. For a full-site rebuild it is used selectively — bringing the most important workloads up first while bulk restores run in parallel.

Why instant recovery depends on backup storage performance

Instant recovery only feels instant if the backup repository can behave like primary storage for the duration. A running VM generates random reads and writes; if the repository is slow, the recovered workload is slow, and staging many VMs at once can overwhelm it. This is why the metric that matters is not just whether a product supports instant recovery but how many workloads it can serve concurrently — see restore throughput — and why the capability is meaningless unless it has been proven with restore testing under realistic load.

Performance also interacts with immutability. Instant recovery must run from a copy that is safe — one that a compromise cannot have altered. That means booting from an immutable, isolated copy: S3 Object Lock keeps the source unchangeable, and a logical air gap keeps it unreachable, so the workload you power on is known-clean rather than re-infected.

Instant recovery and ARTESCA

Scality ARTESCA is high-performance object storage you deploy on standard servers, and its design is built so the backup repository can sustain the live I/O instant recovery demands.

• Performance sized for recovery. ARTESCA is engineered to deliver the read throughput that lets backup applications boot and run workloads directly from the repository, not just archive to it.
• Immutability at the source. S3 Object Lock in governance and compliance modes, plus legal hold, ensures the copy a workload boots from cannot have been tampered with.
• Isolation from production. CORE5 credential separation, zero-trust admin controls and a hardened platform keep the recovery copy reachable to the restore process but not to a compromised production domain.
• Broad backup integration. Validated interoperability with Veeam, Commvault, Rubrik, Cohesity and others means instant-recovery workflows run through the tools teams already use.

The result is a repository fast enough to act as temporary primary storage during a recovery, and trustworthy enough that the workload booting from it is clean.

Instant recovery FAQs

How fast is instant recovery?

A workload is typically usable within minutes because it boots directly from backup instead of waiting for a full copy. The full migration back to production storage still takes time and runs in the background, but the business is operational long before it finishes.

Does instant recovery restore all my data at once?

No. It makes a workload runnable immediately by serving data on demand from the repository, then migrates the complete dataset to production afterwards. It is designed to minimize downtime for critical systems, not to bulk-move an entire environment instantly.

Is instant recovery safe after a ransomware attack?

Only if you boot from a clean copy. If the recovery source is immutable and isolated — protected by Object Lock and a logical air gap — instant recovery brings up a known-good workload. Booting from a copy an attacker could have altered risks reintroducing the infection.

What limits how many workloads I can instant-recover at once?

The performance of the backup repository. Each running workload generates live random I/O against it, so concurrency is bounded by the repository’s throughput and latency. This is why restore throughput, measured in workloads per hour, matters more than a simple yes/no on the feature.