Snapshots
Snapshots Overview
The snapshot mechanism in the USBridge appliance is engineered to preserve critical data states independently of the target server.
I designed this subsystem to complement standard KVM access by enabling deterministic, block-level data operations that remain entirely isolated from the host operating system.
Autonomy and Control
A fundamental property of the USBridge storage architecture is its absolute independence from target server resources and state variables.
| Architectural Property | Technical Execution |
|---|---|
| Zero Host Dependency | Snapshot generation requires no drivers, agents, or background software installation on the target machine. |
| Hardware-Level Isolation | The target host has zero permission or physical routing capability to create, modify, or delete stored snapshots, ensuring total resilience against compromised OS environments or ransomware. |
| Event-Driven Triggers | Captures are initiated autonomously by the appliance based on file-system events (inotify) or programmed quiet periods following write operations. |
| Out-of-Band Control | Operators can manually trigger captures or audit historical snapshot states directly via the physical hardware controls and the built-in LCD screen. |
Core Storage Principles
The storage architecture enforces strict, transparent principles to guarantee predictable recovery behavior during critical infrastructure failures.
- Copy-on-Write (CoW): Utilizing Btrfs semantics, snapshots share unmodified data blocks. Delta changes are written to free blocks without overwriting the previous state, ensuring highly efficient history retention.
- Absolute Immutability: Immediately upon creation, the system seals each snapshot as a strictly read-only Btrfs subvolume.
- Standardized Format: Because I avoided proprietary hardware wrappers, the raw Btrfs filesystem can be mounted and read natively on any standard Linux workstation during emergency recovery scenarios.
- Crash Consistency: Snapshots capture a transaction-accurate state equivalent to an instant power-loss event, strictly preserving metadata integrity.
System Boundaries and Limitations
To maintain maximum operational reliability, this subsystem operates within explicit engineering boundaries.
Scope and Workload Profile
The capture scope is strictly limited to the file-system state (directory trees, metadata, and static file content). Volatile state data, such as system RAM contents, active kernel drivers, or in-flight processes, is intentionally excluded.
Consequently, this hardware subsystem is not engineered to act as a primary OS boot disk, a high-frequency database volume, or a target for continuous heavy log ingestion.
Recovery Model and Capacity Behavior
Because the architecture enforces read-only Btrfs subvolumes, in-place rollback operations are structurally prohibited. To execute a recovery, administrators must mount the target snapshot and extract the required data to a secondary physical medium.
Furthermore, I deliberately omitted automatic block rotation or automated deletion logic. When physical storage capacity is exhausted, the appliance safely halts new write operations and transitions the medium into a permanent archive mode, ensuring all existing historical snapshots remain intact and readable.