Although the file count matches, we cannot be sure. Did you check the files immediately after creating the backup? Was CouchDB running during the backup? If so, that’s the likely cause of the size difference.
In CouchDB, small size differences can still occur due to various states of indexing and compaction. If documents were being written during or after the backup, some shard files may have grown after their copy was already taken, making prod slightly larger than backup.
To be fully certain, when you restore the backup to a temporary CHT instance, you can look for the documents count of medic database.
# Prod document count
curl -u admin:password 'http://localhost:5984/medic/_all_docs?limit=0'
# After your backup is restored to a temporary instance
curl -u admin:password 'http://localhost:<backup_port>/medic/_all_docs?limit=0'
You can also use Fauxton to check the databases and the document count at http://localhost/_utils.
If you can schedule a brief downtime, stopping CHT before copying ensures a consistent backup:
# Stop CouchDB first
cd /home/ubuntu/cht/compose
docker compose -f cht-core.yml -f cht-couchdb.yml --env-file ../upgrade-service/.env -p cht stop
# Then copy
cp --archive /home/ubuntu/cht/couchdb /home/ubuntu/cht/backup/
# Then restart
cd /home/ubuntu/cht/upgrade-service
docker compose restart
Thanks for the question @Sanjit_Kumar_Makaju ! As Binod stated above, the sizes may indeed change as time passes between when you made the backup and when you measured the file sizes.
One extremely important part of backup is called out at the very top of the instructions:
A backup is not functional until the restore is tested. Be sure to test the restore regularly!
Did you try doing a restore? This is the very best way, and really the only authoritative way, to validate if the size differences you cited are an issue or not.