I’m busy working out the process to backup our existing production site and restoring on a secondary site and then pointing our proxy to the correct back-end to allow graceful upgrading of our site without downtime.
The process so far is pretty simple. (This will be automated)
Enable read-only on production site.
Enable including uploads in backups.
Run backup.
Copy backup to standby site.
Enable read-only on standby site.
Restore backup with uploads.
Switch proxy to standby site.
Disable read-only mode on standby site.
Now the standby site is the new production site. The problem seems to be the backup process removes the read-only status, thus making production live again, which allows changes that is not included in the backup to be possible.
My expectation is the backup process should not change the read-only state of the site.
Changing this state allows for changes that will not be on the restored site.
In that case, you have to pass a key that identifies this read-only mode as user-selected – I’m not sure what the exact syntax is, though, maybe someone else can help
Try opening a rails console (./launcher enter app, rails c) and running Discourse.enable_readonly_mode(Discourse::USER_READONLY_MODE_KEY).
I haven’t tried this, so have a backup ready, but it’s a very educated guess, given the quote above ;-))
Readonly mode is based on keys stored in Redis. If you’re restoring backup from one site to another that uses a different Redis server, it is going to fall out of readonly mode.