mirror of
https://github.com/rustfs/rustfs.git
synced 2026-08-02 11:29:17 +00:00
overtrue
0d30b623a7
Restoring a Vault-backed deployment is an operator action for the trust root and a RustFS action for everything else. This adds the orchestration around that split. Ordering is structural, not documented: VaultRestoreSequence refuses any stage that is not the next one, so material and metadata can never be published before the Transit/HSM trust root is verified back. Every way the recovered Vault can disagree with the bundle is a distinct typed mismatch: a missing Transit key, a min_decryption_version raised above what the bundle still needs, a Transit version history restored below the snapshot point, a rolled-back KV generation, and cluster, namespace, or mount drift. A dry-run reports them all and issues reads only; an actual restore refuses on the first one, before any KV path is probed. Writes are create-only check-and-set throughout, so version regression, generation rollback, and reviving deleted state are impossible rather than merely rejected, and a lost race stops the restore instead of overwriting. A reserved KV record is the single commit point: published before the first write and removed after the last, it names exactly the records this restore owns, so re-running the same bundle rolls forward idempotently and abort takes back precisely what was written — never a record that pre-existed. Every interruption converges to the complete old or the complete new state. Tests drive the whole surface offline through the scripted Vault responder, including the zero-write contract asserted at the wire; the live-Vault drill is ignored but kept compiling. Refs rustfs/backlog#1572 (part of rustfs/backlog#1562)