I wrote a document describing a range of issues identified with backup/restore that prevent it functioning for large courses (either 'large' as in many activities, or 'large' as in large file sizes).
Michael asked us to file these in the Moodle tracker. I've made this issue to track them, and filed subtasks for all the specific items.
We don't intend to implement these ourselves at the present time. Also to note, I have set 'Affects version' as 2.3.x because that's where testing was done, but any changes on this scale clearly would not happen until a future Moodle major version.
Here is some context about use of backup and restore at the Open University, which may explain why these issues cause us problems. We expect some of these factors will apply to other institutions too, now or in future.
Many of our sites have the following characteristics which affect backup and restore performance:
- A large number of activities. (Max: 1,770 activities. Median: 70. 39 courses with 500+.)
- A large number of sections. (Max: 754 sections. Median: 100. 42 courses with 200+.)
- A large number of files (due to the use of interactive activities and per-user data). (Max: 57,000 different files. Median: 70. 66 courses with 1,000+.)
- Large files. Due to the provision of high-quality videos (and other files that include videos, such as EPUB3 ebooks), some of our sites contain a number of large files which add up to a large total size. (Max: 11GB in total. Median: 50MB. 129 courses have 1GB+.) (Note: These sizes include duplicate files with same contenthash; I wasn’t able to make a fast enough query that takes this into account.)
- A large number of users (several thousand).
We use backup and restore in two ways:
- The standard Moodle backup and restore features for certain manual tasks.
- A custom script to ‘roll forward’ a course to the next presentation (this uses the backup API and then the restore API, to automate the process).