Всем привет — в процессе миграции с хостинга Discourse на собственный хостинг. Провели несколько успешных тестовых запусков различных операций, но при попытке выполнить реальную миграцию со всеми загрузками, после нескольких часов распаковки архива появляется сообщение об отсутствии файла или директории при попытке извлечь файл дампа. Теперь возникает риск потери около 140 ГБ загрузок, если у кого-то нет идей, как это исправить?
Можете предоставить лог?
Вы восстанавливаете из командной строки или через веб-интерфейс? Рекомендую использовать веб-интерфейс.
Привет — я прикрепил лог к предыдущему письму, но дублирую его здесь. Сначала я попробовал через веб-интерфейс, а затем через командную строку. У меня есть подозрение, что резервная копия каким-то образом повреждена: она не распознаётся при загрузке в S3 и почти мгновенно отклоняется, если пытаться загрузить её через браузер.
restore-failure-log.txt (3.28 КБ)
Похоже, что так и есть. Вы загружали через веб-браузер или scp/rsync? Я бы загрузил снова с помощью rsync.
Привет, Джей. Извини, я немного запутался ранее, так как мы также вели переписку с командой Discourse по электронной почте на протяжении всего процесса миграции, и именно там я прикрепил файл журнала.
Изучив ошибку, я подозреваю, что в архиве на самом деле нет дампа SQL, только изображения. Файл был инициирован и проверен от нашего имени командой Discourse. Я загрузил его через HTTP и передал на сервер через SCP, так как загрузка через браузер была отклонена.
Да, я только что выполнил команду для проверки содержимого архива, и там действительно только изображения, без дампа SQL.
Можете ли вы проверить, совпадают ли размеры tar-архива точно:
- на экземпляре CDCK
- у скачанного файла
- у файла, который вы загрузили через scp
Рекомендуется выполнить команду tar tfvz, чтобы убедиться, что архив не обрезан.
Также стоит проверить, не заканчивается ли где-то место на диске, так как для операции требуется пространство, кратное размеру архива.
Хорошо, я ненадолго отлучусь, но позже проверю. С местом проблем быть не должно, у меня 512 ГБ, а файл резервной копии занимает 70 ГБ. Меня удивило, что этот файл на несколько гигабайт меньше предыдущего, который мы создавали, я ожидал, что он будет немного больше. Почти уверен, что по какой-то причине в него не включен SQL-дамп, что как раз и объясняет разницу в размере.
Привет @pfaffman @RGJ, просто обновлю вас о ходе событий. SQL-дамп действительно отсутствовал в загруженном архиве, и я не был уверен, сработает ли отдельное резервное копирование базы данных и её добавление в архив (к тому же на тестирование ушло бы несколько часов). В итоге мы просто восстановили базу данных и успешно выполнили миграцию.
Теперь проблема в том, что как только Discourse отключит всё и остановит бакет S3 / CDN, все наши исторические изображения перестанут работать.
У меня есть все изображения, и я думаю, что смогу просто загрузить их все в наш бакет S3, сохранив ту же структуру папок. Видел несколько тем, обсуждающих возможность использования discourse.remap / dbhelper.remap для массового обновления ссылок на уровне базы данных. Буду очень признателен за любые мысли по этому поводу!
Не могу представить, как такое могло произойти. Неужели ваш браузер каким-то образом распаковал архив и разархивировал резервную копию, а затем вы попытались собрать всё обратно?
Вы можете попросить сотрудников discourse.org предоставить вам резервную копию, включающую загруженные файлы. Это именно то, что вам нужно. Они активируют параметр include_s3_uploads_in_backup (это близко к названию скрытой настройки, но почти наверняка не точное её имя).
Также можно попробовать использовать инструменты S3, чтобы загрузить все файлы из их бакета и снова загрузить их в свой. Есть несколько тем на эту тему. Я не рекомендую этот способ.
Недавно я мигрировал резервную копию объёмом около 100 ГБ с CDCK на Digital Ocean (droplet, бакет Spaces и CDN bunny.net) за 1000 долларов. Я сожалею об этом.
Это только база данных?
О, неужели вы каким-то образом восстановили только базу данных, хотя изображения есть в tar-архиве?
Вам нужно восстановить именно тот файл, который они создали, и дать Discourse восстановить его. Тот, который содержит как базу данных, так и загруженные файлы. Или вы можете изучить код восстановления и попытаться вручную выполнить действия, которые он выполняет для перенастройки изображений на новое местоположение. Хотя, по-моему, у Ричарда есть навыки и инструменты для этого, я не думаю, что вам стоит делать это таким способом.
Несколько месяцев назад мы провели тестовый запуск, и всё прошло хорошо. Думаю, они оставили эту скрытую настройку включённой, так как на этот раз мне удалось запустить резервное копирование с загрузками через бэкенд, хотя примерно через 12 часов пришло уведомление о сбое. Затем я связался с поддержкой Discourse, и они сказали, что создадут резервную копию со своей стороны. Через пару часов созданная мной резервная копия, похоже, завершилась, но мы удалили файл, как и рекомендовала поддержка Discourse. После этого у них возникло множество проблем: резервные копии завершались по тайм-ауту и возвращали ошибки, пока в итоге они не сообщили, что файл полностью готов. Однако при попытке восстановить этот файл, после нескольких часов извлечения архива система сообщила об отсутствии дампа. Проверка файла с помощью команды tar -tf подтвердила, что дампа там нет (в других полных резервных копиях он обычно является первым файлом в архиве). Так как было воскресенье, я не мог связаться с поддержкой Discourse, а мы обещали завершить миграцию к утру понедельника, поэтому я сделал резервную копию только базы данных (около 7 ГБ) и использовал её для миграции.
Команда Discourse пытается помочь, но сейчас они могут сделать лишь ограниченное количество действий, так как мы уже завершили миграцию и с воскресного вечера работаем в собственной хостинговой среде. Самый простой вариант — чтобы они оставили наш бакет S3 и CDN активными (за плату), но они заявили, что это невозможно. Честно говоря, думаю, нам придётся просто потерять исторические изображения.
Это можно исправить. Просто загрузите содержимое корзины S3 в локальную директорию загрузок, а затем выполните remap в вашей базе данных, переписав URL CDN и корзины на URL вашего экземпляра.
Несколько проблем: размер загружаемых изображений может исчерпать место на SSD нашего нового VPS, а у нас нет возможности подключить дополнительный диск. Возможно, стоит взять только подмножество данных, хотя не совсем понятно, как это реализовать, глядя на структуру каталогов. Кроме того, мы уже настроили сайт для использования S3 для загрузки файлов вместо локального хранилища.
Хорошо, тогда скопируйте их S3 (или резервную копию из S3) в ваш S3 и перенастройте маппинг?
Да, я надеюсь, что это возможно!
А, понятно. Да, как только вы запустили процесс, вы уже связаны обязательствами. Всё ещё вполне возможно переместить файлы в S3 до их удаления.
Вам всегда требовалось достаточно места для хранения всех изображений, чтобы выполнить восстановление. Вы могли копировать изображения по одному. Также, насколько я знаю, существуют инструменты, которые позволяют копировать файлы напрямую.
Да, изначально планировалось использовать временную виртуальную машину Azure для восстановления с присоединённым большим диском, затем выгрузить данные обратно в S3, создать ещё одну резервную копию после завершения и, наконец, перенести их на наш VPS (пытаемся сократить расходы).
У меня есть tar.gz-архив со всеми загруженными файлами, и я могу загрузить их напрямую в наш бакет S3, сохраняя структуру каталогов (думаю, стандартный загрузчик AWS сейчас это умеет, иначе есть CLI). Возможно, стоит учесть вопросы владения и прав доступа, хотя, может, и не стоит.
После этого будет этап переназначения (remap) — не уверен в разнице между discourse.remap и dbhelper.remap. Сначала я бы протестировал всё это на тестовой установке с парой файлов.