Что вы хотите сделать?
Моя установка Discourse безупречно работала в течение 3 лет. Я выполнил ручное обновление Docker, и теперь всё сломано. Доступ к серверу возможен только в режиме восстановления. Docker не запускается. При запуске сервера с жёсткого диска (вместо режима восстановления) подключение по SSH невозможно.
Когда это нужно сделать?
Вернуть Discourse к работе!
У меня есть снимок системы двухмесячной давности, но я бы предпочёл не терять данные за последние два месяца. Также у меня есть снимок, сделанный сразу после сбоя Docker.
Несколько часов назад я нанял разработчика, но он не смог завершить проект, так как для него уже поздно, а мне нужно решение как можно скорее. Это производственный сайт.
Он сообщил:
были проведены все стандартные проверки, SSH работает, трафик не заблокирован, мы обновили конфигурацию SSH для использования аутентификации по паролю. Теперь необходимо изучить, какие шаги предпринимались до возникновения сбоя, и проанализировать соответствующие логи.
Каков ваш бюджет в долларах США, который вы готовы предложить за эту задачу?
Я оплачиваю задачу почасово по рыночной ставке. Просто сообщите вашу ставку.
Подключили сетевой диск (Digital Ocean Volume Block Storage)
Создали архив (tar-архив) папки /var/discourse
Выгрузили эти файлы на сетевой диск
Выключили старый сервер и отключили сетевой диск
Развернули новую организацию Discourse на новом сервере
Подключили сетевой диск
Распаковали файлы
Нашли резервную копию из 7-дневного цикла резервного копирования
Восстановились до этой точки
Мы пытались просто перенести папку /var/discourse целиком на новый сервер, но столкнулись с проблемами Redis (не уверен, что это были основные проблемы, но именно они были отмечены).
Просто из любопытства. В последнее время несколько сообщений о сбоях при обновлении связаны с Docker и DigitalOcean. Это просто совпадение или есть общая причина, с которой столкнутся другие администраторы Discourse на DigitalOcean при обновлении? Я спрашиваю, потому что я один из них.
@waffleslop@jericson отличная работа, спасибо за информацию о том, как вы это исправили — для самохостера всегда полезно иметь такой ресурс на случай, если вдруг возникнут проблемы!
@icaria36 Я использую Digital Ocean для большинства своих инстансов и совсем недавно обновил как операционную систему, так и код Discourse — всё прошло без каких-либо проблем. (Надеюсь, что этот пост меня не сглазит!)
Могу подтвердить, что все обновления проходили легко до вчерашнего дня. Я обновил Docker через графический интерфейс, и всё сработало. Затем я перешёл к обновлению следующих трёх элементов и нажал на один из них (не помню, на какой именно) первым. Ничего не произошло. Я подождал несколько секунд и нажал на другой… затем на третий. Возможно, я действовал слишком быстро и что-то заблокировал? В итоге я зашёл в консоль и увидел сообщение о том, что рекомендуется перезагрузка, поэтому я перезагрузил машину. После этого она так и не вернулась в полностью рабочее состояние.
Возможно, я перезагрузил систему во время обновления, что, пока я это пишу, кажется довольно глупым!
Мы не тратили время на выяснение причин проблемы, так как хотели как можно быстрее запустить @waffleslop. Я обновлял свои серверы Discourse (размещённые на DigitalOcean) без проблем. Однако я использую командную строку, а не графический интерфейс, так как у меня установлена нестандартная конфигурация.
Я могу порекомендовать несколько шагов для минимизации риска длительных простоев:
Сделайте резервную копию перед любыми действиями! Интересно, не стоит ли добавить в интерфейс предупреждение с настоятельной рекомендацией создать резервную копию перед обновлением. Наличие недавней резервной копии даёт мне уверенность, что в худшем случае мы сможем запустить новый Droplet и восстановить данные.
Убедитесь, что у вас есть доступ к резервной копии!@waffleslop и я потратили значительную часть времени на то, чтобы понять, как скопировать /var/discourse на новый Droplet. С исходным Droplet происходило что-то очень странное, и мы не могли просто scp файлы на новый Droplet. Для своих серверов я храню резервные копии на S3 и ежедневно копирую их на локальную машину. Это чрезмерно? Возможно. Но это даёт мне множество вариантов действий, если что-то пойдёт не так.
Регулярно проверяйте свои резервные копии. Когда ваши производственные серверы недоступны, вы должны быть уверены в своих действиях. В идеале стоит протестировать резервную копию непосредственно перед обновлением, чтобы иметь точку возврата на случай сбоя. Однако обычно достаточно периодически пробовать восстановление, чтобы процесс оставался свежим в памяти.
Две головы лучше, чем одна. Возможно, это эгоизм, но справиться с чрезвычайной ситуацией гораздо легче, если вы сможете поделиться экраном на звонке с кем-то, у кого есть опыт решения подобных проблем. В идеале вам нужен кто-то, кто умеет работать в командной строке.
Если вы сделаете резервную копию, обновление должно пройти безопасно.
