The details would depend on what kind of secrets you’re talking about, but in general yes, but it may be not be easy or convenient.
As an example, let’s say you mean data in a KV secrets engine.
The data would be there, but there is no way to read just the secrets you’re interested in out of the snapshot. The only thing you can use the snapshot for, is to restore into a new instance of Vault.
If you set up a new instance of Vault, restore your snapshot into it, and authenticate to the new Vault, you can read the old values of your secrets from the new Vault.
However, if you want to restore them, you now have to write your own program to read from the new temporary Vault and copy them back to the main production Vault.
Also, starting up a new Vault and restoring a snapshot requires precautions, if your Vault has any secrets engines for which it manages external resources with leases. For example, let’s imagine you are using the Database or AWS secrets engines to manage dynamic credentials. You may have applications in production, which are using those credentials, and periodically extending their validity with the production Vault instance.
If you now start up a new Vault instance, and restore an older snapshot, the new Vault instance may now consider some of those dynamic credentials to have expired (as it does not receive the renewal requests from the applications using them). It will then connect to your databases or AWS (for example) and delete the credentials whilst they’re still being used.
For this reason, it’s necessary to ensure a restored Vault has no outbound network access, if you make use of any secrets engines for which this may be an issue.
So in conclusion - snapshots are a useful backup strategy should the worst happen - but be prepared for a somewhat complex procedure to make use of them.