Uploaded image for project: 'Moodle'
  1. Moodle
  2. MDL-25571

Improvements to 2.0 backups



    • Improvement
    • Status: Closed
    • Major
    • Resolution: Duplicate
    • 2.0, 2.5.1
    • None
    • Backup


      I would like to propose a couple of enhancements to the Moodle 2.0 backups system which NetSpot will develop. I would like to get endorsement from HQ for this to get into core if the changes seem sensible. Feedback much appreciated:

      Enhancement #1) Add an option to perform a backup without file pool content. The backup file would be exactly the same in terms of having a complete files.xml with references to all files etc, but with no actual content files stored in the backup archive. This option could be configurable for scheduled backups. When restoring one of these fileless backups, if all files are contained within the pool, or can be recovered from trash, the restore will be successful. If the restored backup is referencing a contenthash that does not exist in the pool or trash, then an error can be thrown. (optionally, the restore could succeed anyway but provide a list of contenthashes to the administrator which need to be recovered from elsewhere, eg. tape)

      Advantage: It becomes far more feasable to retain course backups for a long period of time since they will usually be less than 100KB each. It will save storage by not duplicating content into many course backups + the file pool itself.

      Enhancement #2) Change the purging of file pool trash to be based on "deleted age" and to have a configurable age threshold. We would like to be able to set this to 6 months. This would use the file's ctime to determine how long ago the file was deleted. This is in contrast to the current system which does a daily purge no matter how recently the file was deleted.

      Through the combination of features 1 and 2, we could ensure that daily backup files from the last 6 months can be restored with all content available, but without having to store an enormous amount of content that would normally exist within each zip file.

      I'm looking to develop this within the next 4 to 6 weeks, so would be good to get some approval if this is suitable for core. If it's not wanted in core, we will develop it anyway and maintain it ourselves, but ideally we can contribute it back.



        Issue Links



              0 Vote for this issue
              6 Start watching this issue