Linux is my OS of choice, so I’ll go that way. Apparently I can’t run this on Pi, but I do have a machine that I an use.
The records that I’ve imported were backed up into encrypted json files. I can import them once I get the Bitwarden server stood up, correct? I’ve done a lot of work to get these records imported, and I don’t want to have to do this again. Once I get everything imported, backed up, create a new machine and import, and they should import without issue, correct?
In theory, it should be possible, but there are many threads here where users have run into difficulty. I am not sure if anyone was ever successful. Officially, Bitwarden does not support it, so you would have to try a manual install.
Yes I understand that that I’ll need to first un-encrypt my data. I do have an encrypted share that I can unencrypted it in and store it safely. I just wanted to make sure that the format would work, without having to “fix” things.
I am coming from mSecure, and I export to a csv file. Unfortunately, I have to fix the format before I can import it into Bitwarden RS and it takes a lot of work to do. I just don’t want to have to duplicate that work.
Great. And just to be perfectly clear, if you are moving to a new system, you MUST export your existing Bitwarden vault using a .JSON unencrypted format. There will be no way for you to decrypt an encrypted JSON export file on the new installation.
Really depends on how you are wishing to backup your data and to what extent you are backing up.
I would most generally classify this into two categories, either an export of a single vault or the backup of the full server instance you are self-hosting.
Both would classify as a backup of your data and you would most likely want to have some form of an off-site copy for recovery purposes.
The main different scenarios I could imagine would be:
Exporting your vault for easy migration from self-hosted to SaaS or visa-versa, migrating from one password manager to another, or simply wanting a backup copy for the human error “oops” factor.
Backup and recovery of your self-hosted server in a disaster recovery situation. i.e Server has a hardware failure, ransomware, etc. (This only applies to self-hosted instances, as you would not be able to recovery this directly to the Bitwarden SaaS cloud.)
This is either an export of your personal Vault, or an Organizational Vault.
You are correct that the web and desktop clients will be relatively the same across the 3rd party Vaultwarden, and Bitwarden either SaaS cloud or Self-Hosted servers instances. Both Vaultwarden and Bitwarden servers still use the official Bitwarden client applications; either with the web-vault, desktop app, CLI, or browser extension etc.
Currently the supported operations to backup from the official clients are either exports as an unencrypted.JSON or .CSV file, and encrypted.JSON file.
Currently file attachments are not supported to be exported via the clients.
3rd Party Export Options.
There are additionally some 3rd party programs which can be used, typically via CLI to connect to and export your Bitwarden vault with additional information such as attachments.
Bitwarden used to have some linked in their support site, but can be found with a quick google or on Github.
I will give a warning of caution however,
You should not use any 3rd party software you do not FULLY trust, or have personally inspected and reviewed the code for to understand what it does.
If you are giving access to your password manager vault to some random 3rd party program written by a dev in their spare time you should be sure to trust it and the developer has a good reputation with the project.
Backing up Self-Hosted Server
This would constitute a backup of the ENTIRE Bitwarden service, including all personal and organizational Vaults, as well as any attachements, etc. for restore in a disaster recovery scenario.
This part is fairly straight forward, as the server admin you should have access to the ./bwdata directory the Bitwarden installer script was ran and the files created by the Bitwarden docker services.
If you intend to backup the entire ./bwdata directory it should be noted your backup method should contain MSSQL specific commands to freeze the database properly and ensure data consistent backups. Some types of backup software have this option built in to specify database backups VS simple regular file backups.
Otherwise you may need to stop the Bitwarden service, run the file level backup with something such as rsync or rclone, then spin up and start your Bitwarden service. This runs the problem of a slight downtime on the server during the backup operation in which users would be unable to sign in to new devices, or make changes back to the server. The Bitwarden clients would still continue to function for auto-fill and the like if already signed in prior.
Most likely would only lead to a small downtime of a few minutes and may not even be noticed by users but still not the best backup method.
Thankfully Bitwarden already does this for you to make it easy!
Nightly Database Backups
Bitwarden will automatically take nightly backups of the mssql container database. These backups are kept in the ./bwdata/mssql/backups directory for 30 days.
In the event of data loss, you can use ./bwdata/mssql/backups to restore a nightly backup.
With this you should need to only back up at minimum the following locations:
./bwdata/env - Instance’s environment variables, including database and certificate passwords.
Thank you for all of this great info. Right now, I’m looking just to backup my data, disaster recovery type. I just need to re-install my data should I need it.
The platform that I am moving from has an auto encrypted backup of my data to a desired location as well as I can press the button and force a backup should I feel the need. I then sweep those up in my backup software.
I’ve been exporting my data in .json format, unencrypted to an encrypted share that I use. It’ll work, I just have to remember to do it every time after making changes.