mirror of
https://github.com/dani-garcia/vaultwarden.git
synced 2026-02-05 00:29:40 +03:00
Document process of data recovery without a server #307
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @yacoob on GitHub (May 31, 2019).
I wonder if there should be a documentation for recovery from catastrophic situations. All you've managed to save is the database itself. You have the
.sqlite3file. You know your password. Now what?The simplest way to go about it would be to set up a fresh server from the scratch and feed it the database you've saved. Is that sufficient? I'm unsure whether the
rsa_keypresent there is automatically generated for web serving or is it used for anything important and should be backed up together with the database?What if we're unable to set up a new server, for whatever reason? Any simple/straightforward way of dumping the data from the saved db to a csv file for example?
Maybe I've missed a wiki page describing this :)
Thanks!
@mprasil commented on GitHub (May 31, 2019):
There are restore instructions in the wiki. It's just one sentence:
Maybe we could explain, that if you're restoring from zero, you just need to copy the file there as there is nothing to override? I feel like that is kinda obvious, but if you think you can phrase it better, feel free to do so, the wiki is editable by anyone.
Hope that answers your question.
@yacoob commented on GitHub (May 31, 2019):
Current restore instructions assume you can spin up a server. There's a bunch of cases where this might be hard to do, and that's what this bug is about. :)
Right now I use keepass for storing some of my passwords. Keepass has a well documented storage format, and databases can be shared between different keepass clients. There are libraries that can be used to create emergency "break glass" procedures where all you have is the password file and a script/binary, and you can extract anything that you need offline.
With bitwarden, I need the server to be up, running and available/reachable. That should be an option most of the time, but not always. Most likely scenario: I recover my db from offsite backup, and I'm not able to bring up whole server for whatever reason (eg. I'm offline and don't have the binary handy). Is there an easy way to recover passwords from the sqlite file? Is there a non-easy way? :D
Maybe it's not worth the trouble, and I'm just thinking about unlikely scenarios. It'd be nice to have plan Z, though.
Thanks for your consideration! :)
@mprasil commented on GitHub (May 31, 2019):
I see what you mean now. Well I think the easy answer is to run bitwarden_rs with your sqlite3 file anywhere. This thing runs on $5 raspberry pi zero, so if you have any computer at all, you can probably run it. Technically speaking you can just run it on your desktop and just point your browser to localhost.
The sqlite3 file is just normal DB dump, but the data stored is a bit more complicated to just decrypt by some script. There's password sharing, multiple users, organizations, etc.. It would be way more involved than just finding a way to run the service in some temporary manner. You'd be essentially implementing part of the server logic plus part of the client side logic. And the DB schema can change over time so you'd have to follow the development closely.
If you want some quick plan Z, find a way to run the docker image on your desktop. That way you can start up recovery service in matter of minutes.
@yacoob commented on GitHub (Jun 1, 2019):
Thanks for the overview of the complexity here. I'd prefer the solution to be 100% local, so I'll test how minimal I can get in terms of "use this tgz in case you need to recover a password while offline". Static linking of the rust binaries should help here :D
Do you have any estimation of how backward compatible the db has been? That is, how often the schema changed enough, to require up to date binary in order to read it?
@dani-garcia commented on GitHub (Jun 2, 2019):
You can look into the migrations folder to check how often we make them, we had about a dozen during 2018 while the project was still growing, and we haven't had a new one since November. There is another one that's gonna happen soon for adding MySQL support, but i don't expect many to happen in the future.
@mprasil commented on GitHub (Jun 3, 2019):
@yacoob, I think your best bet might be using bitwarden-cli and automatically backup the passwords into some encrypted export. This won't save attachments, but it will give you the encrypted
*.csvyou can use without starting the server.@yacoob commented on GitHub (Jun 4, 2019):
Oh, good idea. Won't be automated probably, due to the auth, but I can totally turn it into a procedure ran on a regular basis to get a working bkp of the passwords.
Thanks!