Instant Mount: File Recovery via Native iSCSI

Traditional restoration processes require transferring the backed-up data to the local disk before it can be accessed. This data transfer scales linearly with the size of the dataset.

StateWarden provides an Instant Mount feature to reduce recovery time. This functionality allows deduplicated backups to be mounted directly as native block devices within the operating system. The process uses an integrated iSCSI Target Engine embedded in the Agent, providing read-only access to the data without transferring the entire disk image.

1. The Architecture of Instant Mount

Instant Mount integrates with the host operating system's storage stack.

Native Integration: The process utilizes the native iSCSI Initiator available in Windows and Linux. It does not require third-party filesystem drivers (such as Dokan or WinFSP).
Data Integrity Checks: When mounted, the data stream undergoes continuous integrity checks. Blocks are verified against their cryptographic hashes before being presented to the OS.
On-Demand Assembly: The Storage Node (Driad) streams the necessary deduplicated, encrypted chunks to the local Agent, which decrypts them and translates them into SCSI commands for the host OS.

2. Initiating an Instant Mount

An Instant Mount session is initiated from the StateWarden Dashboard.

Step 1: Locate the Target Backup

Navigate to the Restore panel within the Realm.
Select the relevant Device and locate the specific backup snapshot.

Step 2: Trigger the Mount Task

Click the Instant Mount action for the selected backup.
The Control Plane (Artemis) dispatches the command to the Agent on the target machine.

Step 3: Accessing the Data

The Agent initializes its internal iSCSI Target, authenticates with the Data Plane via its mTLS client certificate, and establishes the connection with the local OS.

On Windows: The volume appears in File Explorer with an assigned drive letter (e.g., Z:). Users can browse and copy files normally.
On Linux: The block device is mapped natively (e.g., /dev/sdb) and can be mounted using standard tools. Note: As the backup is read-only, ext4 filesystems should be mounted with the noload flag (e.g., mount -o ro,noload /dev/sdb1 /mnt) to prevent the kernel from attempting journal recovery.

3. Security and Session Management

Read-Only Enforcement

Instant Mount sessions are strictly Read-Only. The StateWarden Agent intercepts any SCSI WRITE commands, ensuring the original backup snapshot remains unmodified.

Cryptographic Handling

Data is decrypted entirely in-memory within the Agent using the assigned session keys. The plaintext data is passed directly across the local loopback interface to the OS kernel.

Unmounting

To terminate the session and release the resources:

Locate the active mount session in the Tasks or Restore view of the Dashboard.
Click Unmount.

The Agent terminates the iSCSI session, closes the connection to the Data Plane, and zeroes the decryption keys from its memory.

4. Troubleshooting

Environmental factors can occasionally interfere with the Instant Mount process.

MSiSCSI Service (Windows): The Agent attempts to start the Microsoft iSCSI Initiator Service automatically. If a Group Policy Object (GPO) disables this service, the mount will fail. Ensure the service startup type is set to at least "Manual".
Dirty Filesystems: If a machine crashed at the exact moment of a backup, the filesystem journal may be marked as "dirty". Windows typically mounts this transparently in read-only mode. On Linux, the -o ro,noload mount flag is required to bypass the journal check on dirty ext4 filesystems.