Scheduling Automated Moodle Backups

May 6, 2024 by Jonathan Downey

"Better safe than sorry!" This tutorial covers scheduling automated backups in case disaster strikes (and, unfortunately, it eventually will...)

Learn how to backup the core moodle and moodledata directories, as well as the the MySQL 'moodle' database. We automate the process using cron scripts and archive backups as .tar.gz tarballs.

Course Backup vs. Site Backup

Back up your Moodle server often. Just do it. How often depends on how large your site is, how much often new content is uploaded, and how disappointed your students would be if their uploaded assignments were lost!

"Better safe than sorry!"
- People who learned the hard way

Understand that backing up individual courses is different than backing up the entire site, and that the former probably not enough. In case something really bad happens, you'll want a way to go right back to where you were before. This tutorial aims to teach you how to go about this process.

"Oops. I made a backup, right?"

This image, entitled Nuclear Disaster, by DEVDES-LPZ,
is licensed under a CC BY 3.0 licence.

That said, backing up individual courses can be handy because sometimes things will happen in an individual course that you would like to roll back without having to restore the entire Moodle site (for instance, if there were multiple courses...) Site admins and instructors can backup courses manually to a .mbz file. Also, admins can schdule automated course backups. Restoring these backups is pretty straightforward.

Site Backup Instructions

First, make a backup directory. I made mine in the server's /var/www directory (note that there is already a "backups" folder in /var but that one is off-limits:


                            mkdir /var/www/moodle_backup

There are three elements you need to back up into that folder:

The core Moodle code
The "moodledata" files
the Moodle MySQL database

A Moodle backup consists of copying three elements

1. Backing Up the Core Moodle Code

The main moodle code needs to be backed up. To do this, simply copy the main moodle folder and all of its contents into the backup directory:


                            cp -r /var/www/html/[nameofMoodleserver] /var/www/moodle_backup

2. Backing up the "moodledata" files

The contents of the moodledata folder consist of everything that has been uploaded to your Moodle instance. Again, the location of this folder can also be found in config.php. (i.e., /var/www/html/[moodledirectory]/config.php)


                            cp -r /var/moodledata /var/www/moodle_backup

3. Backing up the Moodle MySQL database

The last thing that you'll need to back up is the moodle database table, where information specific to your Moodle instance is stored. For the purposes of this tutorial, we're assuming that you're using a MySQL database (although you can use others like MariaDB or Postgres). For a MySQL database, use the mysqldump utility:


                            mysqldump -u [mysql_username] -p [mysql_password] [mysql_database] > /path/to/[mysql_dump_file_name].sql

Again, the username, password, etc. can by found in the config.php file. So for instance, the command for backing up on my test site might look like this:


                            mysqldump -u testuser -p test moodle > /var/www/moodle_backup/moodle_backup.sql

Compressing the Backup into an Archive

To save space, you can store a consolidated and compressed version of these three backup files using the "tar" ("tape archive") and "gzip" ("GNU" zip) utilities. You can bundle and compress the three using the tar command:


                            tar cvzf moodle_backup.tar.gz moodle_backup moodledata_backup moodle_backup.sql

...where -c is for "create", -v is for "verbose", -z is for "zip" (i.e., compressing the tar bundle), and -f is for "file", allowing you to specify the name of the resulting zipped tar file. The resulting .tar.gz file is referred to as a "tarball."

Package your backup files for easy archiving...

Restoring Moodle from the Backup File

You can extract the tarball with:


                            tar xvzf moodle_backup.tar.gz moodle_backup moodledata_backup moodle_backup.sql

...where -x is for "extract."

You can restore the main Moodle directory and the "moodledata" directory by simply doing the reverse of the backup process:


                            cp -r /var/www/moodle_backup/moodledir_backup /var/www/html/[nameofMoodleserver]
    cp -r /var/www/moodle_backup/moodledata_backup /var/moodledata

And you can restore the Moodle database with:


                            mysql -p moodle < moodle_backup.sql

Cron Backup

