Difference between revisions of "Backup 2.0"

Jump to: navigation, search
(Drop in ideas)
m (Drop in ideas)
Line 30: Line 30:
 
* Roll dates: on restore or import, allow instructor to input a start date, and roll all assignment, quiz, etc. dates forward based on the new start date.
 
* Roll dates: on restore or import, allow instructor to input a start date, and roll all assignment, quiz, etc. dates forward based on the new start date.
 
* Backup would need to be called when publish a course on the community hub ([https://docs.moodle.org/en/Community_hub#Publish_course course template])
 
* Backup would need to be called when publish a course on the community hub ([https://docs.moodle.org/en/Community_hub#Publish_course course template])
 +
* Metadata... to be included in backup/restore... something like: [[Metadata]]
  
 
=== General prerequisites ===
 
=== General prerequisites ===

Revision as of 08:38, 21 September 2009

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.

Moodle 2.0


Drop in ideas

  • Enable Backup and restore of a Course and it's related meta courses IN ONE HIT to save on adminstration time.
  • Support incremental backups & restore.
  • Support 1-activity backup.
  • Backup/restore one topic only (not just one activity) --Samuli Karevaara 21:29, 5 March 2009 (CST)
  • Support anonymisation of personal data on backup.
  • Separate process and progress. (Perhaps these classes I wrote can help)--Tim Hunt 19:41, 1 March 2009 (CST)
  • XML format doesn't need to be radical different (IMO).
  • Support restore of old (1.9 only?) backups.
  • Hook in backup & restore to intercept & support other formats (BB, IMS-CC...)
  • One code base both for manual and scheduled backup
  • Scheduled restore
  • Fix restore so that one can also select to restore course settings (they are currently backed up, but not restored in any restore function.)
  • Fileless export/import (aka fix import function so that one can choose to import blocks, course settings, etc. in addition to resources/activities)
  • Export/import over mnet
  • OOP.
  • Secure (don't handle non-allowed data, user matching on restore, salted passwords..)
  • Safe (some sort of "rollback" on failure - requires to have everything annotated somewhere - backup_ids or so).
  • file-less backups - if you have separate backups, import/export etc.
  • Allow to backup one category of courses (at the same time, one zip per course). MDL-17187
  • Allow to mark courses to be excluded from scheduled backup manually.
  • Avoid anti-timeout output when not running from browser. MDL-17282
  • Review related caps, cleaning them and adding missing bits, improving sec. consistency.
  • Log all backups (both manual and scheduled). Improve logging in general.
  • Separate each module's portion of XML into its own namespace.
  • Use the namespaces to allow each module the option of validating it's XML content before processing.
  • Roll dates: on restore or import, allow instructor to input a start date, and roll all assignment, quiz, etc. dates forward based on the new start date.
  • Backup would need to be called when publish a course on the community hub (course template)
  • Metadata... to be included in backup/restore... something like: Metadata

General prerequisites

Improve XML parsing

One of the major bottlenecks in backup and, specially, in restore reliability under Moodle 1.x has been the big amount of memory needed to handle those operations (see bugs like MDL-14302, MDL-15489, MDL-9838... and many others). While the whole XML file (moodle.xml) is parsed in a SAX way (hence, "streamed" and requiring small amounts of memory), we use to group some XML contents into "parts" in order to delegate the operations over those "parts" to different plugins (modules, blocks...). And problems arrive when some of those "parts" is big enough and processing them with the xml_parse_into_struct() function and the xmlize library uses exaggerated amounts of memory (for example, to process a 12.5MB file requires 311MB of memory, crazy!). So we need to switch to an alternate method to parse those "parts" using much less memory and to build the corresponding in-memory object with one acceptable throughput (speed).