ASynchronous Backup and Restore Specification: Difference between revisions
From MoodleDocs
Damyon Wiese (talk | contribs) No edit summary |
Damyon Wiese (talk | contribs) No edit summary |
||
Line 33: | Line 33: | ||
* MDL-28505 - Asynchronous course backup / restore | * MDL-28505 - Asynchronous course backup / restore | ||
== Notes from Hackfest 2012 == | |||
https://docs.google.com/document/d/1EUuZIukG56EnU-gjmvxjmD9biJZX3b5SSdjTnhL1mG4/edit?pli=1 | |||
== Implementation plan == | == Implementation plan == |
Revision as of 14:27, 28 October 2012
Asynchronous Backup and Restore | |
---|---|
Project state | Proposed |
Tracker issue | MDL-28505 |
Discussion | - |
Assignee | {{{assignee}}} |
Project goals
- Long-term goal: For all backup and restore operations in core Moodle to happen asynchronously
- Short-term goal: To allow a plugin to change the default Moodle operation so backup and restore operations happen asynchronously
- To prevent timeouts from long running backup/restore operations
- To allow backups and restores to happen on dedicated node(s) in a clustered environment
Project scope
This project does NOT change the UI of backup and restore except as required in order for users to monitor the backup and restore queue.
This project aims to:
- Make user course/activity backup and restore operations in core Moodle to happen asynchronously in order to:
- Allow backup and restores through the UI of courses that would normally fail with a timeout
- Allow backup and restore operations to be carried out on dedicated nodes in a cluster (to prevent session locks and load on the app serving nodes)
Things that must be decided and designed carefully:
- Reporting errors to the user from a backup and restore operation
- Sending notifications that a backup/restore is complete
- Preventing a user from queuing multiple identical backup restores
Relevant tracker issues
- MDL-28505 - Asynchronous course backup / restore
Notes from Hackfest 2012
https://docs.google.com/document/d/1EUuZIukG56EnU-gjmvxjmD9biJZX3b5SSdjTnhL1mG4/edit?pli=1
Implementation plan
Immediately (2.5?)
- New admin tool plugin for contrib called asyncbackup
Later (2.X)
- Move the code into core but perform the backup and restores in cron by default (to cater for small sites/default installs)
Design for plugin
- Should be a new admin tool plugin in contrib (asyncbackup)
- Removes default backup/restore links from the settings block for courses and activities
- Adds equivalent links which call it's own backup/restore pages
- Reuses existing backup/restore ui classes to generate the interface
- Instead of executing the operation saves the backup/restore controller to a queue
- Provide a cli script for pulling N backups off the queue and executing them
List of backup/restore types that should happen asynchronously
Operation | Should be asynchronous |
---|---|
UI triggered Course Backups | Yes |
UI triggered Activity Backups | Yes |
UI triggered Imports | Yes |
UI triggered Activity Duplication | No |
Automated Backups | Yes * |
(* They should at least be performed by the cli script and not by cron)
Database schema
Notes and things to discuss