Небольшое обновление. На прошлой неделе над этим работал кто-то другой из моей команды, но решение так и не нашлось, поэтому я попробовал ещё раз, на этот раз отредактировав базу данных на своей локальной системе.
Что я сделал:
- Загрузил старую резервную копию, которую хочу восстановить.
- Распаковал файлы с помощью 7-Zip.
- Открыл dump.sql в Visual Studio Code.
- Нашёл дублирующиеся теги непосредственно в базе данных.
- Нашёл, по-видимому, список тегов, выполнив поиск с использованием кавычек вокруг тега. В моём случае это ‘socialmedia’. Теги выглядят как второй и третий снизу среди найденных вхождений.
- Изменил одно из вхождений на:
132 ‘socialmedia2’:1A socialmedia2 en_GB 3
- Снова упаковал файл dump.sql с помощью 7-Zip:
- Добавить в архив
- Формат архива: .gzip
- Снова упаковал основной файл резервной копии:
- Добавить в архив
- Формат архива: .tar (gzip пока недоступен)
-
Теперь у вас должен появиться заархивированный исправленный файл резервной копии .tar
-
Упакуйте файл .tar с помощью 7-Zip, чтобы создать файл .tar.gz, соответствующий формату, используемому в Discourse:
- Добавить в архив
- Формат архива: .gzip
- Загрузите файл в раздел резервных копий и восстановите его через административную панель.
На этом этапе я столкнулся с сообщением об ошибке:
Извлечение файла дампа…
[2023-08-08 15:09:15] EXCEPTION: No such file or directory @ rb_check_realpath_internal - /var/www/discourse/tmp/restores/default/2023-08-08-150913/dump.sql.gz
Есть ли у кого-нибудь идеи, что я упустил в описанном выше процессе?
Единственное, что приходит мне в голову, — это то, что путь, который система ищет, использует сегодняшнюю дату, а не дату резервной копии (я пишу это 08-08-2023).