Note: You are currently viewing documentation for Moodle 1.9. Up-to-date documentation for the latest stable version is available here: Backup and restore FAQ.

Talk:Backup and restore FAQ

From MoodleDocs

Text in Motion

While it appears that Helen moved most of the content of this FAQ to the Backup Doc, she did not move the comments..... the result being that we have lots of comments on this page that have no bearing to the content to which it seems to argue it applies..... to address that I am going to copy tall this to the backup doc page, and look forward to further comment and discussion before changing others work....

Comment

I have some concerns about some of the material provided in this FAQ. I am concerned that the command line resources are potentially being provided to new users who will get very very confused. I also think that the FAQ should, if anything, really be an index into the docs.

As far as specifics:

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.

Aside from ending in "to",  ;) , I have to challenge the accuracy of this statement in that I demonstrated that it can be next to impossible to download the save version of moodle as you had installed and it is just so very simple to back this up as well.

Here is an outline of a little script you can run on Unix to backup the database

This is not a script but a list of commands that one might consider in developing a script.

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 --create-options mydatabasename > moodle-database.sql
gzip moodle-database.sql

While it is obvious one can't move something that does not exist, I just know that someone is going to complain about this.

Because so many people get confused over -p[password] I do concur that longopts should be recommended, but I think it would also be helpful if the suggestions used longopts throughout, as in

mysqldump --user=[username] --password=[password] --opt [dbname]>[outputfile]

Of course, the error that usually results from placing a space between -p and a password regarding being unable to locate table "nameofthedatabasetobedumped" should be included.

Because the lines may break, it is important with longer lines either to force the break and add the \ and provide a placeholder for the system prompt.

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.

Arguably whether you are running mysql or not has nothing to do with whaty you used to back up your sql file or its extensions. Backed up files may also be in tgz format and could be zip'd or rar'd for that matter.

For the files, you can use rsync regularly to copy only the changed files to another host:

While the rsync info is great, it assume knowledge of how to set up rsync and provides no references of any sort. On the other hand, there is no discussion of simply tarring/gziping the files.

Since phpmyadmin is so prevalent it might be help to include information on using this tool, as well as information on dropping tables in an existing database.

And files don't try to do anything..... Perhaps as noted above a discussion of how to drop tables before importing the sql file might be helpful

But, as suggested, I think this should all be covered in the full docs in appropriate sections, with the FAQ simply pointing to the various doc sections.

--Marc Grober 14:59, 9 July 2008 (CDT)

Marc, thanks for your comments. As suggested, content has been moved from Backup and restore FAQ to other pages. Most likely there is more which can be moved. Please feel free to edit the section on creating a backup of your Moodle site in Site backup according to your comments. Any help is much appreciated, as I'm definitely not a backup expert ;-) --Helen Foster 08:49, 3 October 2008 (CDT)


What Backup and Restore does not do

Hi Tim, I notice you deleted the items I added to the Backup Restore FAQ. Could you answer them? I read through all of Backup/Restore and there is no written answer. From my experience, it seems blocks are not backed up. If that is not true, could you state explictly that they are not and why they are not. This is a frequent question by my teachers, and a source of frustration as well. I need to tell them clearly. I think the FAQ page is the right page to state that. Thanks, Don

Hi Don, as far as I know, standard blocks are backed up in a course backup and can be restored to a new course unless the site where the course is being restored to does not have the particular block enabled. Are you using a contributed block by any chance? If so, perhaps you could post in a Using Moodle forum about it. --Helen Foster 18:10, 20 April 2009 (UTC)
Hi Helen, thanks for the reply. As I look at all the blocks that our teachers are using, it seems most are standard HTML blocks. So am I correct to assume that all standard blocks are backed up and restored *except* HTML blocks? The FAQ should say so clearly. I would also like to know *why* HTML blocks are not backed up, but that is a less critical question and could be part of an Issue Tracker discussion. This definitely is a high irritant to our teachers who are manually copying and pasting their blocks across the site. --Don Hinkelman 01:49, 21 April 2009 (UTC)
Don, as you saw, I added a comment to your talk page to explained why I deleted your incorrect speculation from the FAQ page. All blocks, including HTML blocks are backed up. At least they were when I fixed MDL-12066.--Tim Hunt 03:29, 21 April 2009 (UTC)

References

A big THANK YOU to Eloy Lafuente (stronk7) :-) Helen Foster 26 November 2005 17:34 (WST)