Backup and restore
can you do that again with Debugging switched on so we can see where it's going wrong. My immediate guess is that this might be caused by an optional plugin which doesn't implement restor properly. Is that possible?
Were you able to solve this issue? We are having the same problem using a 2.1 backup into 2.2.2. From some testing I think it may be due to the Restoring of Course logs, When all fields are ticked to restore (and were backed up) it fails but when I only untick the restore course logs checkbox the restore works. I'll include the error and stack trace from debugging below.
Thanks again if anyone can help.
Coding error detected, it must be fixed by a programmer: define_restore_log_rules() method needs to be overridden in each subclass of restore_activity_task
line 250 of /backup/moodle2/restore_activity_task.class.php: coding_exception thrown
line ? of unknownfile: call to restore_activity_task->define_restore_log_rules()
line 50 of /backup/util/helper/restore_logs_processor.class.php: call to call_user_func()
line 73 of /backup/util/helper/restore_logs_processor.class.php: call to restore_logs_processor->__construct()
line 1934 of /backup/moodle2/restore_stepslib.php: call to restore_logs_processor::get_instance()
line 131 of /backup/util/plan/restore_structure_step.class.php: call to restore_activity_logs_structure_step->process_log()
line 103 of /backup/util/helper/restore_structure_parser_processor.class.php: call to restore_structure_step->process()
line 125 of /backup/util/xml/parser/processors/grouped_parser_processor.class.php: call to restore_structure_parser_processor->dispatch_chunk()
line 91 of /backup/util/helper/restore_structure_parser_processor.class.php: call to grouped_parser_processor->postprocess_chunk()
line 148 of /backup/util/xml/parser/processors/simplified_parser_processor.class.php: call to restore_structure_parser_processor->postprocess_chunk()
line 92 of /backup/util/xml/parser/processors/progressive_parser_processor.class.php: call to simplified_parser_processor->process_chunk()
line 169 of /backup/util/xml/parser/progressive_parser.class.php: call to progressive_parser_processor->receive_chunk()
line 253 of /backup/util/xml/parser/progressive_parser.class.php: call to progressive_parser->publish()
line ? of unknownfile: call to progressive_parser->end_tag()
line 158 of /backup/util/xml/parser/progressive_parser.class.php: call to xml_parse()
line 137 of /backup/util/xml/parser/progressive_parser.class.php: call to progressive_parser->parse()
line 105 of /backup/util/plan/restore_structure_step.class.php: call to progressive_parser->process()
line 153 of /backup/util/plan/base_task.class.php: call to restore_structure_step->execute()
line 182 of /backup/moodle2/restore_activity_task.class.php: call to base_task->execute()
line 148 of /backup/util/plan/base_plan.class.php: call to restore_activity_task->execute()
line 157 of /backup/util/plan/restore_plan.class.php: call to base_plan->execute()
line 310 of /backup/controller/restore_controller.class.php: call to restore_plan->execute()
line 147 of /backup/util/ui/restore_ui.class.php: call to restore_controller->execute_plan()
line 46 of /backup/restore.php: call to restore_ui->execute()
We've just come across this error in 2.3+. It's preventing courses from restoring and I dread to think what data it's leaving orphaned in the database. Will see what's happening on the Tracker.
I've been keeping this Tracker entry as up-to-date as possible with my experiences. When filed, we couldn't restore 2.2 backups into 2.3, which we got around by creating backups without user data, which then worked fine. Now, we can't restore 2.3 backups into 2.4 for the same reason (and with the same solution) with the added 'bonus' of receiving 500 internal server errors instead of the error mentioned on the Tracker post.
I can't in good conscience make the issue a blocker, as Moodle functions fine day-to-day, but the fact that we can only restore course backups without user data is a concern (the main reason we create these backups is for disaster recovery reasons).
I encourage anyone experiencing this to vote and comment on the issue on the tracker, as without raising it's awareness it will not be seen and won't be addressed.