This commit contains three changes in the three files:
1. A bug in the backup process meant that anything logged after a
certain point did not appear in the on-screen display of the
backup log, because the logger was serialised and deserialised
but display code referred to the old version. Changed so that
code retrieves new object.
2. Add more information to backup log when there is a missing file.
3. Add more information to restore log when there is a missing file
(and remove existing code duplication of the current message).
The 'missing file' situation is one that generally shouldn't occur in
normal usage, but when it does happen, it is useful to have full
information about the file.
Files bigger than 4GB is not supported at this point. Zip archiver doesn't know about it and always returns true. We need to verify if it is a valid file or not and delete if not
Also delete the backup file immediately if anything goes wrong anywhere in backup. We don't want to use up space
When restoring a backup that contains a large number of users
to a different server where those users don't already exist,
creating users can take a significant time. This change adds
progress reporting so that it doesn't time out and shows
activity in the user interface while doing the creation.
Change the start of restore process so that the archive file can
be passed as a pathnamehash pointing to the Moodle file object,
rather than only as a filename in the temporary directory. This
avoids making an unnecessary copy of the archive file, which can
take a long time (and potentially cause a timeout) in the case
of multi-gigabyte backups.
Deleting directories at the end of backup can take a long time if
there are many directories (potentially up to 65536 file
directories). This change reports progress while deleting
directories to avoid timeout.
This change relates to the Moodle forms used to select activities
in the restore process.
If you add too many form fields at once, it takes a very long time
during which we can't report progress. But adding fields in smaller
groups takes longer overall, so it's a tough balance. This change
splits the adds into groups of 1,000, reporting progress between each.
The new experimental setting enabletgzbackups allows backups to be
created so that the internal format for .mbz files is .tar.gz.
Restore transparently supports .mbz files with either internal
formats (.zip or .tar.gz).
The .tar.gz format has the following benefits for backup:
- Supports larger files (no limit on total size, 8GB on single file
vs. 4GB limit on total size)
- Compresses text better, resulting in smaller .mbz files.
- Reports progress regularly during compression of single files,
reducing the chance of timeouts during backups that include a
very large file.
Time performance may also be improved although I haven't done a
direct comparison.
When doing a backup or restore operation with the normal user interface,
if there is anything in the backup/restore log, it will now be displayed
at the end of the process below the Continue button.
If you have developer debugging enabled, it sets the display level to
LOG_DEBUG and there will always be content in the log. Otherwise, it
uses LOG_INFO which generally means the log is empty, and nothing
displays (no visible change for users).
Adds 'Preparing page display' progress bars for user interface pages
if they take a long time to display.
Also adds changes where other parts of the backup progress timed out on
long backups. After this change, and MDL-41838, it is finally possible on
my dev server to successfully back up the 'XL' test course.
Sam Hemelryk