So far, we have covered how to backup a single course. The site-level backup performs the same operation for every course in the system, including hidden courses and the front page, which is also a course (the name of the front page backup uses the name of the site).
To schedule site backups, go to Courses | Backups | Automated backup setup. You will see a number of settings:
The remainder of the settings page covers Automated backup settings that specifies which elements will be included in the backup. These are identical to the initial backup settings, except the anonymize option, which has been excluded.
For the backup to start automatically at the specified time, the cron process has to be set up correctly, which was covered in Chapter 2, The Moodle System. Alternatively, you can initiate the backup process via the CLI. The command execution from the shell or for the inclusion in scripts is as follows:
sudo –u <apache_user> /usr/bin/php admin/cli/automated_backups.php
The script has to be run as an Apache user, usually www-data. In the preceding example, it is executed from the main Moodle application directory. The script executes the same script that is called by the cron process.
The recovery of courses is identical to restoring data from course-level backup archives.
As a Moodle administrator, it is your duty to ensure that the backup execution has been successful. For this purpose, Moodle provides a backup report, which you can find by going to Reports | Backups.
The report provides details for each course being backed up, namely, Time taken (start and end time), Status (OK or ERROR), and the date and time of Next Backup.
Courses in which there hasn't been any activity for 30 days, that is, no changes have been made to the course content and no users have used the course, are excluded from the automated backup, and the status is shown as SKIPPED.
As a Moodle administrator, you will receive an e-mail after the execution of the scheduled site-level backup has been completed. It provides details on the total number of courses backed up and a split of how many course backups were okay, had an error, are unfinished, and were skipped. Make sure your e-mail settings have been configured properly (refer to Chapter 9, Moodle Configuration). It is highly recommended that you check the content of this e-mail every day.
There are a number of issues to consider when running automatic site-wide Moodle backups:
- Backup content: Make sure that everything included in the archives is needed and anything that is not required is excluded. For instance, do you have to back up the entire log file every night?
- Backup size: The size of the backup files can be potentially huge (multiple gigabytes). Ensure that you only keep the number of backups that are required and your setup can cope with.
- Backup timing: The backup operation is a CPU and hard disk-intensive operation. Make sure that you schedule it when the load on the site is relatively low. If you run multiple sites on the same server, it is a good idea to time-stagger the backups or create a script that makes of the described CLI. An alternative approach is to set up a separate webserver dedicated just to run the backups.
- Backup frequency: Do you need seven daily backups or are weekly backups sufficient? Are there periods (such as weekends) when you can switch off the backup facility altogether?
- Backup location: By default, all backup files are saved to the respective courses, which means that the backups are held on the same server as Moodle itself. If you have to recover multiple courses, you will have to locate each archive separately, which is potentially a very time consuming exercise.
You might want to consider backing up on an external device (tape, external disk, NAS drive, SAN, and so on). An alternative to this is to mount a backup device and include its content in the organization-wide backup.
Site-level backups are a great way to automate course backups and make the lives of individual teachers and instructors easier. However, there are a number of drawbacks that should be stressed on:
- Course backups are potentially very expensive in terms of time and CPU usage.
- It is not uncommon for backups to time out, especially on commercially hosted systems that are not dedicated to Moodle.
- If teachers and instructors run their own backups, there is a likelihood of duplication of archives, which should be avoided if possible.
As the name suggests, you only have to back up courses, not the entire system. While this is sufficient if you have to recover a simple course or a number of activities, it does not provide a solution to the scenario when the entire system has to be restored. You should not use the course backup facility as your sole backup system. Instead, system-level backups should be used as a supplement, which we will look at next.