Это пост — очень сжатая версия моих событий за последние 24 часа. Хотя обновление ещё не прошло успешно, я надеюсь, что кто-нибудь укажет ниже, где именно возникла ошибка.
Мое обновление Discourse не прошло из-за дубликата ключа: один из тегов был продублирован. Чтобы исправить проблему с обновлением, мне потребовалась чистая установка Discourse и последующая загрузка последней резервной копии. Однако при загрузке возникла ошибка из-за того же дубликата ключа. Поэтому мне пришлось зайти внутрь резервной копии и изменить проблемный тег на что-то другое.
По какой-то причине перепакованная резервная копия с исправленным дубликатом тега оказалась значительно меньше исходной и не восстанавливалась — значит, при перепаковке что-то пошло не так.
1) Поиск резервных копий: Чтобы найти резервные копии Discourse, выполните следующую команду:
sudo find / -name "*.tar.gz"
Эта команда выполнит поиск всех файлов с расширением “.tar.gz” на вашей системе. По умолчанию они должны находиться внутри контейнера в каталоге: shared/backups/default
2) Создание копии: Когда вы нашли нужную резервную копию, создайте её копию, чтобы сохранить оригинал. Используйте команду “cp”:
bash
sudo cp /path/to/original_backup.tar.gz /path/to/copy_backup.tar.gz
3) Извлечение копии: Извлеките содержимое скопированного файла резервной копии с помощью команды “tar”:
bash
tar -xzvf /path/to/copy_backup.tar.gz
Это извлечёт файлы резервной копии во временный каталог.
4) Редактирование тегов в базе данных: Перейдите в извлечённые файлы резервной копии и откройте соответствующий файл базы данных с помощью текстового редактора. У меня возникла проблема с дубликатами тегов “socialmedia”, из-за чего восстановление не удавалось. В большой базе данных множество записей с тегами, и, скорее всего, несколько экземпляров именно того тега, который вы ищете. Поэтому я использовал поиск ‘immutable socialmedia’ через Ctrl+W в Nano, что сразу перенесло меня к нужному месту.
sudo nano /path/to/extracted_database.sql
Я изменил один экземпляр тега “socialmedia” на “socialmedia2”, затем быстро проверил, что теперь он встречается только один раз. Исправить остальные теги я смогу из админ-панели после успешного восстановления.
5) Перепаковка: После редактирования файлов резервной копии создайте новый файл с исправленным содержимым. Используйте следующую команду для сжатия изменённых файлов:
tar -czvf /path/to/new_modified_backup.tar.gz /path/to/modified_files_directory
6) Перемещение в правильный каталог: Переместите новый изменённый файл резервной копии в каталог, где хранятся резервные копии. По умолчанию это обычно “/shared/backups/default”:
sudo mv /path/to/new_modified_backup.tar.gz /shared/backups/default/
7) Остановка и запуск служб: Перед восстановлением изменённой резервной копии остановите соответствующие службы, чтобы избежать возможных конфликтов в процессе восстановления. Используйте команду “./launcher stop app” для остановки приложения Discourse:
./launcher stop app
8) Восстановление резервной копии: Чтобы восстановить данные из изменённой резервной копии, используйте команду “discourse restore” с указанием пути к новому файлу:
discourse restore /shared/backups/default/new_modified_backup.tar.gz
Или вы можете сделать это через /admin на вашем сайте, так как файл теперь должен отображаться в разделе резервных копий.
9) Проверка восстановления: После завершения процесса восстановления я проверил, что изменения были успешными, просмотрев приложение Discourse и базу данных, убедившись, что дубликаты тегов “socialmedia” удалены.
10) Запуск служб: Я перезапустил ранее остановленные службы, чтобы вернуть приложение Discourse в работу. Для этого использовал команду “./launcher start app”:
./launcher start app
11) Удаление временных файлов и лишних резервных копий: После успешного восстановления я удалил все временные файлы и дополнительные резервные копии, созданные в процессе, чтобы освободить место на диске. Используйте команду “rm” для удаления файлов:
sudo rm -r /path/to/temporary_directory
sudo rm /path/to/copy_backup.tar.gz