While there may be times when you want to make a manual backup in the moment, typically backups are made automatically on a schedule. You can use the "cron" job scheduling utility to run a shell script with your backup commands.

First, You will need to grant the Apache webserver (the www-data user) write and read access to this directory. To do so, we will specify the group of the directory as www-data:


                            sudo chown -R [username]:www-data /var/www/moodlebackup/

...and set 770 permission (owner and group can read/write/execute, other users cannot) to the folder and everything inside:


                            sudo chmod -R 770 /var/www/moodlebackup/

Of course, keep in mind that granting write permissions for the www-data user is risky, so don't grant these permissions in the /var/www parent directory.

A Sample Backup Script

This bash script is based on the cron job that I use to backup my Moodle instance. Note that this script assumes that you've already made a backup directory and created backup manually at least once before (specifically, the moodle_backup.tar.gz file needs to already exist in order to be moved):

You can create and edit the script in the nano editor:


                            sudo nano backup_script.sh

The body of the script could include:


                            #!/bin/bash

    cd /my/backup/directory

    # Timestamp the previously most recent backup (you will have a month of backups)
    mv moodle_backup.tar.gz moodle_backup_$(date +%d%m).tar.gz

    # Back up "moodle" directory
    cp -rp /var/www/html/moodle /my/backup/directory/moodledir_backup

    # Back up "moodledata" directory
    cp -rp /var/moodledata /my/backup/directory/moodledata_backup

    # Back up database
    mysqldump example.com -u [username] -p [password] moodle > /my/backup/directory/moodle_backup.sql

    # Compress the three backups into one archive 
    tar -cvzf moodle_backup.tar.gz moodledir_backup moodledata_backup moodle_backup.sql

Notes:

All Bash shell scripts start with: #!/bin/bash
$(date +%d%m) appends the day and month number to the end of the file. Therefore, each backup of a given day will overwrite the last, and will be a daily backup record for one year.
The -r option for cp specifies that both the directory as well as everything inside should be copied.
The -p option for cp retains the permissions and ownership for the file.

Next, the script must be made executable:


                            chmod +x backup_script.sh

You can run the script manually with:


                            bash backup_script.sh

Now, so that this script runs automatically at prespecified intervals, direct that this script be run by the crontab utility of the Apache web user (i.e., www-data):


                            sudo crontab -u www-data -e

(Remember that the www-data user has no password)

Inside the crontab, schedule the backup script with something like this:


                            0 * * * * /bin/bash /home/[username]/backup_script.sh > /tmp/moodle_cron.log 2>&1

...and create a log file in the /tmp directory:


                            sudo touch moodle_cron.log

The instructions you provided in the cron tab ask for the backup script to be run every hour at the hour. You can familiarize yourself with the cron syntax if you'd like to implement a different backup schedule.

The > /tmp/moodle_cron.log part of the instruction directs any "standard output" to be recorded in a log file at /tmp/moodle_cron.log

2>&1 redirects standard error to wherever standard output is being redirected. In other words, any output or errors messages from the running of the script will be recorded in moodle_cron.log.

You can find more discussions and examples online of running scripts with a cron.

Test that everything is working properly:

You can see if Moodle's cron script, cron.php, is running by checking Site aministration > Reports > System status.

Check if the Moodle Cron script is running properly

To see if the cron script is running the way you intended, you can check for specific errors in the cronlog file that you created.

Too Much of a Good Thing?

While making regular backups is obviously a good practice, it's possible to go overboard. First, if you site is large, you can spend a lot of computational resources making backups, that could otherwise be put to use for a smoother course experience for you students. Also, be careful with how much space your backups take up. You defintitely don't want to fill up your disk space and crash your course site. Your students will not be able to log on and will just get the message, "The session partition is full. It is not possible to login at this time. Please notify the server administrator." You may want to make backups overwrite each other, as we did in the example cron script above.

Backups can be resource intensive

Backing Up to External Server

To be super-safe, you might even want to backup to an entirely different server. To do this, you'll probably want to use the rsync utility to copy to an external location, as it has better performance than scp. You can check out this Moodle.org forum discussion for more information.