Thanks for sharing the detailed setup — it’s helpful to understand how you’ve separated IRIS binaries, database, journal, and WIJ across different mount points.

In a storage-level snapshot scenario, consistency is the key concern. Even if IRIS is installed on the local OS directory, you typically need to ensure the instance is placed into a proper backup state before taking the snapshot. Otherwise, restoring only the database files without coordinated journal/WIJ handling can lead to recovery complications.

On the secondary host, you generally do need an IRIS instance (same version and patch level) to mount the restored database and perform crash recovery. Journals are important if the snapshot was not taken in a fully quiesced state, since IRIS may need them to roll forward transactions and ensure consistency. WIJ also plays a role in recovery integrity depending on the shutdown state.

Many customers either:

• Use external freeze/thaw mechanisms integrated with IRIS backup APIs, or

• Put IRIS into online backup mode before snapshot, or

• Use IRIS mirroring for cleaner secondary validation instead of raw storage snapshots.

Simply mounting database files without starting IRIS would not allow proper consistency validation, since recovery logic runs during instance startup.

It would also be good to confirm whether you’re planning a crash-consistent snapshot or an application-consistent one — that usually determines the exact recovery steps.

Hope this helps clarify the approach a bit.

Congratulations to everyone who participated in the InterSystems Full Stack Programming Contest 2026 

It’s great to see the results and the recognition through technology bonuses. Contests like this really motivate developers to explore more features of InterSystems IRIS and improve their full stack skills.

Appreciate the effort of the organizers as well for putting together such a valuable opportunity for the community. Looking forward to future contests!