Hi Malaya,

First, by "Freeze", I think you mean executing ##class(Backup.General).ExternalFreeze().  That method pauses the write daemon at the end of a cycle.  This does not stop the journal daemon.  Journals are not written at the end of the write daemon cycle, they are written continually as you make updates.

The usage of the WIJ is described here: https://docs.intersystems.com/iris20253/csp/docbook/DocBook.UI.Page.cls?KEY=GCDI_wij.

Data blocks that are going to be written to databases are first written to the WIJ.  If there is a crash while the databases are being updated, some blocks may have made it to disk, and some not.  IRIS detects this and applies the blocks from the WIJ at the next startup.  

If you are getting warnings about MISMATCH.WIJ, contact the WRC for help.  There may be a problem with how you are backing up, or there may be another problem with your storage.

One other thing to keep in mind about journal files:

When you restore from a backup, you usually want to bring the system up to the current point in time. For that, you need journal files from the time of the backup up to the current time.  That means that some of the journal files you need aren't going to be in your backup, because they didn't exist when you took your snapshot.  You would need to account for this in your backup planning.
 

It looks like a number of people have contributed to that repo, both inside and outside of InterSystems.  Perhaps @Dmitry Maslennikov, @Evgeny Shvarov, or @Robert Cemper can help.

Those chained RUN commands are very common because they keep the layer count down, but it's a pain when they don't work 100%.

Or, if you like, improve what you can in your fork of this repo and propose a pull request to update it.  Get yourself some Developer Community cred for your effort!