Perth Hackfest October 2012/Asynchronous Backup System spec: Difference between revisions
(Created page with "== Introduction == This page details a proposal to introduce a new plugable backup system that would allow for backup/restore to be handled asynchronously. == Purpose == == Des...") |
No edit summary |
||
| Line 3: | Line 3: | ||
== Purpose == | == Purpose == | ||
The Moodle backup and restore system is a powerful and resource-intensive system. On large, busy sites, the active use of backup and restore can significantly impact successful operation by negatively impacting performance. Often times the necessary workflows of an organization using Moodle requires backup and restore being peformed at the same time as a peak user period (e.g. educational institution setting up a new session while previous session carrying out an exam period). | |||
== Design == | Also, very large backup operations can time-out in the web environment, preventing operations from successfully completing. | ||
As a solution, backup and restore could be redesigned in a way that would allow for these operations to be scheduled and handled asynchronously rather than synchronously on-demand. This system would also allow for the prevention of synchronous backups as specified by the site administrators. | |||
== Requirements == | |||
* Ability to run the backup/restore operations in a "managed" (scheduled and queued) way to reduce impact on Moodle performance. | |||
* Ability to separate the backup/restore operations from synchronous operation on the Moodle server. | |||
* Ability to monitor progress and notify completion and other status of operations. | |||
* Ability to disable synchronous backup/restore (live) functions from specified users. | |||
== Design Ideas == | |||
Revision as of 18:57, 12 November 2012
Introduction
This page details a proposal to introduce a new plugable backup system that would allow for backup/restore to be handled asynchronously.
Purpose
The Moodle backup and restore system is a powerful and resource-intensive system. On large, busy sites, the active use of backup and restore can significantly impact successful operation by negatively impacting performance. Often times the necessary workflows of an organization using Moodle requires backup and restore being peformed at the same time as a peak user period (e.g. educational institution setting up a new session while previous session carrying out an exam period).
Also, very large backup operations can time-out in the web environment, preventing operations from successfully completing.
As a solution, backup and restore could be redesigned in a way that would allow for these operations to be scheduled and handled asynchronously rather than synchronously on-demand. This system would also allow for the prevention of synchronous backups as specified by the site administrators.
Requirements
- Ability to run the backup/restore operations in a "managed" (scheduled and queued) way to reduce impact on Moodle performance.
- Ability to separate the backup/restore operations from synchronous operation on the Moodle server.
- Ability to monitor progress and notify completion and other status of operations.
- Ability to disable synchronous backup/restore (live) functions from specified users.
