ASynchronous Backup and Restore Specification: Difference between revisions
From MoodleDocs
Damyon Wiese (talk | contribs) No edit summary |
m (Title was "ASynchronous" and I made the "S" lower case to be "Asynchronous") |
||
(4 intermediate revisions by 2 users not shown) | |||
Line 1: | Line 1: | ||
{{DISPLAYTITLE:Asynchronous Backup and Restore Specification}} | |||
{{Infobox Project | {{Infobox Project | ||
|name = Asynchronous Backup and Restore | |name = Asynchronous Backup and Restore | ||
Line 4: | Line 5: | ||
|tracker = MDL-28505 | |tracker = MDL-28505 | ||
|discussion = - | |discussion = - | ||
}} | }} | ||
Line 29: | Line 29: | ||
* Sending notifications that a backup/restore is complete | * Sending notifications that a backup/restore is complete | ||
* Preventing a user from queuing multiple identical backup restores | * Preventing a user from queuing multiple identical backup restores | ||
* Allow cancelling a backup/restore | |||
== Relevant tracker issues == | == Relevant tracker issues == | ||
* 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 == | ||
Line 51: | Line 56: | ||
=== List of backup/restore types that should happen asynchronously === | === List of backup/restore types that should happen asynchronously === | ||
{| class=" | {| class="wikitable" | ||
|- | |- | ||
! Operation | ! Operation | ||
Line 77: | Line 82: | ||
''' Notes and things to discuss ''' | ''' Notes and things to discuss ''' | ||
{{DEFAULTSORT:Asynchronous_Backup_and_Restore_Specification}} |
Latest revision as of 14:45, 11 April 2024
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
- Allow cancelling a backup/restore
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