[GH-ISSUE #427] Restoring data when apps/extensions are logged in doesn't actually restore the data

kerem commented

2026-03-03 01:27:14 +03:00

Owner

Originally created by @vitobotta on GitHub (Mar 7, 2019).
Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/427

Hi! First of all thanks a lot for bitwarden_rs, it's much simpler and works great.

I wrote a simple script to backup both the sqlite database and the attachments (it's in this gist if someone wants to use it - https://gist.github.com/vitobotta/3a6c53c3693ff77cd0c920d0a541622d); backups work fine, but I am seeing a weird behavior with restores if I leave the client apps (including browser extensions) open/logged in while restoring the database. The procedure I use to do a restore is as follows:

docker stop
replace the sqlite database with the backup file (and optionally replace the attachments directory if needed)
docker start

If I delete an item from my vault after a backup, and then restore that backup while leaving the apps open/logged in, that item doesn't appear again in the client apps after a sync. It seems to me that I have to logout from all the client apps and browser extensions before restoring, so that the restored data appears again in the apps when re-logging in. Why is this happening? Is it because any changes made after the backup -which will be restored- are more recent than the backup and therefore when syncing the clients the restored data gets replaced again with the modified data? If yes perhaps this should be explained in the README.

I took a note for myself to log out from both the mac/Android apps and the browser extensions (Firefox and Chrome) before restoring, but I would like to know if this is expected behavior / if there is a way to avoid this and leave the apps logged in while restoring, which would be easier.

Thanks in advance for your help!

Originally created by @vitobotta on GitHub (Mar 7, 2019). Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/427 Hi! First of all thanks a lot for bitwarden_rs, it's much simpler and works great. I wrote a simple script to backup both the sqlite database and the attachments (it's in this gist if someone wants to use it - https://gist.github.com/vitobotta/3a6c53c3693ff77cd0c920d0a541622d); backups work fine, but I am seeing a weird behavior with restores if I leave the client apps (including browser extensions) open/logged in while restoring the database. The procedure I use to do a restore is as follows: 1. docker stop <container> 2. replace the sqlite database with the backup file (and optionally replace the attachments directory if needed) 3. docker start <container> If I delete an item from my vault after a backup, and then restore that backup while leaving the apps open/logged in, that item doesn't appear again in the client apps after a sync. It seems to me that I have to logout from all the client apps and browser extensions before restoring, so that the restored data appears again in the apps when re-logging in. Why is this happening? Is it because any changes made after the backup -which will be restored- are more recent than the backup and therefore when syncing the clients the restored data gets replaced again with the modified data? If yes perhaps this should be explained in the README. I took a note for myself to log out from both the mac/Android apps and the browser extensions (Firefox and Chrome) before restoring, but I would like to know if this is expected behavior / if there is a way to avoid this and leave the apps logged in while restoring, which would be easier. Thanks in advance for your help!

kerem

2026-03-03 01:27:14 +03:00

closed this issue
added the
enhancement
label

kerem commented

2026-03-03 01:27:15 +03:00

Author

Owner

@dani-garcia commented on GitHub (Mar 7, 2019):

The problem is probably that the clients check the last modified date before fetching the data from the server, so when restoring a backup, the clients would have a more recent modified date than the server, and so they keep the old data.

If you try to create a new cipher on a device, this should update the last modified date, which should at least force the other devices to update their local data.

We could add an option to the admin panel to refresh the last modified date, which should solve the problem, but it'll require an extra step. Or we could also add an option to force refresh the users modified dates at each startup.

@dani-garcia commented on GitHub (Mar 7, 2019): The problem is probably that the clients check the last modified date before fetching the data from the server, so when restoring a backup, the clients would have a more recent modified date than the server, and so they keep the old data. If you try to create a new cipher on a device, this should update the last modified date, which should at least force the other devices to update their local data. We could add an option to the admin panel to refresh the last modified date, which should solve the problem, but it'll require an extra step. Or we could also add an option to force refresh the users modified dates at each startup.

kerem commented

2026-03-03 01:27:15 +03:00

Author

Owner

@mprasil commented on GitHub (Mar 7, 2019):

Yeah that definitely sounds like revision date issue. I think we should add an option to update revision dates in admin panel. (even better if we can get per-user and "all" option) It should be fairly easy to implement. Alternatively we could also have an option to update revision date on start, but I wouldn't set it as default as users can restart the service often (say daily backup?) and that would force the sync for entire server for no good reason.

As a quick workaround, if you have all users in some organization, just updating/adding some password in the organization will update revision date for all members.

@mprasil commented on GitHub (Mar 7, 2019): Yeah that definitely sounds like revision date issue. I think we should add an option to update revision dates in admin panel. (even better if we can get per-user and "all" option) It should be fairly easy to implement. Alternatively we could also have an option to update revision date on start, but I wouldn't set it as default as users can restart the service often (say daily backup?) and that would force the sync for entire server for no good reason. As a quick workaround, if you have all users in some organization, just updating/adding some password in the organization will update revision date for all members.

kerem commented

2026-03-03 01:27:15 +03:00

Author

Owner

@vitobotta commented on GitHub (Mar 7, 2019):

Thanks both for your replies.

As a quick workaround, if you have all users in some organization, just updating/adding some password in the organization will update revision date for all members.

Not sure I am following. If I leave even one client logged in the data restored gets overwritten right away, so how/when do I need to add a password to update the revision date? Thanks

@vitobotta commented on GitHub (Mar 7, 2019): Thanks both for your replies. > As a quick workaround, if you have all users in some organization, just updating/adding some password in the organization will update revision date for all members. Not sure I am following. If I leave even one client logged in the data restored gets overwritten right away, so how/when do I need to add a password to update the revision date? Thanks

kerem commented

2026-03-03 01:27:15 +03:00

Author

Owner

@mprasil commented on GitHub (Mar 7, 2019):

If I leave even one client logged in the data restored gets overwritten right away

This shouldn't happen, it's just clients showing stale data. The sync is always one way server -> client. Client can only upload individual items on edit or creating new. These actions won't be triggered unless you actually do such actions in client. (I'm ignoring import tool, but same applies, the client won't sync anything to the server unless told to)

So what you see in the client is just last version the client saw before restore. But once you save one password, whoever can see the password will realize they are out of sync and will sync current data from server. So if you upload or edit shared key that all users can see, they will all sync. (you might need to reload page in browser, or trigger sync in client to do that instantly, or wait for regular interval to pass)

@mprasil commented on GitHub (Mar 7, 2019): > If I leave even one client logged in the data restored gets overwritten right away This shouldn't happen, it's just clients showing stale data. The sync is always one way server -> client. Client can only upload individual items on edit or creating new. These actions won't be triggered unless you actually do such actions in client. (I'm ignoring import tool, but same applies, the client won't sync anything to the server unless told to) So what you see in the client is just last version the client saw before restore. But once you save one password, whoever can see the password will realize they are out of sync and will sync current data from server. So if you upload or edit shared key that all users can see, they will all sync. (you might need to reload page in browser, or trigger sync in client to do that instantly, or wait for regular interval to pass)

kerem commented

2026-03-03 01:27:15 +03:00

Author

Owner

@vitobotta commented on GitHub (Mar 7, 2019):

I just tried restoring a backup while leaving the mac app open and logged in, then I added a password in the mac app after the restore as you suggested, then triggered a sync (is it this what you mean or did I misunderstand?) - same result. The data restored is kinda overwritten again or something as confirmed by checking in the web interface as well. The items deleted do not appear again in the vault.

If I repeat exactly the same process but I log out from the mac app first (assuming no other apps/extensions are currently logged in/open), then the items deleted appears again in the vault as expected. Please let me know if I misunderstood what you explained/suggested. Thanks

@vitobotta commented on GitHub (Mar 7, 2019): I just tried restoring a backup while leaving the mac app open and logged in, then I added a password in the mac app after the restore as you suggested, then triggered a sync (is it this what you mean or did I misunderstand?) - same result. The data restored is kinda overwritten again or something as confirmed by checking in the web interface as well. The items deleted do not appear again in the vault. If I repeat exactly the same process but I log out from the mac app first (assuming no other apps/extensions are currently logged in/open), then the items deleted appears again in the vault as expected. Please let me know if I misunderstood what you explained/suggested. Thanks

kerem commented

2026-03-03 01:27:15 +03:00

Author

Owner

@dani-garcia commented on GitHub (Mar 7, 2019):

What I meant was that if you kept the mac app and say, a mobile app logged in, and after restoring the backup you made a change in the mac app, then that would trigger an update in the modified date, which would mean that when the mobile app tried to sync, it would fetch the new data.

It still woudn't work on the mac app, because as the mac app made the change, it would assume that it was updated correctly and won't try to sync again, which means the mac app would still keep the old data, before the backup was restored.

I'll implement a quick button on the admin panel to update all users modified date, and if it works fine, then we can think of a possible better alternative.

@dani-garcia commented on GitHub (Mar 7, 2019): What I meant was that if you kept the mac app and say, a mobile app logged in, and after restoring the backup you made a change in the mac app, then that would trigger an update in the modified date, which would mean that when the mobile app tried to sync, it would fetch the new data. It still woudn't work on the mac app, because as the mac app made the change, it would assume that it was updated correctly and won't try to sync again, which means the mac app would still keep the old data, before the backup was restored. I'll implement a quick button on the admin panel to update all users modified date, and if it works fine, then we can think of a possible better alternative.

kerem commented

2026-03-03 01:27:15 +03:00

Author

Owner

@vitobotta commented on GitHub (Mar 7, 2019):

I'll implement a quick button on the admin panel to update all users modified date, and if it works fine, then we can think of a possible better alternative.

Cool, do you mind updating this issue when you have done this? Thanks!!

@vitobotta commented on GitHub (Mar 7, 2019): > I'll implement a quick button on the admin panel to update all users modified date, and if it works fine, then we can think of a possible better alternative. Cool, do you mind updating this issue when you have done this? Thanks!!

kerem commented

2026-03-03 01:27:15 +03:00

Author

Owner

@mprasil commented on GitHub (Mar 7, 2019):

@vitobotta apologies for misleading you there a bit. I should have been more specific and say that the changed password will trigger proper sync on all clients expect the one you do the operation on. For that one you can trigger proper sync by logging out and back in.

@mprasil commented on GitHub (Mar 7, 2019): @vitobotta apologies for misleading you there a bit. I should have been more specific and say that the changed password will trigger proper sync on all clients expect the one you do the operation on. For that one you can trigger proper sync by logging out and back in.

kerem commented

2026-03-03 01:27:15 +03:00

Author

Owner

@dani-garcia commented on GitHub (Mar 7, 2019):

I just pushed the change, should be in the latest commit, I'd appreciate some testing. If it works fine, we should add a note in the wiki.

@dani-garcia commented on GitHub (Mar 7, 2019): I just pushed the change, should be in the latest commit, I'd appreciate some testing. If it works fine, we should add a note in the wiki.

kerem commented

2026-03-03 01:27:16 +03:00

Author

Owner

@vitobotta commented on GitHub (Mar 7, 2019):

@vitobotta apologies for misleading you there a bit. I should have been more specific and say that the changed password will trigger proper sync on all clients expect the one you do the operation on. For that one you can trigger proper sync by logging out and back in.

Thanks for the clarification.

@vitobotta commented on GitHub (Mar 7, 2019): > @vitobotta apologies for misleading you there a bit. I should have been more specific and say that the changed password will trigger proper sync on all clients expect the one you do the operation on. For that one you can trigger proper sync by logging out and back in. Thanks for the clarification.

kerem commented

2026-03-03 01:27:16 +03:00

Author

Owner

@vitobotta commented on GitHub (Mar 7, 2019):

I just pushed the change, should be in the latest commit, I'd appreciate some testing. If it works fine, we should add a note in the wiki.

How would I test as I am using mprasil/bitwarden:latest at the moment? (Not very familiar with Docker unfortunately).

@vitobotta commented on GitHub (Mar 7, 2019): > I just pushed the change, should be in the latest commit, I'd appreciate some testing. If it works fine, we should add a note in the wiki. How would I test as I am using mprasil/bitwarden:latest at the moment? (Not very familiar with Docker unfortunately).

kerem commented

2026-03-03 01:27:16 +03:00

Author

Owner

@mprasil commented on GitHub (Mar 7, 2019):

@vitobotta the build for mprasil/bitwarden:latest is now running, however due to slow build servers on docker hub, you need to wait about 2 hours for the latest image to be built. Alternatively you can use bitwardenrs/dev:latest right now if you want to test the functionality right now. This is dev image that is automatically built from master on commit. (but it's not "trusted" build, so after testing you should probaby switch back to mprasil/bitwarden:latest)

@mprasil commented on GitHub (Mar 7, 2019): @vitobotta the build for `mprasil/bitwarden:latest` is now running, however due to slow build servers on docker hub, you need to wait about 2 hours for the latest image to be built. Alternatively you can use `bitwardenrs/dev:latest` right now if you want to test the functionality right now. This is dev image that is automatically built from master on commit. (but it's not "trusted" build, so after testing you should probaby switch back to `mprasil/bitwarden:latest`)

kerem commented

2026-03-03 01:27:16 +03:00

Author

Owner

@vitobotta commented on GitHub (Mar 10, 2019):

@vitobotta the build for mprasil/bitwarden:latest is now running, however due to slow build servers on docker hub, you need to wait about 2 hours for the latest image to be built. Alternatively you can use bitwardenrs/dev:latest right now if you want to test the functionality right now. This is dev image that is automatically built from master on commit. (but it's not "trusted" build, so after testing you should probaby switch back to mprasil/bitwarden:latest)

Hi, sorry for the delay. I have updated the container, where do I find the button in the admin panel you mentioned? Thanks

@vitobotta commented on GitHub (Mar 10, 2019): > @vitobotta the build for `mprasil/bitwarden:latest` is now running, however due to slow build servers on docker hub, you need to wait about 2 hours for the latest image to be built. Alternatively you can use `bitwardenrs/dev:latest` right now if you want to test the functionality right now. This is dev image that is automatically built from master on commit. (but it's not "trusted" build, so after testing you should probaby switch back to `mprasil/bitwarden:latest`) Hi, sorry for the delay. I have updated the container, where do I find the button in the admin panel you mentioned? Thanks

kerem commented

2026-03-03 01:27:16 +03:00

Author

Owner

@dani-garcia commented on GitHub (Mar 10, 2019):

Should be at the bottom of the users list in the admin panel, to the left of the reload users button.

I think it says something like Force users to re-sync or something close to that.

@dani-garcia commented on GitHub (Mar 10, 2019): Should be at the bottom of the users list in the admin panel, to the left of the reload users button. I think it says something like `Force users to re-sync` or something close to that.

kerem commented

2026-03-03 01:27:16 +03:00

Author

Owner

@vitobotta commented on GitHub (Mar 10, 2019):

Ouch! I hadn't realised there was an /admin area!! I tried to visit that page but it's asking me some credentials and doesn't accept my username and password. What should I enter there? Thanks!

@vitobotta commented on GitHub (Mar 10, 2019): Ouch! I hadn't realised there was an /admin area!! I tried to visit that page but it's asking me some credentials and doesn't accept my username and password. What should I enter there? Thanks!

kerem commented

2026-03-03 01:27:16 +03:00

Author

Owner

@vitobotta commented on GitHub (Mar 10, 2019):

Nevermind.... I had enabled basic auth in nginx.... I can see now the admin panel and the link. I will try and report back.

@vitobotta commented on GitHub (Mar 10, 2019): Nevermind.... I had enabled basic auth in nginx.... I can see now the admin panel and the link. I will try and report back.

kerem commented

2026-03-03 01:27:16 +03:00

Author

Owner

@vitobotta commented on GitHub (Mar 10, 2019):

Hello again!

So I tried many times that new function in the admin area and it worked at times but not always. However I think I may have found the problem!

If I:

stop the container
delete db.sqlite3-shm and db.sqlite3-wal
restore the db
restart the container
click on "Force clients to resync" in the admin panel

then when I trigger a sync from the clients they get updated with the restored data! This even if I leave the clients open and logged in. I am not familiar with sqlite and haven't read about it yet, so I am not sure about the roles of those two files.

Here's what I do to restore:

cd /tmp
mkdir restore-bitwarden
cd restore-bitwarden
tar xvfz /data/backups/bitwarden/backup.tar.gz.<TIMESTAMP>
docker stop root_bitwarden_1
rm /data/bitwarden/db.sqlite3-*
rm -rf /data/bitwarden/attachments/
cp db.sqlite3.<TIMESTAMP> /data/bitwarden/db.sqlite3
cp -r attachments /data/bitwarden/
docker start root_bitwarden_1

Followed by the "Force clients to resync" thing.

I will do some more testing and let you know if I still have issues. But so fat it seems to work each time. :)

@vitobotta commented on GitHub (Mar 10, 2019): Hello again! So I tried many times that new function in the admin area and it worked at times but not always. **However** I think I may have found the problem! If I: - stop the container - **delete db.sqlite3-shm and db.sqlite3-wal** - restore the db - restart the container - click on "Force clients to resync" in the admin panel **then** when I trigger a sync from the clients they get updated with the restored data! This even if I leave the clients open and logged in. I am not familiar with sqlite and haven't read about it yet, so I am not sure about the roles of those two files. Here's what I do to restore: ```bash cd /tmp mkdir restore-bitwarden cd restore-bitwarden tar xvfz /data/backups/bitwarden/backup.tar.gz.<TIMESTAMP> docker stop root_bitwarden_1 rm /data/bitwarden/db.sqlite3-* rm -rf /data/bitwarden/attachments/ cp db.sqlite3.<TIMESTAMP> /data/bitwarden/db.sqlite3 cp -r attachments /data/bitwarden/ docker start root_bitwarden_1 ``` Followed by the "Force clients to resync" thing. I will do some more testing and let you know if I still have issues. But so fat it seems to work each time. :)

kerem commented

2026-03-03 01:27:16 +03:00

Author

Owner

@mprasil commented on GitHub (Mar 10, 2019):

Yeah, instead of force syncing clients you can just wait, but the sync interval differs for each client and it can be quite long.

@mprasil commented on GitHub (Mar 10, 2019): Yeah, instead of force syncing clients you can just wait, but the sync interval differs for each client and it can be quite long.

kerem commented

2026-03-03 01:27:16 +03:00

Author

Owner

@dani-garcia commented on GitHub (Mar 13, 2019):

Those two files are temporary files used by SQLite's WAL mode, which should help improve performance. If the backups are created online with the sqlite command, then you'll only get one final file, and you should delete those two extra files when restoring, to avoid possible incompatibilities between the older shm and wal files and the restored database file.

If you are doing a simple copy paste backup of the database when the server is offline, then you should just overwrite the three files.

I think we can mark this as solved, but we should probably add a note to the wiki about it.

@dani-garcia commented on GitHub (Mar 13, 2019): Those two files are temporary files used by SQLite's WAL mode, which should help improve performance. If the backups are created online with the sqlite command, then you'll only get one final file, and you should delete those two extra files when restoring, to avoid possible incompatibilities between the older shm and wal files and the restored database file. If you are doing a simple copy paste backup of the database when the server is offline, then you should just overwrite the three files. I think we can mark this as solved, but we should probably add a note to the wiki about it.

kerem commented

2026-03-03 01:27:16 +03:00

Author

Owner

@vitobotta commented on GitHub (Mar 27, 2019):

Sorry for the delay (just noticed the notification of the comment) and thanks for the clarification!

@vitobotta commented on GitHub (Mar 27, 2019): Sorry for the delay (just noticed the notification of the comment) and thanks for the clarification!

Rows
Columns

[GH-ISSUE #427] Restoring data when apps/extensions are logged in doesn't actually restore the data #252