I’m currently running a CHT production instance using Docker in single node . I am currently running cht 4.5. I want to backup everything .Delete the server.
Run the same configuration , data , users in next server when required ( suppose after 1 year)
A. While reviewing the documentation, I came across two different guides:
1. Backup Migration (for CouchDB and environment files)
2. Migration using couch2pg /postgress
I’m a bit unsure which process fits my case best.
My question:
i. Should I simply back up and restore the CouchDB data (/home/ubuntu/cht/couchdb), credentials volume, and .env/compose files to the new server?
ii. Or do I also need to set up couch2pg / CHT Sync ?
What is the recommended best practice for moving a production CHT deployment to new hardware or infrastructure safely?
Note:
I am confused with this term migration & backup .
Hi @Sanjit_Kumar_Makaju - thanks so much for posting your question!
The main guide you should be following is the Production Docker > Backups in CHT. The main focus should be on the CouchDB database and the secrets in the docker .env file. With these two pieces of data backed up, everything else could be recreated.
Our docs link to CouchDBs Backup page, which recommend replication. This is perfectly viable, but you can also just copy the CouchDB files directly. Do this by follow the production docker install steps on your new server. Then delete the entire contents of /home/ubuntu/cht/couchdb and the /home/ubuntu/cht/upgrade-service/.env file. Restore the couchdb directory and the .env file from backups. Restart all the docker services and your restored CHT instance should be up and running.
Note: 1 year is a long time to wait between backup and restores. You very likely will forget all the specific steps. Be sure you document and test your backups to ensure they’re working well and every last detail is included in the instructions.
If you’re running couch2pg, you may also opt to backup your Postgres database. While you can recreate the data in Postgres by starting couch2pg and having it sync over every CouchDB document from scratch, this sync can take some time for very large deployments. The migration guide covers how to do a backup instead.
“Migration” means you’re using (or making) a backup, copying the backed up data to the new server and restoring it.
“Backup” means you’re making one or more copies of the data, likely in an automation manor. This is the first half of a migration process.
A well planned and well practiced backup process makes any migration easy: instead of restoring the same server for a backup, you just restore (migrate) to a new server.
Let us know if you have more questions - we’re happy to help!
4 Likes
@Sanjit_Kumar_Makaju - thank you again for your comment!
After reviewing the backup documentation, it was decided it needed to be much more narrowly focused on exactly how to do a backup and how to restore. To this end, we just published an revised backup documentation.
I’d love your feedback on the document, positive or negative, all is welcome!
2 Likes
Thank you .
I liked the updated document.
1 Like