# SqlVault2

Overview

SqlVault2 is a recoverability-first rewrite of SqlVault in Rust. It encrypts SQL Server databases with AES-256-GCM, uploads artifacts to Google Drive or local storage, and exposes a loopback-only web UI for administration. The north star is verified restoreability, including recovery after the original host and local SQLite metadata are unavailable. The workspace is split into eight crates: core domain models and ports, security with a KEK ring and passphrase-protected recovery key export/import, a versioned encrypted artifact container, SQLite persistence with leases and snapshots, SQL Server and Google Drive integrations, the backup/restore/scheduling/reconciliation engine, the CLI and web host, and a testkit with fixtures and fault injection. Every successful full backup is queued for a background restore drill that restores to a scratch database, runs DBCC CHECKDB, drops the database, and certifies the result. A clean-host restore CLI subcommand recovers a database on a machine with no prior SQLite catalog using only the cloud artifact and a documented recovery key. File backup adds FastCDC content-defined chunking with per-chunk AES-256-GCM, SHA-256 deduplication, glob exclusions, and delta sync manifests. The release gate requires a lost-host restore drill: produce an encrypted artifact, remove the host and SQLite catalog, then restore using only the cloud artifact, recovery key, and released binaries.

Problem

The .NET version proved the product, but recoverability is the real contract. A backup system that cannot restore after host loss, metadata loss, or key loss is a liability. The rewrite makes restoreability the primary acceptance criterion and hardens every layer around it.

Approach

Spec-driven Rust workspace split into core, security, artifact, data, integrations, engine, host, and testkit crates. Streaming AES-256-GCM encryption with resumable uploads, automatic restore drills on every full backup, a clean-host restore CLI subcommand, KEK ring with passphrase-protected recovery key export/import, and an HMAC-chained audit log that fails closed without a key. Loopback-only binding, CSRF, Origin checks, CSP, and rate limiting secure the web surface.

Impact

• * Every successful full backup is queued for a background restore drill: restored to a scratch database, DBCC CHECKDB-verified, dropped, and certified.
• * Clean-host restore subcommand recovers a database on a machine with no prior SQLite catalog, using only the cloud artifact and a documented recovery key.
• * File backup (ENG-028) adds FastCDC content-defined chunking with per-chunk AES-256-GCM, SHA-256 deduplication, glob exclusions, and delta sync manifests.
• * Release gate requires a lost-host restore drill: produce an encrypted artifact, remove the host and SQLite catalog, then restore using only the cloud artifact, recovery key, and released binaries.

Architecture

SqlVault2 is a spec-driven Rust workspace that makes verified restoreability the primary contract. Eight crates separate domain, security, artifact format, persistence, integrations, engine, host, and test infrastructure, with a release gate that requires a lost-host restore drill.

Guardrails

• * Audit log is HMAC-chained and fails closed without an explicit key; no silent operation.
• * Loopback-only binding is enforced; the server refuses non-local binds.
• * Release candidate is not accepted until the lost-host restore drill succeeds against only the cloud artifact, recovery key, and released binaries.