File‑based vs JDBC snapshots: which preserves linearizable state during concurrent cluster restores?

Goal: Ensure that when multiple Akka cluster nodes restore snapshots concurrently, the recovered actor state remains linearizable and all nodes observe the same event sequence.

Constraints: File‑based snapshots require the actor system to be stopped before restore to avoid inconsistency, which prevents concurrent restores but yields faster recovery; JDBC‑backed snapshots can be restored online, allowing concurrent restores but entail longer replay times and depend on database schema compatibility.

Uncertainty: It is unclear whether concurrent restores using either snapshot mechanism preserve linearizability across nodes or may lead to divergent event sequences due to timing differences in journal replay or snapshot application.

Does restoring file‑based snapshots concurrently on multiple nodes guarantee that all nodes see the same event sequence? Can JDBC snapshot restoration be performed concurrently without risking divergent state? What verification steps are needed to confirm linearizability after concurrent restores?