Hi, we’d like to take “hot” filesystem snaphots of a running Jackrabbit, in order to spin up new instances from those filesystem copies. Our assumption is that we can somehow make sure the filesystem is in a consistent state before taking the snapshot, so we’d only need to remove the .lock files before spinning up a new instance (based on the snapshot). We’d like to avoid any startup delay due to consistency checks or any reindexing kicking in.
From what I understand, the only problem here could be the Lucene index files, as they may not be fully flushed to disk since the last write operation to Jackrabbit. Assuming that triggering of write operations has come to a full stop, my impression is that flushing to disk could be reliably enforced, either by calling SearchIndex.flush(), or simply by waiting the configured maximum volatileIdleTime of all workspaces? Or is there anything else that may cause problems on using a filesystem copy of a running instance? Let’s assume a remote database is used, or, if it also stores locally like an H2 database, it properly supports the “D” in ACID ... Thanks for any hints, Jörg
