Note:

If you want to create a new page for developers, you should create it on the Moodle Developer Resource site.

Backup 2.0 requirements

From MoodleDocs

Template:Development:Backup 2.0Moodle 2.0

Note: This page is a work-in-progress. Feedback and suggested improvements are welcome. Please join the discussion on moodle.org or use the page comments.

This page shows the analysis/justification/decision for all the drop in ideas detected/suggested along the last months mashed up with the main goals of the project. While pinpointing all the requirements of the new Backup 2.0, also we'll be defining the main list of tasks to fulfil them.

RQ01:

Enable Backup and restore of a Course and it's related meta courses IN ONE HIT to save on adminstration time

Meta courses are out in Moodle 2.0 and their functionality will be, somehow, replaced my the new Cohorts (a.k.a. site-wide groups). In any case, and as a general rule, any backup / restore operation involving more that one course is not backup / restore responsibility (i.e. the functionality is not built in there) but responsibility of newly scripts using the new backup API to do those "multiple operations".

RQ02:

Support incremental backups & restore

RQ03:

Support 1-activity backup

Supported!

RQ04:

Support 1-section backup (topic/week)

Supported!

RQ05:

Support anonymisation of personal data on backup

Supported! Right now it's limited to anonymize user information bits (name, email...) and related info (preferences, tags, personal files...) to be exported. There are two points that could be improved:

  • Improvements to the anonymizer (MDL-22158): Make information to "look" better, using random names and so on.
  • Be more intrusive (NOBUG): Also anonymize (replace) file submissions and friends by "template-blank" files.

RQ06:

Separate process and progress

This is one of the primary goals of the new subsystem. Already have two well defined points where visualization can happen (conditionally). The backup / restore UI (MDL-22142 - previous to process). And the output process (MDL-22144 - handled by output singleton). Both used only if necessary and not interfering the process itself at all. Also, logging (MDL-22143) has been separated from process and delegated to proper loggers. Finally, heartbeat information (MDL-22143 - needed to avoid browser timeouts) is also performed transparently by the process and developer doesn't need to do it manually any more.

RQ07:

XML format doesn't need to be radical different

While the original idea (at early Moodle 2.0 planning stages) was to keep the Backup 2.0 format as similar as possible with 1.x format, finally some core changes (new File API...), other requirements (like 1-activity, 1-section backups, see above...) and the need to modernize a bit the old format (uppercase, not using attributes...), have produced this original thoughts to change. So Moodle 2.0 will debut one new format, split along multiple files for easier reference / manipulation.

Note that contents will be basically the same, as far as contents are just "DB dumps". They just will be more organized along different files. See the general architecture page for more information about the new format.

RQ08:

Support restore of old (1.9 only?) backups

RQ09:

Hook in backup & restore to intercept & support other formats

RQ10:

One code base both for manual and scheduled backup

RQ11:

Scheduled restore

RQ12:

Fix restore so that one can also select to restore course settings

RQ13:

Fileless export/import

RQ14:

Export/import over mnet

RQ15:

OOP

RQ16:

Secure

RQ17:

Safe

RQ18:

file-less backups - if you have separate backups, import/export etc.

RQ19:

Allow to backup one category of courses. MDL-17187

RQ20:

Allow to mark courses to be excluded from scheduled backup manually

RQ21:

Avoid anti-timeout output when not running from browser. MDL-17282

RQ22:

Review related caps, cleaning them and adding missing bits, improving sec. consistency

RQ23:

Log all backups (both manual and scheduled). Improve logging in general

RQ24:

Separate each module's portion of XML into its own namespace

RQ25:

Use the namespaces to allow each module the option of validating it's XML content before processing

RQ26:

Roll dates

RQ27:

Backup would need to be called when publish a course on the community hub

RQ28:

Metadata... to be included in backup/restore. Something like Metadata

RQ29:

Allow backup of roles with permissions, assigns and overrides. MDL-17081