ASynchronous Backup and Restore Specification: Difference between revisions
From MoodleDocs
Damyon Wiese (talk | contribs) Created page with "{{Infobox Project |name = Asynchronous Backup and Restore |state = Proposed |tracker = MDL-28505 |discussion = - |contributors = - }} {{Moodle 2.5}} == Project goals == * Long-..." |
This page will not be migrated to new devdocs |
||
| (7 intermediate revisions by 3 users not shown) | |||
| Line 1: | Line 1: | ||
{{Template:WillNotMigrate}} | |||
{{DISPLAYTITLE:Asynchronous Backup and Restore Specification}} | |||
{{Infobox Project | {{Infobox Project | ||
|name = Asynchronous Backup and Restore | |name = Asynchronous Backup and Restore | ||
| Line 4: | Line 7: | ||
|tracker = MDL-28505 | |tracker = MDL-28505 | ||
|discussion = - | |discussion = - | ||
}} | }} | ||
== Project goals == | == Project goals == | ||
| Line 21: | Line 22: | ||
This project aims to: | 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 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) | ** 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) | ||
| Line 30: | Line 31: | ||
* 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 49: | Line 55: | ||
* Reuses existing backup/restore ui classes to generate the interface | * Reuses existing backup/restore ui classes to generate the interface | ||
* Instead of executing the operation saves the backup/restore controller to a queue | * 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 | * Provide a cli script for pulling N backups off the queue and executing them | ||
=== List of backup/restore types that should happen asynchronously === | |||
{| class="wikitable" | |||
|- | |||
! 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 === | === Database schema === | ||
| Line 55: | Line 84: | ||
''' Notes and things to discuss ''' | ''' Notes and things to discuss ''' | ||
{{DEFAULTSORT:Asynchronous_Backup_and_Restore_Specification}} | |||
Latest revision as of 15:35, 7 February 2025
| Warning: This page is no longer in use. The information contained on the page should NOT be seen as relevant or reliable. |
| 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
