Testing the integrity of a backup

Support
1

Operating system

Linux

Joplin version

3.1.24

Sync target

Joplin Cloud

What issue do you have?

How does one truly trust the .jex backup? I.e., is there a sensible way to test the integrity of the backup?

My thoughts were that (a) I could just unzip the thing and randomly poke around, but (b) the only real way is to create a temporary profile and import the backup into that? Would (b) be the recommended method?

1 Like
2

Maybe that would be a good test:

  • restore the backup in a new profile
  • export everything as Markdown+FrontMatter
  • switch to your current profile
  • export everything as Markdown+FrontMatter in a different directory

Then use a tool to compare the directories such as BeyondCompare. That should give you a good idea about what's in the backup and any differences.

2 Likes
3

Tested this by …

  1. create empty folders export1 and export2 on the filesytem
  2. sync
  3. export 2024-12-10.jex
  4. export markdown + frontmatter to export1 folder
  5. create new profile, and switch to it
  6. import from 2024-12-10.jex
  7. export markdown + frontmatter to export2 folder
  8. run on commadline: diff -ruN export1 export2

The results were interesting. Seems like somewhere in the export process from running instance to .jex, to import, and then export to markdown + frontmatter an ordering heuristic is triggered that can't guarantee identical outcomes for files that are named the same.

For example, in the conversion to markdown on disk, there are three resources in my export all called colophon.src.svg. Two of the three are slightly different. In it's native state, Joplin saves these files each with a unique hash. In the conversion to markdown + frontmatter, Joplin saves to original filenames. The result is, for example, in my exports, I have those three files normally named colonphon.src.svg instead named colophon.src.svg, colophon.src-1.svg, and colophon.src-2.svg. Two of which are slightly different.

Here's the kicker: via this import and export process which one gets the -1 or -2 suffix is not guaranteed. What happened in my case was that, export1/_resources/colophon.src-1.svg is identical to export2/_resources/colophon.src-2.svg and export1/_resources/colophon.src-2.svg is identical to export2/_resources/colophon.src-1.svg. But export1/_resources/colophon.src-1.svg is DIFFERENT than export2/_resources/colophon.src-1.svg and vice versa.

I have a shocking number of just slightly different resource items that are named the same. :wink:

Note, if I just save straight to export1 and export2 from the same profile … the diff runs clean.

The good news: comparing exports in this manner was convincing enough to me that I could be confident that this particular back up is sound. An imperfect test, but useful nonetheless.

Computers are fun. :wink:

2 Likes
4

The same could happens for folder during the markdown export.

1 Like
5

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.