Every restore workflow has a dependency chain. But most teams document the data path and never trace the control path.
When ransomware isolates a datacenter or a vendor service goes dark, control path determines whether recovery starts at all. A recovery plan that depends on the very service an attacker can take away is not a recovery plan.
NAS Cloud Direct Offline Recovery exists for that moment. It is a restore workflow that works when Rubrik Security Cloud and the supporting NAS Cloud Direct cloud services are unreachable. The customer restores from backups they already own, using the NAS Cloud Direct VM already deployed at their site.
Here's how the design works.
The Dependency Hidden in Every Restore
In normal operation, a restore asks the NAS Cloud Direct control plane two questions:
What exists? The index answers by tracking every object in every backup.
How is it configured? The application configuration answers by describing systems, exports, backup targets, and the buckets that hold the data.
The VM itself is stateless. It carries out work and reads or writes data, but the answers come from cloud services.
The upside: The VM is simple to deploy and easy to replace.
The catch: A restore cannot begin without a path to those services.
Offline Recovery removes that path from the critical sequence. The VM stops asking the cloud and instead asks a local copy of the same services instead. The copy is built from metadata the customer has already placed in their own storage.
The normal backup workflow looks like this:
Figure 1: Backup workflow. The VM reads from the source NAS, writes backup data to customer storage, and coordinates metadata and job status through the NAS Cloud Direct control plane.
Step 1: NAS and destination details are added to the control plane.
Step 2: The stateless VM connects to the source NAS share, scans the filesystem, and reads new data.
Step 3a: The VM moves new backup data and writes indexes to cloud object storage or on-prem storage.
Step 3b: The VM moves metadata to the control plane and to the storage target.
Step 4: The VM commits job status to the control plane.
Syncing the Map, Not the Territory
The backup data stays where it already lives. Offline Recovery adds a small amount of metadata beside it. A background sync job runs independently of backup jobs and writes two artifacts to a customer-owned destination:
Configuration snapshot: A compact copy of the application configuration
Index mirror: A copy of the index, filtered to the site and kept current as backups are added and as they expire
How the sync behaves:
Scoped by site: Each site writes into a namespace tied to its own recovery target, so multiple sites can share one bucket without colliding.
Changes only: After the first full sync, the job transfers only changes.
No impact on backups: Backups are untouched, no additional full backups are required, and existing operations continue as before.
Visible freshness: Customers can check the time of the last successful sync through the site configuration, which tells them how current their offline recovery point is.
Configuration is per site. The customer supplies a target and a credential, and Rubrik syncs from there. Disabling the feature stops further syncs and leaves the bucket contents alone.
Keeping Secrets Out of the Bucket
A metadata mirror in a customer bucket raises an obvious question. What else travels with it?
Sanitized snapshot: Credentials, authentication tokens, task details, and policies are removed before the snapshot leaves the site, so secrets stay with Rubrik.
Credentials at restore time: Anything needed to restore, such as credentials for an SMB or Kerberos destination, is entered by the operator when the restore begins and is held in memory. The CLI never returns a stored password.
No new surface area: Offline Recovery introduces no new roles, permissions, or network channels.
Encryption: When encryption is in use, the key stays with the existing credentials rather than with the offline data, and the operator is prompted again at restore. A reachable KMS server is still required for the VM to decrypt the data.
Recovering in Two Steps
Recovery takes two steps. The operator boots the VM into offline mode, and then restores.
Step 1: Boot into offline mode
Open the offline mode configuration from the VM console and enable it.
The VM reboots disconnected from NAS Cloud Direct services.
Provide the offline recovery target details.
The VM downloads the configuration snapshot and index mirror and starts a local index service and a local application service.
At that point, the VM answers its own questions and no longer reaches out to the control plane. No new infrastructure is needed, and no agent has to be deployed during an outage. The existing VM becomes the recovery plane.
Two things to know before switching modes:
Protection pauses: Entering offline mode stops active protection and backup workflows on that VM. If that is what you intend to do, you must confirm.
Reversible: Disabling offline mode reboots the VM into normal operation, reconnects it to NAS Cloud Direct services, and resumes backups and expirations.
Step 2: Restore
Once the local services are running, the operator chooses how to restore:
Recovery UI: Browse and restore interactively from the UI hosted on the VM address.
Command line: Script or work remotely over SSH.
The restore flow is the same either way:
Initialize the offline services from the target details.
List the systems and datasets available.
Submit a restore. A task identifier returns immediately, so long restores do not hold a session open.
Poll the task until it completes.
The offline restore workflow looks like this:
Figure 2: Offline restore workflow. The VM does not connect to Rubrik infrastructure. The operator provides destination details and credentials, selects an export and snapshot, and the VM restores the data.
The design principle behind all of this is simple: recovery should depend on as few things as possible, and those things should belong to the customer. Offline Recovery moves the index and configuration needed to restore into storage the customer controls, so the first step of recovery no longer waits on anyone else.
DISCLAIMER: Any unreleased services or features referenced in this document are not currently available and may not be made generally available on time or at all, as may be determined in our sole discretion. Any such referenced services or features do not represent promises to deliver, commitments, or obligations of Rubrik and may not be incorporated into any contract. Customers should make their purchase decisions based upon services and features that are currently generally available.