ARIVARAN TWIN · PLANNED RECOVERY DIRECTION

Twin is not a backup. It is designed as a live endpoint, ready when you need it.

Planned direction: open a live, browser-accessible digital twin when the original endpoint is unavailable. Today’s accepted path is authenticated, role- and organization-scoped browse of a completed snapshot with single-file download; full live recovery and incident-time self-service remain unavailable.

Planned outcome: no restore queue. No administrator wait.

Setup neededEndpoint and server recovery

Open the canonical product panel Products

Twin for endpoints and servers

Setup needed

The diagram shows the mechanism, its current result, and the limit that remains in force.

Step 1 of 3Catalog plus immutable block identity
The browser resolves a stored file through its catalog and verified block references without treating the source device as the recovery path.
Step 2 of 3Browser file recovery
Authorized users can inspect stored snapshots and recover a selected file when the required snapshot and blocks exist.
Step 3 of 3Evidence boundary
File browse and download do not prove a bootable Twin, in-place restore, standby, or migration outcome.

Mechanism

The browser resolves a stored file through its catalog and verified block references without treating the source device as the recovery path.

Platform state

Agent, filesystem, and restore coverage vary by platform and must be checked before deployment.

Evidence boundary

File browse and download do not prove a bootable Twin, in-place restore, standby, or migration outcome.

Before you start

Accepted enrollment, a completed snapshot, stored catalog and blocks, and subject-bound authorization.

Evidence reviewed 2026-08-26

Twin products

Overview
Twin for endpoints and servers — Setup needed
A stored catalog and content-addressed blocks keep file browse and download separate from live endpoint reachability.
1. Mechanism
  Catalog plus immutable block identity
  The browser resolves a stored file through its catalog and verified block references without treating the source device as the recovery path.
2. Current outcome
  Browser file recovery
  Authorized users can inspect stored snapshots and recover a selected file when the required snapshot and blocks exist.
3. Evidence boundary
  Evidence boundary
  File browse and download do not prove a bootable Twin, in-place restore, standby, or migration outcome.
Platform state
Agent, filesystem, and restore coverage vary by platform and must be checked before deployment.
Before you start
Accepted enrollment, a completed snapshot, stored catalog and blocks, and subject-bound authorization.
Twin for Microsoft 365 — Unavailable
The beta service follows Graph delta links for incremental capture and writes supported item restores back through Graph.
1. Mechanism
  Delta-query capture
  Versioned Microsoft Graph paging records changed Exchange and OneDrive items; optional shared dedup remains configuration-gated.
2. Current outcome
  Item-level cloud recovery
  Exchange and OneDrive engines have code and tests for capture, with restore write-back implemented in the service path.
3. Evidence boundary
  Evidence boundary
  Do not infer SharePoint, Teams, or universally enabled cross-workload dedup from the current beta.
Platform state
Cloud-to-cloud beta for Exchange Online and OneDrive; SharePoint and Teams are not current engines.
Before you start
Tenant OAuth consent, required Graph permissions, deployment-specific service authentication, and egress to Microsoft Graph.
Twin for Kubernetes — Planned
The beta Kubernetes agent separates manifest export, CSI-backed PVC data, and the Watch API journal instead of presenting them as one uniform guarantee.
1. Mechanism
  Layered cluster record
  Resource bundles form layer one, PVC blocks use the shared storage pipeline when CSI snapshots are available, and Watch events form a tier-gated journal.
2. Current outcome
  Workload-aware backup evidence
  Each layer can expose its own readiness and recovery boundary for the target cluster.
3. Evidence boundary
  Evidence boundary
  The CSI path is crash-consistent and still maturing; the change journal is tier-gated.
Platform state
Kubernetes beta; CSI capability and storage behavior depend on the cluster and provider.
Before you start
Helm deployment, cluster permissions, compatible VolumeSnapshot support for PVC capture, storage connectivity, and the required journal tier.
Twin for VMware vSphere — Planned
The beta proxy reads changed virtual-disk blocks and parses supported filesystems from raw bytes to build the familiar file catalog.
1. Mechanism
  No-mount filesystem parsing
  A vSphere-facing proxy reads snapshot data through the management path, then walks partition and filesystem structures without an in-guest agent.
2. Current outcome
  VM file browse on the Twin model
  Parser, CBT, proxy, and catalog tests evidence the architecture without claiming an independently measured speed result.
3. Evidence boundary
  Evidence boundary
  Documented parse-time and cost figures are estimates, not marketing benchmarks; bootable/live VM Twin remains separate.
Platform state
VMware/vSphere beta through an external proxy; transport and datastore modes remain configuration-specific.
Before you start
Supported vSphere APIs, proxy deployment, snapshot and CBT access, datastore reachability, and accepted restore scope.
Twin for Nutanix AHV — Planned
The beta Nutanix proxy connects through Prism, reads snapshot data, and feeds supported virtual-disk content into the same no-mount catalog path.
1. Mechanism
  Prism-to-catalog proxy
  An external proxy keeps AHV credentials and snapshot access at the management boundary while raw disk parsers produce the catalog.
2. Current outcome
  AHV-aware stored recovery data
  Prism client, change-region, backup-engine, and parser tests evidence the beta path.
3. Evidence boundary
  Evidence boundary
  This panel does not claim universal AHV compatibility, measured recovery speed, or a booted replacement VM.
Platform state
Nutanix AHV beta through an external proxy; support is not inferred for every Prism or storage configuration.
Before you start
A supported Prism endpoint, scoped proxy credentials, snapshot access, storage reachability, and accepted recovery configuration.