Note: You are currently viewing documentation for Moodle 3.11. Up-to-date documentation for the latest stable version of Moodle may be available here: Site backup.

Site backup: Difference between revisions

From MoodleDocs
(→‎What needs to be backed up?: added links, edited words, created tip, etc)
(→‎Database: Added --default-character-set: MariaDB ≥ 10.3.11 defaults to utf8mb4, others default to utf8)
(41 intermediate revisions by 10 users not shown)
Line 1: Line 1:
Site backups are recommended in order to have all data saved with the best confidence and the shortest recovery time.
{{Backup}}
A site backup allows a site administrator to save everything associated with a moodle site. These backups can be restored to bring a site back to the point in time when the backup was made. 
 
Performing regular backups are highly recommended to reduce the amount of lost information in the event of a problem on the site and to speed the overall recovery process.


== What needs to be backed up? ==
== What needs to be backed up? ==


A Moodle system comprises three parts:
A Moodle system comprises three parts:
# The data stored in the '''[[Development:Database schema introduction|database]]''' (For example, a MySQL database)
# The data stored in the database (For example, a MySQL database)
# The uploaded '''[[Files|files]]''' (For example, site and course files uploaded via Moodle located in moodledata)
# The uploaded files (For example, site and course files uploaded via Moodle located in moodledata)
# The '''Moodle code''' (For example, everything in server/htdocs/moodle)
# The '''Moodle code''' (For example, everything in server/htdocs/moodle)
You can confirm where all these things are located in a Moodle installation by checking the '''[[Configuration file|config.php]]''' file.  
You can confirm where all these things are located in a Moodle installation by checking the '''[[Configuration file|config.php]]''' file.  


:# '''$CFG->dbna''' shows the database name
:# '''$CFG->dbname''' shows the database name
:# '''$CFG->prefix''' shows the the database table name prefix
:# '''$CFG->prefix''' shows the the database table name prefix
:# '''$CFG->dataroot''' controls where the ''uploaded files'' are stored; and
:# '''$CFG->dataroot''' controls where the ''uploaded files'' are stored; and
:# '''$CFG->dirroot''' points to where the ''code'' is stored.
:# '''$CFG->wwwroot''' points to where the ''code'' is stored.


:Tip: Generally speaking, the database ("dbna and prefix") and the uploaded files (dataroot) are the two most important to copy on a regular basis. These contain information that will change most often. The Moodle code (dirroot) is less important as a frequent backup, since it will only change when the the actual code is changed through upgrades, addins and code tweaks.
;Tip  
Generally speaking, the database ("dbname and prefix") and the uploaded files (dataroot) are the two most important to copy on a regular basis. These contain information that will change most often.  
 
The Moodle code (wwwroot) is less important as a frequent backup, since it will only change when the the actual code is changed through upgrades, addins and code tweaks. You can always get a copy of the standard Moodle code from http://download.moodle.org so you only have to backup the parts you added or changed yourself.


== Creating a backup of your Moodle site ==
== Creating a backup of your Moodle site ==
Line 26: Line 32:
  cd /my/backup/directory
  cd /my/backup/directory
  mv moodle-database.sql.gz moodle-database-old.sql.gz
  mv moodle-database.sql.gz moodle-database-old.sql.gz
  mysqldump -h example.com -u myusername --password=mypassword -C -Q -e --create-options mydatabasename > moodle-database.sql
  mysqldump --default-character-set=utf8mb4 -h example.com -u myusername --password=mypassword -C -Q -e --create-options mydatabasename > moodle-database.sql
  gzip moodle-database.sql
  gzip moodle-database.sql
