Again I have been hit by the dreaded database corruption on our Joplin server. Long story short: I set up a new user on their computer, I launch sync with "delete local and download from sync target" , Joplin restarts, the sync wheel spins for minutes with no message next to it, I think there's something wrong, I quit and relaunch so the standard sync kicks in and tries to sync a local half-synced database with the distant one, creating a total mess of conflicts, duplicates and disappearing notes on a hefty 4000+ notes database.
So I spent part of the afternoon trying to wipe the mess from the server before re-uploading a clean .jex backup of the notes from a computer I'll name "computer 1". Now I have a dozen other computers with the messy database half-synced that I have to put back to shape using the "delete local and download from sync target" option. The problem is that it takes a lot of time to re-download everything from the server on each machine. I was wondering if on these other machines, I could just delete the existing local data that's messed up, import the .jex backup as local data (each computer has a Joplin under a different user account), then sync the two versions of the same .jex (the one I uploaded to the server from computer 1 and the ones I locally installed on the other computers). Or will this make an even dirtier mess?
I'm almost certain Joplin changes IDs of notes/folders/tags on export (or import). So you may end up in a situation where you have the same notes with different IDs and upon syncing you'll have multiple copies on the server.
I see. Is there a way to manually put the files in the Joplin data folder (in .config) so that they are recognized as the same ones as the ones on the server then? What if there are other non-shared notebooks in this data folder, I imagine it would be tricky to remove only the shared notebooks and replace them by non-corrupted versions ?
Other than copying the full database + attachments, no, I don't think so. The problem with copying complete database is it may have client-specific data that you may not want copied over to another client.
I can't think of an easy way of solving this. Maybe if there was a way to export/import preserving IDs, that would certainly help.
I don't know enough of how sharing work to answer this.
OK this is a nightmare. I've been battling for two days instead of doing research and these "Conflicts (attachement)" keep reappearing from everywhere every time I try to sync from another account (previously corrupted and where I deleted all data locally before syncing to server). At this point I don't know what to do. I have a 12-person research team that can't work because everything is in shambles. I have grant deadlines, new people coming for new academic years and nothing works. I've been chaining 4-hour sync sessions from the primary account for I don't know why (like just changing a notebook from shared to unshared) and every time I try to get the data on another account, it messes up everything.
You could try to delete all notes from one client, sync all clients beginning with this one, then import a clean .jex and sync all clients again beginning with the one where you imported the backup.
If you have already tried that, I would suggest cleaning the server database completely and thus starting from the beginning with all clean databases. Import one .jex backup and sync all other clients.
Regarding speeding up the sync process I had a thought about the following progress (everything untested!):
- Start with an empty client and import a .jex backup.
- Sync with Joplin Server.
- Change the sync target to a folder on a USB-Stick or similar and immidiately press re-upload to sync-target.
- Use this USB-Stick to sync to all the other clients by using the file system sync target.
- At those clients switch the sync target to Joplin Server afterwards.
As said, I didn't try it and can't say if the IDs will get preserved correctly. If you try it, please provide information if this method works.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.