Following is further info on this; I may not have all the concepts exactly correct, but it will help others to provide some feedback on Moodle and its best practice backup procedures specifically.
Some database software incorporates its own backup of databases. These database backups, which are then closed files, are moved to another volume (on the same host or another), and optionally backed up with dedicated backup software. Moodle can do such initial backups triggered by chron.php, etc.
One reason for backing up with this two-fold method is so that a complete backup of a database can be made (on a closed file). Another reason is that some backup software can actually lock a file until it is backed up, which can cause problems, at least slowdowns with db operation -- some backup software puts locks on disc sectors of a volume being backed up, which can cause database software to corrupt data (depending on the backup software and database in use). In the latter case, the volume with live data is (in good practice) never backed up (by external backup software); the db software backs up the db's, which are then moved to another volume, and backed up to tape, etc.
Comments on good Moodle backup procedures? Thanks.
Any backup software should be fine for backing up your moodledata directory.
You're correct in being concerned about the backing up of database data. A straight backup of the database's data files (do you know which volume these are stored on?) is not a good idea.
We have Moodle execute its own backup (of user & course data & files), backup the moodledata directories and do a database-level backup of the entire system. Both are written to a volume serviced by our regular backup regime.
A database-level backup is able to execute a backup as a transaction - ensuring good data integrity. That generated file + moodle data (+ of course your moodle application files of course) is most likely to accurately restore in the case of a catastrophic failure.
Unless you have made modifications to Moodle code, the only files from the Moodle application directory that should be backed up are the Language files (if you've changed custom strings to suit your installation) and the Theme files, however of course these wouldn't usually be subject to regular backups. I suspect too that if you're making modifications you're using some sort of version control (CVS / SVN / Git).
All the best with developing your backup / disaster-recovery plans
You're saying to backup the database via Moodle regulary (and use these backups for restore, if necessary), and also to backup moodledata directories.
The one issue I'm still not clear on is if running backup software on a volume that houses Moodle directories and database/s, while Moodle services are running, is OK or not, in terms of possible corruption problems by: locking sectors that might be in use by the database software; and/or locking Moodle files themselves. To repeat, there are some databases where this can happen, but I have no idea if this is an issue with Moodle / MySQL or not. Thanks.
It's not the operation of Moodle that puts your database files at risk during a backup, it's having MySQL itself active. You're unlikely to corrupt the running database by running a backup over its files, but you won't get a valid backup either. If you subsequently tried to restore the files you had backed up while MySQL was live, then you would have a corrupted database.
Backup of the actual MySQL data files is dangerous unless you shutdown the database itself. There are ways to do it, but not simple ones. Doing a mysqldump on the live database and then backing up the dump files is a lot safer, which is the method that I think the backup script uses.
Backup of the actual MySQL data files is dangerous unless you shutdown the database itself. There are ways to do it, but not simple ones.
That used to be the case, but I think nowadays mysqlhotcopy is supported. It automates the 'not so simple tricks' around copying around the DB files 'hot'.
If you are using PostgreSQL 8.1, you can do something similar with PITR-based techniques, though that's a lot more complicated.
(Edit: mysqldump and pgdump are better and more reliable than "hot" backup methods. I just wanted to mention that mysqlhotcopy exists, and seems to be supported as part of official mysql. Used to be an unofficial hack )