Note: You are currently viewing documentation for Moodle 2.8. Up-to-date documentation for the latest stable version of Moodle may be available here: Backup 2.0.

Development:Backup 2.0: Difference between revisions

From MoodleDocs
(New page: === Drop in ideas === - Support incremental backups & restore. - Support 1-activity backup. - Support anonymisation of personal data on backup. - Separate process and progress. - Support ...)
 
No edit summary
Line 1: Line 1:
=== Drop in ideas ===
=== Drop in ideas ===


- Support incremental backups & restore.
* Support incremental backups & restore.
- Support 1-activity backup.
* Support 1-activity backup.
- Support anonymisation of personal data on backup.
* Support anonymisation of personal data on backup.
- Separate process and progress.
* Separate process and progress.
- Support restore of old (1.9 only?) backups.
* XML format doesn't need to be radical different (IMO).
- Hook in backup & restore to intercept & support other formats (BB, IMS-CC...)
* Support restore of old (1.9 only?) backups.
- One code base both for manual and scheduled backup
* Hook in backup & restore to intercept & support other formats (BB, IMS-CC...)
- Scheduled restore?
* One code base both for manual and scheduled backup
- OOP.
* Scheduled restore?
- Secure.
* OOP.
* Secure (don't handle non-allowed data, user matching on restore, salted passwords..)
* Safe (some sort of "rollback" on failure - requires to have everything annotated somewhere - backup_ids or so).

Revision as of 23:07, 4 November 2008

Drop in ideas

  • Support incremental backups & restore.
  • Support 1-activity backup.
  • Support anonymisation of personal data on backup.
  • Separate process and progress.
  • XML format doesn't need to be radical different (IMO).
  • Support restore of old (1.9 only?) backups.
  • Hook in backup & restore to intercept & support other formats (BB, IMS-CC...)
  • One code base both for manual and scheduled backup
  • Scheduled restore?
  • OOP.
  • Secure (don't handle non-allowed data, user matching on restore, salted passwords..)
  • Safe (some sort of "rollback" on failure - requires to have everything annotated somewhere - backup_ids or so).