backup and restore on filesystem backend

[weak...@gmail.com]

Hello,

I've looked through the archive but didn't find much information; similarly, the documentation for Filesystem backend is mute on the subject of backup

(https://www.vaultproject.io/docs/configuration/storage/filesystem.html)

- is it officially supported to take  a copy (say, a tarball) of the data directory?

- if yes, is it OK to do it while Vault is running (or does it require cold backups for data consistency)?

Thanks in advance,

Waldek

[Chris Hoffman]

Backups are always based on the storage backend you are using and do require Vault to be offline to ensure consistency.  The file system is no different and copying the contents of the directory into a tarball is a perfectly fine backup method.

Chris

--
This mailing list is governed under the HashiCorp Community Guidelines - https://www.hashicorp.com/community-guidelines.html. Behavior in violation of those guidelines may result in your removal from this mailing list.
 
GitHub Issues: https://github.com/hashicorp/vault/issues
IRC: #vault-tool on Freenode
---
You received this message because you are subscribed to the Google Groups "Vault" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vault-tool+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vault-tool/b4f1491a-a423-46ee-89e6-943d44b070d7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[weak...@gmail.com]

Many thanks, Chris - that's very helpful!

So to be completely clear: even if I switched to a storage that on its own supports live backups (e.g. a transactional DB like PostgreSQL), should Vault be shut down for the backup? 

I'm not bothered with 1-2 second race conditions, just wondering "what's the worst thing that could happen" (i.e. whether the data can be corrupted this way).

Waldek

[Chris Hoffman]

Since our storage layer is generic, we do not have a way to perform atomic transactions for multiple writes required for some operations.  You could end up corrupting your data but it really just ends up that the behavior is undefined and there isn’t any guarantee here.

Chris

--

This mailing list is governed under the HashiCorp Community Guidelines - https://www.hashicorp.com/community-guidelines.html. Behavior in violation of those guidelines may result in your removal from this mailing list.
 
GitHub Issues: https://github.com/hashicorp/vault/issues
IRC: #vault-tool on Freenode
---
You received this message because you are subscribed to the Google Groups "Vault" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vault-tool+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/vault-tool/206c861d-5b62-43c2-964d-8bf302623cc4%40googlegroups.com.

[weak...@gmail.com]

Understood, thanks again for your prompt reply Chris!

It's a bit of a shame - seems that automated maintenance requires:

- periodic downtime which interferes with other periodic tasks using vault (CI jobs)

- loosening down the security (unsealing Vault after restart will require the key to be passed via command-line).

Of course, better safe than sorry - so I'll need to compromise on that.

Waldek

[Raoul]

I am also using the file storage backend, wouldn't it be enough to seal the vault during backup instead of completely stopping the service as this would allow me to keep my automated unseal procedure running without adding stop/start?

Raoul

[Francesco Ciocchetti]

Would using the vault operator migrate help with the consistency issue ?

https://www.vaultproject.io/docs/commands/operator/migrate.html

From what i read it will lock the source vault , is that lock enough to guarantee consistency ? 

I will be using it between a Google Storage bucket as source and file system as destination, not sure if source and destination can both be a file system