ASynchronous Backup and Restore Specification

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

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:

Move the code into core but perform the backup and restores in cron by default (to cater for small sites/default installs)

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

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)

Notes and things to discuss