How to prevent DB from getting corrupted in the event of a Kernel Panic or forced quit of DT

I’ve been using DT for a year or so now and absolutely love it.

That said, I have a recurring issue. Every once in a while my Macbook crashes or an update forces shutdown/closes DT and when I boot the system back up and open my database a whole bunch of files (400-800) are reported as “missing,” and moved to the inbox as orphans. I am always asked if I would like DT to repair the database, and when I click “Yes” It always fails.

It’s a ~4GB encrypted database. All files are stored in the DB, none are indexed. The vast majority of the documents are images and PDF’s.

When this happens I select all files/folders in the root of the database and click “Download pending files” from the context menu. DT then re-downloads the missing files from icloud (while simultaneously syncing the new 800 orphans to icloud). It just seems a bit inelegant.

I try my best to make sure I close DT before restarting or doing any development that might cause crashes, but it still inevitably happens. What exactly is happening, and is there a way to ensure that DT can gracefully recover? I’m afraid that one of these days recovery will not go so smoothly.

Shutting down DEVONthink, e.g. before system updates, shouldn’t be an issue usually. Is the option to sync before quit activated? It’s possible that the system kills the app in this case if the sync requires too long.

For that case (and many others) a good backup strategy is highly recommended. E.g. this year an iMac Pro didn’t even boot anymore after a kernel panic over here and after trying all the usual steps without success, the only remaining possibility was to wipe out the disk and reinstall macOS from scratch. The only thing I lost was time.

This is abnormal behavior. Have you done any maintenance on it or had someone look at the machine?

@cgrunenberg

Thanks! I don’t have it configured to sync on quit. If I don’t manually quit DT before a shutdown it will always prevent the shutdown until I do. Usually not an issue, asking it to quit is an easy step.

I am using time machine+external storage so I’m not too worried about data loss. Just wondering if I’m doing something wrong here.

@Bluefrog

I run a lot of crap on my mac. It doesn’t happen often but does occasionally happen. I also run Windows in a VM and various docker containers for web development. Each time it happens I investigate and identify the cause + take prophylactic measures against it happening again.

It doesn’t seem to affect my non-encrypted databases. Maybe I should migrate my data to a non-encrypted DB and sync it to a local datastore instead of cloud services. Can you recommend anything that would help if/when it occurs again?

Thanks!

Ahh… sounds like my machine, but without kernel panics :slight_smile:
/knocks wood

I’d say to not use an encrypted database unless you have a specific need for one. This is especially true if you’re already using full disk encryption via FileVault on the Mac. Also, if there’s not real private data in the database, I’d opt for the simplicity of an unencrypted database and the ability for it to grow without a hard boundary size.

Local sync stores and Bonjour syncs on a local network are definitely something we advocate. They’re fast, generally very reliable, and very private. Professionally, I use a variety of sync methods for testing, etc. Personally, I don’t put any important data on anyone’s machines or servers except my own or a work server of ours. Bonjour and local WebDAV on a Synology NAS are my primary sync mechanisms.

Yes, rub it in :slight_smile:

Sounds like a reasonable plan, thank you for the assistance!

You’re very welcome. :slight_smile: