バックアップおよびリストアFAQ

翻訳中です--Tatsuro Ueda 2006年8月9日 (水) 14:56 (WST)

サイト・バックアップ

サイト・バックアップは、Moodleのアップグレードで説明されているとおり、すべてのデータを最も利用しやすい形で、もっともすばやく復旧できるような形で、保存するのに推奨されます。

コース・バックアップ

コース・バックアップはバックアップページで設定します。コース・バックアップは時間とCPU利用の観点から見ると、より高価です。あなたのサイトを稼動状態に戻すのにかかる時間は、より長くなります。コース・バックアップは、再利用や配布のためにコースの「新鮮な」コピーを得るのに便利ですが、第1のバックアップの仕組みとして使うべきでは決してありません（あなたのホストが前述のサイト・バックアップを禁止してるのでなければ）。定期的なバックアップを取るためには、あなたはcronが定期的に実行されるよう設定しなければなりません。cronの使い方 を参照してください。

Moodleサイト全体をバックアップするには、どうしたらよいですか？

あなたがコピーすべきものは大きく分けて2つあります。データベースとアップロードされたファイルです。Moodleのスクリプトそのものは、それらに比べれば重要なものではありません。なぜなら、あなたはいつでも必要に応じて最新のものをダウンロードできるからです。

バックアップを取るにはたくさんの方法があります。ここではUnix上で実行することのできるデータベースをバックアップするための短いスクリプトを紹介します（このようなスクリプトはcronタスクを通して毎日実行すると良いでしょう）。

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

ファイルの方は、以下のようにしてrsyncを普通に使うことで別のホストに内容が変わったファイルだけコピーすることができます。

rsync -auvtz --delete -e ssh mysshusername@example.com:/my/server/directory /my/backup/directory/

文字のエンコード

Moodleのデータベースをすべてダンプするときは、管理者は文字のエンコードの問題が起きないように気をつけてください。場合によってはmysqldumpやphpmydaminによって作られたバックアップは、spurious A charactersのために文字のエンコードが適切に処理されていないかもしれません。解決策としては、データをUTF-8でダンプするmySQL Administrator 1.1や他のツールを使うことです。

コース・バックアップに含まれないのはどんなデータですか？

バックアップを設定するときにすべてのオプションを選べば、そのコースのほぼすべてのデータを含めることができます。しかしながら、いくつかのものはバックアップされないということに気をつけてください：

• クイズの質問は、少なくとも1つの質問がカテゴリからクイズに追加されているときだけバックアップされます
• 尺度は、少なくとも1つの活動で使われているときだけバックアップされます。

エラー：古いバックアップ・データを削除中にエラーが起きました

バックアップ（やリストア）作業のこの部分は、以下のようなタスクを実行することで、前回の実行で使われた古い情報を削除しようとします。

• 古いレコードを「backup_ids」テーブルから削除：そのテーブルが存在するかチェックし、やり直してみてください

• 古いレコードを「backup_files」テーブルから削除：そのテーブルが存在するかチェックし、やり直してみてください

• 古いファイルを「moodledata/temp/backup」から削除：そのディレクトリを完全に削除し、やり直してみてください

テーブルを修復するには、様々な方法があります。MySQL Adminを使うことのもひとつの手です。

XMLエラー：～行目に不適切な整形（間違った要素）があります

リストアの過程ではいつでもこの問題が現れることがあります。これが起きるのは、バックアップファイルの中に正確な操作を邪魔するような何か間違いをXMLパーサがを見つけたときです。普通は、元のコースにコピー＆ペーストで加えられた何かの「使ってはいけない」文字によって起きます（制御文字や間違った連なりなど）。

この問題に対処する一番良い手段は：

• 問題のあるバックアップファイルを、どこかに作った空のフォルダで解凍します

• moodle.xmlをFirefoxで開きます。これで、どこで問題が起きているか（その文字そのものまで）わかります。

• そのmoodle.xmlファイルを、何かUTF8互換のエディタで編集してその文字を削除し、上書き保存します。

• エラーが表示されなくなるまで、そのmoodle.xmlファイルを何度もFirefoxで試してみます。

• すべてを再度圧縮します（フォルダの中身すべて・・・ただし、フォルダ自身も含めないこと！）

• コースをリストアします。今度は動くはずです。

なお、もし可能なら、元のコースの問題もMoodleそのものから解決することがとても望ましいことです。そうやって一度「修復」されれば、将来新しいバックアップファイルを作っても問題は起きないでしょう。

コースのいくつかが保存されていない！

この問題の原因は3つ考えられます。

1. エラー - バックアップ作業がエラーを見つけて特定のコースのバックアップが終了しなかったときに起きます。これらは「制御された」エラーであり定期バックアップは次のコースから続けられます。

2. 終わっていない - バックアップ作業が未知の原因で中止されたときに起きます。cronが次に実行されたとき、それは前回の実行が異常だったことを検知して、その問題のコースをスキップして続けます。考えられる解決策としては、インストールの際のPHP/Apacheの上限を引き上げることかもしれません（メモリー、実行回数など）。ログ表を見ることでその「頓挫」が正確にいつ起きたかを見つけることができるでしょうし（通常はphpの変数であるmax_execution_timeに伴う問題です）、すべてのコースが壊れているポイントを正確に見つけることができるかもしれません（通常は内部のzipライブラリのためで、代わりに外部の実行ファイルを試してみてください）。

