In the last month, we have performed countless migration tests in various scenarios and docker containers. In addition, I have performed even more Discourse DB restores from one server to another.
Based on extensive recovery testing, the Discourse restore process is brilliant and has worked flawlessly in every situation from the command line.
For example, we use a very primitive script for this, which I store in my /shared/neo/bin directory:
#!/bin/bash
echo "cd /var/www/discourse"
cd /var/www/discourse
echo "discourse enable_restore"
discourse enable_restore
echo "begin neo restore"
discourse restore unix-com-community-2020-03-27-033157-v20200320193612.tar.gz
echo "discourse disable_restore"
discourse disable_restore
Of course, this little bash script is not necessary nor elegant; but a tiny “make it easy and fast” script like this really helps when you are busy and just want to cut-and-paste your latest backup into the script and do the restore.
For me, I always restore on the command line (in app, and in Docker, of course) and the Discourse restore process has never failed, after many test scenarios. Just create a new Discourse Docker install and restore from the command line, and “boom”, it is done.
If we compare this to the “days of the dinosaur past”, before Docker, just the brilliance of the Discourse restore process in Docker makes a recovery process much easier and fast.
For example, we also copy our Discourse backups offsite (to a different server than production Discourse instance), and if that production server or data center “blew up” in a disaster, we can rebuild a Discourse instance from scratch, on any server of our choice, and restore easily (of course we need to keep our DNS TTLs short, but that is a different topic).
Congrats to the Discourse Team on such a well thought out and excellently designed backup and recovery process!
Works brilliantly, time after time, without any flaws.