Технические вопросы

судя по тому, что ошибка при записи в mdl_question_attempts, активно используется тестирование. Тестирование - одно из самых требовательных по ресурсам процессов в moodle - задействовано много таблиц и постоянно что-то куда-то пишется. Поэтому предположу, что просто не хватает ресурсов железа. В первую очередь вопрос к скорости работы жесткого диска. Так как система под гипервизором, значит один физический диск делится на несколько виртуалок. Возможно на уровне виртуалке у вас настроено ограничение на количество iops к диску. Если это так, то обязательно снимите это ограничение.
Если гипервизор позволяет, посмотрите в логах на этот момент времени read и write latency, а также объем оперативки, занятый системой - ведь если оперативка кончается, в ход идёт swap, что ещё сильнее увеличивает нагрузку на диск, что в свою очередь ещё сильнее увеличивает latency. Тормоза в ответах сервера увеличивают количество обновлений страниц пользователями, что приводит к ещё большему числу одновременных запросов, ещё большему потреблению памяти и нагрузки на дб, swap и жесткий диск, в общем цепная реакция.
Поэтому нужно понять, какой из компонентов системы в вашем случае является "бутылочным горлышком".
На саму машину поставьте любое средство мониторинга, я пользуюсь munin, общее представление он позволяет получить, но кто-то возможно подскажет более удобные варианты вроде zabix. Вот примеры того, какие выводы можно сделать на основе мониторинга

Вот сравните, для примера графики. Видно, что профиль нагрузки на apache в целом соответствует профилю нагрузки на mysql и на процссор. iowait на графике, это ожидание системой ответа диска или сети. Сравните iowait- с графиком нагрузки на диск - профили почти совпадают. Сильный пик в районе 19-00 - большая проблема, так как может привезти к тому, что в этот момент система отвечает сильно дольше положенного. Пик связан с большой нагрузкой на диск в этот момент, но не из-за количества пользователей и запросов к БД. Скорее всего какая-то задача из cron потребляет много диска.
Проверяем. Действительно, в этот момент был какой-то особенно долгий запрос к БД и понижение скорости чтения диска

Опишите, каким образом пытаетесь восстанавливать базу данных. Проверьте, точно ли у вас в mysql используется innodb. innodb транзакционный движок, его очень трудно "уронить" до неработоспособного состояния при штатной работе. А вот при проблемах с железом это вполне возможно. Если есть возможность, проверьте память и жесткий диск хотя бы через smart. Если на диске bad-блоки, это будет проявляться в работе только той виртуалки, в чей vhd-файл попали сбойные блоки, поэтому отсутствие сбоев в других виртуалках это не доказательство работоспособности железа. Но в логах гипервизора такие проблемы вроде должны отражаться.