The restore progress bars introduced a bug when restoring Moodle 1.9 backups.
build_plan needs to be surrounded with start_progress/end_progress with the mode
set to indeterminite or it throws coding errors.
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
If a backup contains a large number of questions, the
create_question_files function can take a very long time. This
change adds progress reporting during that function.
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.
In the case of a very large backup with many activities, simply loading
the restore controller (specifically, building the plan) can take a long
time and cause timeouts. This change adds progress reporting while the
restore controller is being loaded.
(This also reduces the time between first going to the page, and the
progress bar appearing, making a slightly better user experience.)
Conflicts:
backup/restore.php
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).
This parallels question_attempt->minfraction, which allows the
fractional mark to go below zere.
This is needed to allow the certainty-base marking behaviours to work
better.
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.
