@@ -444,7 +444,108 @@ This verify that memcache is indeed working as excpected.
...
@@ -444,7 +444,108 @@ This verify that memcache is indeed working as excpected.
### 1) Backup VM
### 1) Backup VM
First, we create our new backup VM: "backup". We also attach our newly created openstack volume to it. As for SSH, we decide to use an alternative solution to the one proposed in the assignment. We give the manager ssh key to the backup VM, so that it might contact the database.
### 3) Backup Script
### 3) Backup Script
Then to make a working backup solution. There are four components to our system. On manager, you have the script "backupDatabase.sh". On the backup VM, there is "backup.sh", and "restore.sh". And on database, there is "checkDbStatus.sh", wich is a script that was written for a previous assignment. The purpose of the script is to check the status of cockroach, and restart it if it's down.
The first step in the backup process is to run backupDatabase.sh on manager. This can safely be done with the database running and backup VM shut off. We use crontab to automaticly backup each morning 08:00, when our bookface has the least visitors.
backupDatabase.sh will first exit bookface production, and reroute visitors to our fallback webserver. Then, the backup VM is started using an openstack command. The script will then repeatedly attempt an SSH connection towards backup until it succeeds. Once in, it will run "backup.sh" and exit. Once this script is done, the backup is complete. The backup VM is turned back off, and production is reinstated.
bash /home/ubuntu/dcsg2003/configuration/manager/production.sh up
```
Once the "backup.sh" script is run on the backup server, it will first mount the volume. Then it will make an SSH connection towards the database VM, use it to kill the cockroach process. With the database down, it will start copying all the content of /bf_data to a local temporary folder.
Once the download is complete, "checkDbStatus.sh" is run via SSH on the database VM, wich will detect the DB as down, and immediatly restart it. Meanwhile, the copied files are compressed into a tarball, wich is then moved to the backup volume. We also have a mechanism in place that deletes all but the three newest backups on every backup. This frees up a lot of space, but makes our backups have a three day expiration date.
Once the backup is done, the script exits. The script on manager will continue, and the VM will be shut down until it is run again the next morning.