3. スキップされた - そのコースが生徒たちから見えなくて1ヶ月間（31日）修正されていなかったときに起きます。処理時間を節約するためにこのタイプのコースはスキップされます。これは間違った状況ではなくて機能であり、バックアップする必要のないたくさんの見ることのできない古いコースがあるサイトで特に便利です。

1.6以前のISO-8859-1でないバックアップをMoodle 1.6にUnicodeでリストアする

完全にISO-8859-1でない内容のバックアップファイルはすべて、Unicodeで稼動しているMoodle 1.6（以上）にリストアする際、問題となります。以下を試してみてください：

1. Moodle 1.5.x（利用可能な最新バージョン）を新しくインストールしてください
2. あなたのコースをすべてそこでリストアしてください（もともと動いていたのなら、動くはずです）
3. あなたのサイトをMoodle 1.6にアップグレードしてUTF-8統合スクリプトを実行してください
4. あなたのコースを再度バックアップしてください

これにより完全にUTF-8であるバックアップのファイルの新しいセットがつくられ、Moodle 1.6で問題なく使うことができるでしょう。

関連情報

• Moodleを使う：バックアップとリストア
• Moodleダウンロード：統合 - MySQL Adminがダウンロードできます

External links

• Repairing Database Corruption in MySQL

Moodle FAQ

• 管理
• バックアップ
• 決定
• 開発者
• インストール
• 学生
• 教授法

Site backups

Site backups, as explained in upgrading Moodle, are recommended in order to have all data saved with the best confidence and the shortest recovery time.

Course backups

Course backups, configured on the backup page, are more expensive in terms of time and CPU usage. The recovery time to have your site running again is longer. Course backups are useful for obtaining "fresh" copies of courses to be re-used or distributed individually, however they should never be used as a primary backup system (unless your hosting doesn't allow the preferred site backups). In order to make scheduled backups, you have to setup CRON to run periodically. Please refer to the cron instructions.

How do I backup my whole Moodle site?

There are two main things you need to make a copy of - the database and the uploaded files. The Moodle scripts themselves are less important, since you can always download a fresh copy if you have to.

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 -h example.com -u myusername --password=mypassword -C -Q -e -a mydatabasename > moodle-database.sql
gzip moodle-database.sql

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/

Character Encoding

When dumping the entire Moodle database, Administrators should be careful to watch for possible character encoding issues. In some instances, backups created with mysqldump or 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.

What data is not contained in course backups?

By selecting all the options when setting up the backup you can include almost all the data in the course. However you should be aware of the fact that some things are not backed up:

• Quiz questions are only backed up if at least one question from their category has been added to a quiz.
• Scales are only backed up if they are used by at least one activity.

Error: An error occurred deleting old backup data

This part of the backup (or restore) procedure tries to delete old info, used in previous executions, performing the following tasks:

• Delete old records from "backup_ids" table: Check the table exists, repair it and try again.

• Delete old records from "backup_files" table: Check the table exists, repair it and try again.

• Delete old files from "moodledata/temp/backup": Delete the dir completely and try again.

There are various ways of repairing tables, including using MySQL Admin.

XML error: not well-formed (invalid token) at line YYYY

This problem can appear at any point in the restore process. It's caused when the XML parser detects something incorrect in the backup file that prevent correct operation. Usually, it's caused by some "illegal" characters added in the original course due to some copy/paste of text containing them (control characters, or invalid sequences...).

The best method to handle this issue is:

• Unzip the problematic backup file under one empty folder.

• Open the moodle.xml with Firefox. It will show you where (exact char) the problem is happening.

• Edit the moodle.xml file with some UTF8-compatible editor and delete such characters. Save changes.

• Test the moodle.xml file again with Firefox until no error was displayed.

• Zip everything again (all the folder contents but the folder itself!).

• Restore the course. It should work now.

Also, if possible, it's highly recommended to solve those problems in the original course too from Moodle itself. Once "repaired" there, problems will be out if you create new backup files in the future.

Some of your courses weren't saved!!

There are three possible causes of this problem:

1. Error - this happens when the backup procedure has found an error and so hasn't finished the backup of a particular course. These are "controlled" errors and the scheduled backup continues with the next course.

2. Unfinished - this happens when the backup procedure dies without knowing why. When the cron is next executed it detects that the last execution went wrong, and continues skipping the problematic course. A possible solution would be to raise the PHP/Apache limit in your installation (memory, time of execution...). By taking a look to your log tables you should be able to see if the "crash" is happening at exact time intervals (usually a problem with the max_execution_time php's variable), or if there is some exact point were all the courses are breaking (generally internal zip libraries, try to switch to external executables instead).

3. Skipped - this happens when the course isn't visible to your students and it hasn't been modified in the last month (31 days). To save process time this type of courses are skipped on purpose. This isn't an error situation but a feature one, specially useful under sites with a lot of invisible old courses where it has no too much sense to backup them always.

Restoring pre 1.6 non-ISO-8859-1 backups to Moodle 1.6 - Unicode

Any backup files with contents which are not 100% ISO-8859-1 will be a problem to restore to Moodle 1.6 (and upwards) running under Unicode. Instead, please try the following:

1. Make a clean install of Moodle 1.5.x (the latest version available)
2. Restore all your courses there (they should work if they were working originally)
3. Upgrade your site to Moodle 1.6 and run the UTF-8 migration script
4. Backup your courses again

This will produce a new set of backup files that will be 100% UTF-8 and you will be able to use them with Moodle 1.6 without any problems.

See also

• Using Moodle: Backup and Restore
• Moodle Download: Integrations - MySQL Admin for download

External links

• Repairing Database Corruption in MySQL