First time when I was working with bahmni, I made some changes to OpenERP, which stopped it from working completely. I tried re-installing bahmni, which didn’t help, so ended up with re-installing CentOS and bahmni completely. So, I wanted to be careful this time, so wanted to take a full backup before making any changes so that I can revert back to a working copy. I tried ‘bahmni -i local backup --backup_type=all --options=all’ as per the wiki documentation. I have two questions on this:
- It looked like the backup was created at /mymount/2017-03-11_003541-patient_images.tar.gz, but I don’t see any database within that. Where would I find the full backup file so that I can restore back when things go wrong?
- I am wondering whether the choice of Ansible for backup was a mistake or there is a valid reason behind that. I am very new to Ansible, however I understand it is a tool aimed at IT automation. However backup/restore is an integrated part of any data oriented application, so I would have really loved to see a simple 'bahmni backup-data/restore-data ’ command that would have hidden all the integration within itself. After running the current command, there is so much of data generated, but it was very hard to find the bit that was really important, ie backup file name. Ideally, ‘-i local’(ie use of ansible) should also be optional as majority of the installations would be on the same system. Ansible should only be used when an inventory file covering multiple systems is provided.
Can you please check under /db_backup folder.
I can’t find /db_backup folder. However I find something in /data/openmrs and /data/reports that looks relevant.
[root@spoojary-laptop mymount]# ls -lrth /mymount/
-rwxr-xr-x. 1 bahmni bahmni 3.4K Mar 11 00:35 2017-03-11_003541-patient_images.tar.gz
-rwxr-xr-x 1 bahmni bahmni 3.4K Mar 11 15:35 2017-03-11_153551-patient_images.tar.gz
[root@spoojary-laptop mymount]# ls -lrth /db_backup
ls: cannot access /db_backup: No such file or directory
[root@spoojary-laptop mymount]# ls -lrth /data/openmrs/
drwxrwxrwx. 3 bahmni bahmni 4.0K Mar 11 00:29 20170311002907_full
drwxrwxrwx 3 bahmni bahmni 4.0K Mar 11 15:29 20170311152831_full
-rwxrwxrwx. 1 bahmni bahmni 80 Mar 11 15:29 backup_info.txt
Is that where the data is expected?
The old way of backup/restore is aimed at db only and doesn’t address my second point,
We played a new story to backup the data like patient documents, patient images, DB data etc in 0.88 Bahmni. So you can’t find backup db files in /db-backup folder with latest Bahmni version. If you need only database backup files and don’t need all other data then you can try below steps.
- Run the commands under Uninstall Backup Tools section in this wiki page. This will remove the latest backup method tool and will generate the single dump file.
- Run this command to take the backup of openmrs database
bahmni -i local backup --backup_type=db --options=openmrs
- You can find the
file.sql.gz file at /data/openmrs folder.
For more information on backup of postgres databases and restore commands check this wiki page.
This used to be optional in older Bahmni versions but we chose to made it mandatory.
I managed to make progress yesterday after looking at /etc/bahmni-backrest.conf contents. I see that documented in the wiki you mentioned, but I missed earlier. I got the backup/restore working, but I felt it is unnecessarily complicated. In general people don’t like to take partial backup. When things go wrong, they want their system to revert back to a previous stable checkpoint. So it is better to have one file that contains all the required data, instead of spreading it across many files. Customizations should be optional, and not difficult as backup file is understood by backup/restore commands. If there is any more work planned in this area, I am interested in contributing.
Thank you for your thoughts @spoojary. I think the Backup / Restore feature could definitely use some more “simplification”.
I agree that it would be best if somehow a single command can be used to perform a “full backup” – of every artefact, like images, config files, databases, etc. And possibly all the artefacts should be generated in a single folder called: “bahmni-backup-yyyy-mm-dd” or something similar, so that people know that if they safely offload this folder somewhere they are good. Then for restoring, it should pick up all files from a given folder and restore them to the right place.
The complications arise because:
Different implementations use different parts of Bahmni. So, not everyone wants to backup/restore everything. For instance, some people are using only EMR parts of Bahmni, and there too, may not be uploading any Radiology images. So, the tool needs to work in different scenarios, and not fail if it doesn’t find postgres db, or something like that.
Sometimes people want to restore only “parts” of the system – like maybe restore only Patient Images – and not everything. We need to support some use-cases like that.
Many times the backups take too long if done in “full-backup” mode. So we needed the ability to perform quick incremental backups – and that again resulted in some complications in design choices.
The choice of Ansible was to continue using the infrastructure that already is expected to exist on Bahmni server machines, and Ansible does give us more flexibility / robustness in design – along with picking up from where it left off, which is rather difficult to do in normal bash scripting. But I agree, that people should not get confused by large log outputs, and we should figure out a way to print human readable backup/restore reports – so that it helps people in understanding what is going on.
Any contributions from you on this front – documentation or code or scripts or ideas will be helpful. I have provided a link to this discussion from the Wiki page for future readers to provide opinion / thoughts: https://bahmni.atlassian.net/wiki/pages/viewpage.action?pageId=114729037
I agree with your points and they need to be considered for backup/restore changes. I am hoping it will make it to ‘Admin’ screen sometime in the distant future, so thinking from that angle for the CLI/scripts.
A simple change to start with will be updating /etc/bahmni-backrest.conf, to point all the backup files to a single directory, like /data/bahmni_backup. That allows creating a quick tar file containing all the data, which can be transferred to a different machine.
If people install part of the systems on different servers, we need to backup/restore only relevant parts. That is perhaps not difficult if there is an easy way of finding what sub systems are installed. If not we could just ignore the extra check for presence of data files. In a way that isn’t bad as you will have bigger problems if the data itself is not found!
Full backups taking long time is certainly a big issue, especially as we don’t use smart storage with snapshot features. In one of the previous work, we resorted to full daily backups and hourly incremental backups.
For the time being, I resorted to two quick python scripts, which takes all the backups in /data/bahmni_backup and creates a tar file. The restore script first untars and issues individual restore commands. Without good python knowledge, it is quite trivial so needs a lot more work before it can be useful to others…
It would be helpful if you can upload your current python scripts to your github account or something similar so that others searching for some better alternatives for automation could potentially reuse your scripts.
pushed to git, but certainly needs more work to be really useful
Thank you. This is quite nice!