Very interesting answer.
I really like the idea of putting the server in readonly mode, it would work really well.
The replication scenario isn't as interesting for a smaller shop, since it would incur maintenance costs (extra server or cloud) and introduce extra steps:
* setup automatic replication
* detect when replication is done, then stop the secondary server to put its DB into consistent state
* create the backup
* spin up the secondary server
But for this to be more reliable, we would have to also set monitoring of the secondary server, and failure recovery as well, so the first server won't go crazy when automatic replication kicks in the the secondary is dead. We also need to be careful not to stop the secondary during a replication.
With the readonly option it would be very simple to perform the backups using the same setup most of us already have (setups that stop the server before the backup operation, then start the server again).
Of course, a in-house backup solution would be even better, as it would have access to Plastic's internals and could speed up backups immensely. One thing that comes to mind is the timestamps in SQLite DBs. Restarting the Plastic server changes the timestamps and the DBs are seem as changed by the backup tools, which, in turn, wastes time as the tool will have to check the file to see what exactly changed (for incremental/differential backups, the entire file will need to be read).
Thanks for such a detailed answer. Really looking forward to seeing how Jet will turn out!
P.S.: Incidentally, are you planning on enabling Jet on community/open source licenses as well, or only for team/enterprise licenses?