Also consider using an option to help ensure that the backup is consistent (e.g. avoid the data changing half-way through the backup), e.g. for MySQL/MariaDB and mysqldump try  [https://dev.mysql.com/doc/refman/5.7/en/mysqldump.html#option_mysqldump_single-transaction --single-transaction].


==== Character encoding ====
==== Character encoding ====
Make sure that a database backup uses the correct character encoding. In most databases, use [[UTF-8]].
When dumping the entire Moodle database, check for possible character encoding issues. In some instances, backups created with [http://dev.mysql.com/doc/refman/5.1/en/mysqldump.html mysqldump] or [http://www.phpmyadmin.net phpMyAdmin] may not properly encode all of the data.  This will result in non-readable characters when the database is restored.


When dumping the entire Moodle database, administrators should be careful to watch for possible character encoding issues. In some instances, backups created with [http://dev.mysql.com/doc/refman/5.1/en/mysqldump.html mysqldump] or [http://www.phpmyadmin.net phpMyAdmin] may not properly encode all of the data resulting in spurious A characters. One solution is to use MySQL Administrator 1.1 or another tool that will force a UTF-8 dump of the data.
:''Tip'': One solution is to use MySQL Administrator 1.1 or another tool that will force a UTF-8 dump of the data.


==== Tools for database backups ====
==== Tools for database backups ====


* [http://www.phpmyadmin.net phpMyAdmin] is the tool of choice with most web hosting providers.
; phpMyAdmin
* [http://www.mysqldumper.de/en/ MySQLDumper] is a backup script for MySQL databases, written in PHP and Perl. MySQLDumper uses a proprietary technique to avoid execution interruption when running PHP scripts (the max. execution time is usually set to 30 seconds). MySQLDumper also cares for the encoding problems mentioned above. It also works with compressed files.
: [http://www.phpmyadmin.net phpMyAdmin] is the tool of choice with most web hosting providers.
 
=== Data files ===
 
They are just files, so all you have to do is make a copy of them somewhere safe. You may then want to compress that copy using zip or gzip.
 
Since typically, a lot of the files will stay the same, and only a few new ones will be uploaded or edited, you can use a tool like rsync to only copy the changed files, which is more efficient.
 
====Using rsync to backup files====
 
For the files, you can use '''rsync''' regularly to copy only the changed files to another host:
 
rsync -auvtz --delete -e ssh mysshusername@example.com:/my/server/directory /my/backup/directory/
 
If you want to run the cronscript at the machine you are running Moodle at you have to use following rsync syntax
 
rsync -auvtz --delete -e ssh /path/to/local/folder/ remoteuser@remoteserver:/path/to/remote/folder/
 
If you do not want the root mailbox be spammed by statusmails of the rsync use:
  rsync -autzq --delete -e ssh /path/to/local/folder/ remoteuser@remoteserver:/path/to/remote/folder/
 
If your Moodle hosting provider does not allow ssh (or just do not provide it) and you have simple ftp access with a username and a password
you can also use:
 
mkdir /tmp/remote-folder
curlftpfs ftp://username:password@ftp.your-site.com /tmp/remote-folder
rsync -auvtz --delete /tmp/remote-folder /my/local/backup/folder/
umount /tmp/remote-folder
rmdir /tmp/remote-folder


Entire database backup can be accomplished (tested on cPanel web interface) using the following command:
; MySQLDumper
: [https://sourceforge.net/projects/mysqldumper/ MySQLDumper] is a backup script for MySQL databases, written in PHP and Perl. MySQLDumper uses a proprietary technique to avoid execution interruption when running PHP scripts (the max. execution time is usually set to 30 seconds). MySQLDumper also cares for the encoding problems mentioned above. It also works with compressed files and allows setting up regular cron jobs for updating and updating to a remote FTP site.


wget --http-user=username --http-password=password http://your-site.com:2082/getsqlbackup/moodle.sql.gz
; AutoMySQLBackup
and the entire backup of the Moodle code tree:
: [https://github.com/sixhop/AutoMySQLBackup AutoMySQLBackup] is a backup script for MySQL databases, written in PHP. AutoMySQLBackup will create Daily, Weekly and Monthly backups of one or more of your MySQL databases from one or more of your MySQL servers. Features include email notification, compression and encryption, configurable backup rotation, incremental database backups, and more.
wget --http-user=username --http-password=password http://your-site.com:2082/getbackup/backup-your-site.com-`date +"%-m-%d-%Y"`.tar.gz


Some customization might be needed for other web interface like (webmin?)
=== Uploaded files (moodledata) ===
Through the Moodle interface, users can upload or create files and folders.  These are located in a directory, often called "moodledata". Since they are just files and folders, there are many different ways to backup or copy moodledata. 


=== Code files ===
* For example, using a file transfer program, copy the entire moodledata directory to a different area, drive or computer.  Example of file transfer programs include: FTP, WinSP, wget, rsync.


If you have not customised the code, you can always download a new copy. However, it is still a good idea to keep your own local copy with the rest of your backup, and if you are doing customisation, it is essential. The steps are the same as for backing up the data files.
* You might use a compression program  to create compact files (tar, zip. 7z, XZ, BZIP2, GZIP, and WIM are a few file formats) of the entire directory. This can be done before or after file transfers.


== Restoring a site backup ==
; Tips
* Typically not all moodledata files change between regular/periodic backups. A new Administrator might want to look into [http://en.wikipedia.org/wiki/Incremental_backup incremental or other efficient backups] procedures.
* Depending upon the operating environment there are many tools for backing up server files and ways of backing up moodledata.  See [[Tools_for_backing_up_server_files]] for tips on using rsync, FTP or Wget.


If you have followed the above instructions and created a backup of a Moodle site, you may need to know how to restore the site backup you created. Here is a set of basic steps that make up the restore process.
=== Moodle code ===
Backing up the Moodle code, will be similar to backing up moodledata. See [[Tools for backing up server files]].


1. Rename the original Moodle directory to something different (so you still have it) and copy the backed up Moodle directory or a newly downloaded Moodle directory in its place.
;Tip
 
It is always a good idea to have several backup copies of your Moodle code files. While you can always download a fresh base copy of the Moodle code from http://download.moodle.org, you might have customized that code. It is a good idea to create a separate backup of your Moodle code before you customize the codeThis includes installing [[Contributed code]], [[Themes]] and upgrading.
2. If you are running MySQL, a backup of the database should be a .sql, .gz or .tar.gz file.  If it is .tar.gz or .gz you need to extract it until it is an sql file.
 
tar -xzvf moodlesqlfile.tar.gz
 
3. If you are running mysql, import the SQL file back into a newly created database on the MySQL server.  Be careful here, some backups try to import right back into the same working database that Moodle is connected to.  This causes database problems that damage a Moodle installation.  The best thing to do is make a new database, restore the backed up database into it, and change the Moodle '''config.php''' file to connect to this new database (this way you still have the original database).
 
Once you have created the new database:
 
  mysql -p new_database < moodlesqlfile.sql
 
For other databases, follow their instructions for restoring a backup.


== See also ==
== See also ==
 
* [https://www.youtube.com/watch?v=k5rwTy3sNh0 Screencast: How to back up a Moodle site] (thanks to Bruce Chambr)
*[[Backup and restore FAQ]]
*[[Site restore]] Now that you have a backup, how to restore it
*[[Automated course backup]]
* [[Moodle migration]] - move a Moodle site to a different server
*The section "Backup important data" in [[Upgrading]]
* Using Moodle [http://moodle.org/mod/forum/discuss.php?d=140949 Site DatabaseBackup Using phpMyAdmin] forum discussion
*[http://www.moodletutorials.org/view_video.php?viewkey=e257e44aa9d5bade97ba Video showing how to backup a whole Moodle site (on Linux)]
* [[Moodle migration]]
* Using Moodle [http://moodle.org/mod/forum/discuss.php?d=140949 Site Backup Using phpMyAdmin] forum discussion
* [[Site Backup for Low-tech Users]]
* [[Site Backup for Low-tech Users]]
[[Category:Backup]]


[[de:Sicherung der Moodle-Installation]]
[[de:Sicherung der Moodle-Installation]]
[[ja:サイトバックアップ]]
[[ja:サイトバックアップ]]
[[es:Copia de seguridad del sitio]]
[[fr:Sauvegarde de site]]

Revision as of 11:38, 16 April 2021

A site backup allows a site administrator to save everything associated with a moodle site. These backups can be restored to bring a site back to the point in time when the backup was made.

Performing regular backups are highly recommended to reduce the amount of lost information in the event of a problem on the site and to speed the overall recovery process.

What needs to be backed up?

A Moodle system comprises three parts:

  1. The data stored in the database (For example, a MySQL database)
  2. The uploaded files (For example, site and course files uploaded via Moodle located in moodledata)
  3. The Moodle code (For example, everything in server/htdocs/moodle)

You can confirm where all these things are located in a Moodle installation by checking the config.php file.

  1. $CFG->dbname shows the database name
  2. $CFG->prefix shows the the database table name prefix
  3. $CFG->dataroot controls where the uploaded files are stored; and
  4. $CFG->wwwroot points to where the code is stored.
Tip

Generally speaking, the database ("dbname and prefix") and the uploaded files (dataroot) are the two most important to copy on a regular basis. These contain information that will change most often.

The Moodle code (wwwroot) is less important as a frequent backup, since it will only change when the the actual code is changed through upgrades, addins and code tweaks. You can always get a copy of the standard Moodle code from http://download.moodle.org so you only have to backup the parts you added or changed yourself.

Creating a backup of your Moodle site

Database

The right way to back up your database depends on which database system you are using. The instructions below are one way to back up a MySQL database. Another option would be to use a tool like phpMyAdmin to manually make a backup. The documentation for your database will give more options.

There are many ways to do such backups. Here is an outline of a little script you can run on Unix to backup the database (it works well to have such a script run daily via a cron task):

cd /my/backup/directory
mv moodle-database.sql.gz moodle-database-old.sql.gz
mysqldump --default-character-set=utf8mb4 -h example.com -u myusername --password=mypassword -C -Q -e --create-options mydatabasename > moodle-database.sql
gzip moodle-database.sql

Also consider using an option to help ensure that the backup is consistent (e.g. avoid the data changing half-way through the backup), e.g. for MySQL/MariaDB and mysqldump try --single-transaction.

Character encoding

Make sure that a database backup uses the correct character encoding. In most databases, use UTF-8.

When dumping the entire Moodle database, check for possible character encoding issues. In some instances, backups created with mysqldump or phpMyAdmin may not properly encode all of the data. This will result in non-readable characters when the database is restored.

Tip: One solution is to use MySQL Administrator 1.1 or another tool that will force a UTF-8 dump of the data.

Tools for database backups

phpMyAdmin
phpMyAdmin is the tool of choice with most web hosting providers.
MySQLDumper
MySQLDumper is a backup script for MySQL databases, written in PHP and Perl. MySQLDumper uses a proprietary technique to avoid execution interruption when running PHP scripts (the max. execution time is usually set to 30 seconds). MySQLDumper also cares for the encoding problems mentioned above. It also works with compressed files and allows setting up regular cron jobs for updating and updating to a remote FTP site.
AutoMySQLBackup
AutoMySQLBackup is a backup script for MySQL databases, written in PHP. AutoMySQLBackup will create Daily, Weekly and Monthly backups of one or more of your MySQL databases from one or more of your MySQL servers. Features include email notification, compression and encryption, configurable backup rotation, incremental database backups, and more.

Uploaded files (moodledata)

Through the Moodle interface, users can upload or create files and folders. These are located in a directory, often called "moodledata". Since they are just files and folders, there are many different ways to backup or copy moodledata.

  • For example, using a file transfer program, copy the entire moodledata directory to a different area, drive or computer. Example of file transfer programs include: FTP, WinSP, wget, rsync.
  • You might use a compression program to create compact files (tar, zip. 7z, XZ, BZIP2, GZIP, and WIM are a few file formats) of the entire directory. This can be done before or after file transfers.
Tips
  • Typically not all moodledata files change between regular/periodic backups. A new Administrator might want to look into incremental or other efficient backups procedures.
  • Depending upon the operating environment there are many tools for backing up server files and ways of backing up moodledata. See Tools_for_backing_up_server_files for tips on using rsync, FTP or Wget.

Moodle code

Backing up the Moodle code, will be similar to backing up moodledata. See Tools for backing up server files.

Tip

It is always a good idea to have several backup copies of your Moodle code files. While you can always download a fresh base copy of the Moodle code from http://download.moodle.org, you might have customized that code. It is a good idea to create a separate backup of your Moodle code before you customize the code. This includes installing Contributed code, Themes and upgrading.

See also