Я пытаюсь выполнить восстановление на только что установленном экземпляре Discourse и получаю эту ошибку в CLI:
ERROR: could not extend file "base/16384/17011337": wrote only 4096 of 8192 bytes at block 15860
HINT: Check free disk space.
EXCEPTION: psql failed: HINT: Check free disk space.
Файл резервной копии, который я пытаюсь восстановить, имеет размер 22 ГБ (сжатый gz), и на сервере свободно 198 ГБ, поэтому мне кажется, что это точно не проблема с местом на диске. Есть ли какие-то идеи, почему здесь возникает такая жалоба?
У вас есть представление о размере в несжатом виде? Также это не учитывает индексы, поэтому, возможно, стоит попробовать на сервере с большим объемом диска?
Вы также можете проверить разделы вашего диска. Возможно, на сервере свободно 198 ГБ, но, как вы наверняка знаете, у сервера может быть несколько разделов диска. Может быть, ответьте с выводом команды df?
Я думаю, что база данных занимала около 40 ГБ в несжатом виде. Я сделал резервную копию форума после импорта из другого программного обеспечения для форумов, поэтому предполагал, что восстановление не составит труда. До этого у меня точно не было проблем с местом на диске. Я могу добавить немного больше места, но я просто думал, что не может быть необходимости в объёме, превышающем размер базы данных более чем в 3 раза.
Всё смонтировано в раздел /, поэтому я не думаю, что там есть какие-либо проблемы:
Попробовал оба способа, но последний раз через CLI. Я попробую увеличить дисковое пространство, а затем буду следить за его использованием в процессе импорта.
Я знаю, что у нас много контента. Но, похоже, требования к дисковому пространству резко возросли просто из-за выполнения резервного копирования и восстановления. До создания резервной копии у нас было свободно более 100 ГБ, поэтому я предполагал, что восстановление не вызовет проблем, однако для этой операции потребовалось значительно больше места, чем я ожидал. Похоже, места оказалось чуть-чуть недостаточно.
Я пытаюсь выполнить запрос для отображения 20 самых крупных объектов в базе данных, но он выполняется уже около часа, и я не знаю, сколько ещё потребуется времени до его завершения.
Проверьте, остались ли резервные копии и файлы восстановления схем. Если восстановление или резервное копирование завершаются катастрофически (например, из-за нехватки места), они могут оставаться в системе. У нас есть фоновая задача, которая очищает их еженедельно, но вы можете запустить её раньше.
Перейдите по адресу /sidekiq/scheduler, найдите Jobs::DropBackupSchema и нажмите «Запустить».
Если у вас есть полная резервная копия, то у вас будет 3 копии: полная резервная копия, дамп базы данных внутри неё и восстановленная база данных, плюс та база данных, которая была изначально.