On UNCode we have two separate places where backups are done, a GitLab repository containing the task and course files and the Database backups in Google Drive, here you will know how to set up the different automatic backups for your production server, with the help of cron jobs. This guide will walk you through the steps to follow to setup the automatic backups in you production server.

For this process, we use GDrive to store the corresponding backups on Google Drive. To backup the DB, you need to have a Google account to store your data on Google Drive. Once this requirement is accomplished, follow the next steps:

1. In the Deployment repository you will find a file called install_gdrive_db_backup.sh, this file does the necessary steps to install this script:

   wget https://raw.githubusercontent.com/JuezUN/Deployment/master/deployment_scripts/install_gdrive_db_backup.sh
   chmod +x install_gdrive_db_backup.sh
   ./install_gdrive_db_backup.sh

2. Once gdrive is installed, you need to set up the Google credentials and allow gdrive to access your Google account to be able to upload or delete files. For that, run the command:

   sudo gdrive list

   This command, will give a link that you have to follow and give permissions to GDrive. Once this is done, it returns a token which you have to paste in the console.

   After this. you are ready to set up the cron jobs.

3. Cron job to automatize backup

   This cron will be run every Monday at 4 am, as not many users are using UNCode. However, feel free to create your own crons.

   1. Check documentation about uncode_database_backups to see how to use the script.

   2. Run the next command to open the crontab

      sudo crontab -e

      Add the next cron in the opened file:

      0 4 * * 1 cd /your/backup/local/repo/ && /usr/bin/uncode_database_backup -a create

In order to set up the automatic backup and set some crons, we should set up the ssh keys and put them in the remote repository.

1. Configure the ssh on the remote. Follow the instructions on this page: https://docs.gitlab.com/ee/ssh/ (If your remote repository is not on GitLab, these instructions work for almost all of them, as the process to generate the ssh key is the same).

2. The previous process must be done also for the root user. That means you must run the command to generate the ssh key as sudo: sudo ssh-keygen ... and also copy this key on GitLab.

3. Go to your local repository an check the remote url is a ssh url. Run command git config --list to see the url is correct. To change the url run the next command: git remote set-url origin <ssh_url>.

4. Check ssh connection for both users running ssh -T [email protected] and sudo ssh -T [email protected] for the case you are using GitLab.

After these steps you are all set. Now you can push/pull to/from the repository the backups and is not necessary to set the username and password every time you run those commands.

Now in order to do automatic backups, you must set cron jobs for each backup (tasks and database).

First check the documentation of uncode scripts to make the backups.

We consider that tasks are not changing very often, therefore a constant backup is not necessary. We consider a weekly backup is fair enough (every Sunday at 00:00:00). However, you are free to create your own backup policy.

1. sudo crontab -e to edit or add a cron.

2. As it was described before, this example creates an automatic backup every Sunday at 00:00:00. Add the next cron.

   0 4 * * 1 /usr/bin/uncode_tasks_backup create && /usr/bin/uncode_tasks_backup push

3. Save the file and the cron will be installed.

UNCode provides a command to backup using git the configuration files of the different services deployed in a server. Depending on the type of server (i.e. main, grader, or tools) some files are backup. Backing up these files is very useful in case something happens to a server and it has to be restarted, then, you will be able to get the update configuration files for the different services. The main server refers to the server which hosts the frontend and most of the services, including monitoring. The grader server hosts the agent server plus nginx; and in the tools server basically the nginx service config files are backed up.

As mentioned before, the backups are done using Git.

In order to set up the automatic backup and set some crons, we should set up the ssh keys and put them in the remote repository:

1. Configure the ssh on the remote repository. Follow the instructions on this page: https://docs.gitlab.com/ee/ssh/ (If your remote repository is not on GitLab, these instructions work for almost all of them, as the process to generate the ssh key is the same).

2. The ssh key must be done also for the root user. That means you must run the command to generate the ssh key as sudo: sudo ssh-keygen ... and also copy this key on GitLab.

3. Clone the remote repository using ssh. You can clone this repository wherever you want.

4. Check ssh connection for both users running ssh -T [email protected] and sudo ssh -T [email protected] for the case you are using GitLab.

After these steps you are all set. Now you can push/pull to/from the repository the backups and is not necessary to set the username and password every time you run those commands.

Now, in order to do automatic backups, you must set cron jobs to trigger the backup.

First check the documentation to see how this works.

We consider that tasks are not changing very often, therefore a constant backup is not necessary. We consider a weekly backup is fair enough (every Sunday at 00:00:00). However, you are free to create your own backup policy.

1. sudo crontab -e to edit or add a cron.

2. As it was described before, this example creates an automatic backup every Sunday at 00:00:00. Add the next cron.

   0 4 * * 0 /usr/bin/uncode_config_files_backup /path/to/repository <server_name> <server_type (main/grader/tools)> <push_commits (true/false)>

3. Save the file and the cron will be installed.

Note: in case there are several servers that modify the repository, be careful of leaving a time frame between crons in the different servers, that way the backups are done correctly.