Suppose I have a raft snapshot of an old vault (self-hosted). The old vault is gone completely and I want to re-deploy it from scratch. Can I somehow start vault with the old snapshot directly?
I’m asking because it seems that the only way is to start up the new vault, then do n vault operator raft snapshot restore <file> in the cli (or an equivalent vault request) with the running vault, then unseal normally. That seems a bit clonky to me, because, e.g. with the “file” storage backend, you can just copy vault’s state directory to the correct location and spin up vault, no running vault and subsequent cli-command needed.
So I guess my questions is, is there some sort of config.hcl setting or other means that I can provide with a path to a snapshot so that vault automatically loads that on first startup and, provided successful, ignores it on any startup after that?
You do need some way to make a Vault cluster operational before running the Vault snapshot command. The unseal/shamir keys will be unique to the new cluster (see step 3).
You can likely restore in an automate fashion as part of a workflow that brings up, unseals the new cluster, copies the snapshot to the cluster, and restores the snapshot using the CLI.
I’m aware that I still need to unseal somehow.
The question was more, instead of having a blank vault instance start up and then doing a vault snapshot restore –force …, can I specify the snapshot before startup without running the CLI command and start vault right away in a state where it expects the unlock keys.
When using a file-backed vault it was very convenient that the deployment could just pull the state from backup and start right up without doing the CLI dance.
From the snapshot, no - you need to automate the process for a snapshot restore.