Recovering corrupted database

Testing version: Version 2.0 (11504)

What were you doing: Editing a note and then exporting it as TextBundle

What happened: Bear exhibited a clear rendering bug while editing the test note, then crashed when I tried to export this as a TextBundle to upload with a bug report.

Upon relaunching, the app initially showed the note in plain text, with no formatting, then every note that I clicked in this state was cleared to being completely blank, and synced to my other devices as freshly erased.

Screenshot 2023-06-09 at 12.02.24 AM

Looking at the SQLite database, these three notes indeed show as just modified, and with completely blank contents.

Because Bear still only allows manual backups, my most recent full backup is at least a week old.

Is there any way to recover history from the sync system? Or any other way of restoring from history? And how can I reset the state of my Mac client to be sure it’s safe to use again? This is profoundly disconcerting.

2 Likes

To the developers: I have at least one Mac that syncs to this account but hasn’t been running Bear through this process. Is there any way I can use the CloudKit update stream it is still waiting to receive to reconstruct this? Or to use the CloudKit contents even on the main Mac where the corruption happened?

I am very technical and comfortable digging quite deep, but I’m astonished at how instantly and completely this content was blown away on my primary devices – everywhere I’ve looked in all the related SQLite databases, etc. seems to have no evidence of any historical information whatsoever.

I’ve complained before that Bear has no way of automatically triggering backups. Let this be another reminder – there should at least be an automation action or URL scheme for doing this transparently in the background! Manually-triggered backups are never sufficient, and (as this shows) sync not only isn’t backup, it alone is worse than no backup because it replicates corruption instantly to all copies.

2 Likes

Hello there,

I’m really sorry about this, unfortunately you seems to have experienced a memory corruption due to a crash that didn’t bring down the whole app.

Your database is fine, the note you’ve shown crashed the app and put it in an inconsistent state. Without that note the problem should not present itself anymore. We’ve also fixed the crash that triggered the whole sequence of events and added more safety checks.

Unfortunately the lost notes are gone unless you have a backup/Time Machine :frowning:

(un)fortunately the sync is fast and propagated the empty notes everywhere, it’s usually a very good feature, not in this case.

Correct, sync is not a backup and manual backup is not enough. Automatic backup is on our list, but it’s not trivial and there are a lot of real issues in doing it (space, time taken, restriction on what apps can do in background, etc…).

Note editing history is also planned after the launch, that’s going to improve (if not solve) accidental editing and this edge cases.

Thank you for the time you’re investing in the app, we’re doing everything we can to make it as solid as possible.

1 Like

Thanks for the thorough reply, Matteo. I’ve finally figured out what the notes were that were clobbered and can fortunately survive.

It’s great to hear that automatic backups and cloud versioning are in the works.

In the meanwhile,

  1. Is there a recommended way to fully reset the state of my Mac client and restore it from the cloud copy?

  2. I am going to start my own simple automated backup of the main SQLite database. Fully acknowledging that you all don’t and shouldn’t have to support the user community poking directly at their live database, can you generally assume that the simple workflow of:

    • Quit Bear
    • Overwrite the database file
    • Relaunch Bear

would be sufficient to restore from a backup? Is there any nontrivial interaction with the sync service (e.g., changes have to have a ZMODIFICATIONDATE later than the last sync in order to be picked up)?