Как сделать резервную копию и восстановить всю папку приложения /var/discourse?

Как сделать резервную копию и восстановить всю папку /var/discourse?

Из-за проблем с обычным процессом резервного копирования и восстановления я задумался: можно ли сделать резервную копию всей папки /var/discourse и использовать её на другом сервере. Вот что я сделал…

На производственном сервере:

rsync_opts="\
   --recursive \
   --links \
   --hard-links \
   --safe-links \
   --owner \
   --group \
   --perms \
   --times \
   --delete \
   --sparse \
   --compress \
   --partial \
   --rsh=ssh
"
dir=/var/discourse
rsync  $rsync_opts "$dir/" root@xx.xx.xx.xx:"/var/production-backup/$dir"

На тестовом сервере:

Установите Docker.

rsync --recursive --links --hard-links --safe-links --owner --group --perms --times --delete --sparse --compress --partial /var/production-backup/var/discourse/ /var/discourse

Но получаю ошибку 502 Bad Gateway.

Пытаюсь разобраться.

cd /var/discourse

./launcher start app

root@whonix-app:/var/www/discourse# service postgresql status
12/main (port 5432): down
root@whonix-app:/var/www/discourse# service postgresql start
[....] Starting PostgreSQL 12 database server: main[....] Error: The cluster is owned [FAILoup id 116 which does not exist ... failed!
 failed!

Предполагаемые исправления:

chown -R postgres.postgres /etc/postgresql
chown -R postgres.postgres /shared/postgres_*
chown -R postgres.postgres /var/lib/postgresql
chown -R postgres.postgres /var/log/postgresql
chown -R redis.redis /etc/redis/redis.conf
chown -R redis.redis /shared/redis_data
chown -R redis.redis /var/run/redis
chown -R redis.redis /var/lib/redis
chown -R redis.redis /var/log/redis
chgrp -R ssl-cert /etc/ssl/private

Но это не помогло.

root@whonix-app:/var/www/discourse# service postgresql start
[....] Starting PostgreSQL 12 database server: main[....] Error: /usr/lib/postgresql/12/bin/pg_ctl /usr/lib/postgresql/12/bin/pg_ctl start -D /shared/postgres_data -l /var/log/postgresql/postgresql-12-main.log -s -o -c config_file="/etc/postgresql/12/main/postgresql.conf" exited with status 1: 2020-05-25 10:20:10.501 UTC [603] FATAL: database files are incompatible with server 2020-05-25 10:20:10.501 UTC [603] DETAIL: The data directory was initialized by PostgreSQL version 10, which is not compatible with this version 12.2 (Debian 12.2-2.pgdg100+1). pg_ctl: could not start server Examine the lo[FAILput. ... failed!
 failed!

Почему возникают проблемы с правами доступа к файлам?

Почему PostgreSQL обновляется с версии 10 до версии 12 просто при копировании всей папки с одного сервера на другой? Я, должно быть, что-то делаю не так.

Не могли бы вы, пожалуйста, поделиться инструкциями о том, как сделать резервную копию всего приложения Discourse на одном сервере и перенести его на другой сервер?

Discourse не использует Phabricator?

Опечатка. Я имел в виду Discourse. Опечатка исправлена. Исходный вопрос остаётся в силе.

Это не перемещает всю папку /var/discourse. Я знаком с этими инструкциями, но они не работают для меня. Поэтому я хотел более «полный» способ резервного копирования «один к одному» — «жесткую копию».

Вы можете остановить контейнер и скопировать его целиком на новый сервер, исключив директории tmp, backup и cache (и, кажется, ещё одну?). Это должно сработать. Я недавно делал что-то подобное, думаю, по той же причине.

Но вам всё равно нужно решить проблему с повреждённым индексом.

Я думаю, что различия вносят версии Docker. (Что в итоге приводит к сбоям.)

Оригинальный сервер:
docker-engine 17.05.0~ce-0~debian-stretch

vs более новый (тестовый) сервер:
docker-engine 17.05.0~ce-0~debian-stretch

Из-за этого на оригинальном сервере версия postgres 10, а на более новом (тестовом) уже postgres 12.

Это обязательно? Есть ли более простой способ? Почему требуется не копировать всё как есть и не восстанавливать?

Это приводит к проблемам с правами доступа, которые я не могу объяснить. Должно быть возможно скопировать без нарушения прав доступа. И я также не уверен, что полностью исправил все проблемы с правами.

Да, но я думаю, что гораздо безопаснее приступать к этому только после того, как я смогу хотя бы воспроизвести то, что сейчас ещё работает.

Вы не можете просто «упаковать» директорию /var/discourse с помощью tar, переместить её на другой сервер, распаковать и запустить приложение Discourse.

Одна из основных причин заключается в том, что при сборке / инициализации Discourse (загрузчик, если я не ошибаюсь) проверяет наличие базового контейнера Discourse (образа), загружает базовый Docker-образ Discourse (если его нет) и запускает этот базовый образ в контейнере.

После этого обновления из git процесс сборки создаёт ещё один Docker-образ (образ приложения).

Оба этих Docker-образа (базовый образ и образ приложения) не находятся внутри /var/discourse, поэтому упаковка /var/discourse через tar является лишь частичным «решением» (используя этот термин условно).

Эти образы Docker для Discourse создаются как образы Docker и являются частью экосистемы Docker; они не «живут» в /var/discourse, а создаются там, а затем перемещаются в Docker как образы.

Возможно, отредактировать файл конфигурации контейнера (YAML) и собрать всё заново с нуля, но более стандартный способ — сохранить:

  • файл(ы) конфигурации контейнера (YAML)
  • полную резервную копию с загрузками

затем отредактировать файл конфигурации контейнера, клонировать репозиторий discourse-docker и выполнить сборку заново.

После этого восстановить полную резервную копию, включая загрузку файлов (через командную строку внутри контейнера).

Использование GitHub в качестве репозитория — более чистое решение, чем старый «unix-подобный» способ «упаковки всего этого дела» и «перемещения всего этого дела» на другой сервер. Однако даже при использовании «старого unix-метода» этот подход часто не обеспечивает полного решения, поскольку в системе часто есть общие библиотеки в пользовательских директориях и многое другое, что не входит в дистрибутивный каталог, а также файлы в /etc, которые не находятся в корневом каталоге дистрибутива и т.д.

Поэтому даже в большинстве современных систем Linux мы используем apt (например, в Ubuntu) для получения репозитория. В случае с Docker для Discourse вы загружаете (и собираете) репозиторий discourse-docker для настройки базового контейнера и другой репозиторий Discourse для сборки приложения. Таким образом, /var/discourse является «местом для сборки» (образов) и «местом для хранения» (данных, резервных копий, публичных статических файлов и т.д.).

Надеюсь, это краткое изложение было хоть немного полезным.

Конечно, вы можете скопировать всё с помощью rsync -rav.

У вас может получиться лучше, если вы измените своё приложение так, чтобы оно использовало шаблон PostgreSQL 10. Но, судя по всему, самое простое решение — исправить базу данных на месте.

Вы можете переместить папку, это работает нормально. Просто это не рекомендуемый путь, так как он обходит discourse-setup и любые настройки/тесты, которые он выполняет по ходу дела.

В моём случае это не сработало, поскольку обновлённый Docker привёл к более новой версии PostgreSQL внутри контейнера Docker, что, в свою очередь, сделало форум нерабочим из-за проблем с миграцией PostgreSQL. Пришлось переключиться на шаблон PostgreSQL 10.

How to backup and restore a whole /var/discourse app folder? - #8 by neounix хорошо объясняет детали.

Думаю, мне пришлось бы также сделать резервную копию и восстановить папку /var/docker. Но даже это может не сработать из-за следующего:

Вы спускаетесь в кроличью нору.
На вашем месте я бы сосредоточился на решении вашей первоначальной проблемы с резервным копированием и восстановлением.

Возможно, даже в нору :rat: :rat: :rat:.

Согласен… безусловно…

@adrelanos

С процессом резервного копирования и восстановления нет никаких «проблем». Посмотрите это «восхищение», которое ваш покорный слуга @neounix написал несколько месяцев назад по этой теме:

Уважаемый @adrelanos,

Возвращаясь к вашему первоначальному вопросу в посте #1 выше: будучи по натуре любопытным, я не был полностью удовлетворён своим предыдущим ответом и сегодня провёл несколько тестов.

Короче говоря, я подтвердил, что можно использовать команду docker save (для базового и основного контейнеров) и tar для директории /var/discourse, чтобы полностью сохранить, перенести (создать резервную копию) и восстановить приложение таким образом.

Я почти уверен (на 99,99%), что этот метод не официально поддерживается, но вы заслуживаете ответа, поэтому я протестировал это для вас:

Вот шаги, вкратце:

  1. Сохраните ваши контейнеры с помощью docker save.

Например, если вы запускаете автономное приложение, вы можете сохранить базовый и основной контейнеры, как показано ниже (в зависимости от вашей конфигурации):

docker save -o /tmp/my.discourse.docker.app.tar  discourse/base:2.0.20200512-1735

а также:

docker save -o /tmp/my.discourse.docker.app.tar local_discourse/app:latest  
  1. Вы также можете создать tar-архив директории /var/discourse, как вы упоминали:
cd /var/
tar -cvzf /tmp/my.var.discourse.tar.gz discourse

а затем, если хотите, сжать ваши tar-файлы Docker с помощью gzip и создать архив:

gzip /tmp/my.discourse.docker*.tar
  1. … и вы можете переместить эти файлы на другой сервер, сохранить их на том же сервере, что угодно, выполнить шаги в обратном порядке и запустить приложение Discourse без проблем.

Я просто подтвердил это, “сделав это”, удалив все образы контейнеров и директорию /var/discourse. По сути, я стер всё и перезапустил систему (нет необходимости пересобирать, так как домен не изменился и т.д.) из резервных копий.

Например, для восстановления вы можете взять сохранённые образы Docker выше и загрузить их, например:

gzip -d /tmp/my.discourse.docker.app.tar.gz
docker load -i /tmp/my.discourse.docker.app.tar

gzip -d /tmp/my.discourse.docker.base.tar.gz
docker load -i /tmp/my.discourse.docker.base.tar
  1. Затем распакуйте исходную директорию /var/discourse:
cd /var
tar -xvzf /tmp/my.var.discourse.tar.gz
  1. Далее вам нужно проверить ваши образы, чтобы убедиться, что они правильно помечены:
docker images
  1. Если образы не помечены правильно, убедитесь, что вы присвоили им правильные теги, например, для вашего основного образа:
docker tag 58ffc74989af local_discourse/app:latest
  1. Затем просто выполните следующее:
cd /var/discourse
./launcher start app

и всё будет работать отлично. Я только что протестировал это (дважды).

Надеюсь, это поможет.

К сведению: я попробовал этот метод двумя разными способами, выполнив описанную выше процедуру резервного копирования, удалив все контейнеры Docker, образы и директорию /var/discourse (полностью уничтожив всё каждый раз).

В каждом случае я мог загрузить сохранённые образы Docker, распаковать директорию /var/discourse, запустить ./launcher start app, и Discourse запустился безупречно. Чтобы это доказать, я смог выполнить обычное резервное копирование через интерфейс, подтвердив, что всё в порядке.

Не уверен, отвечает ли это на ваш вопрос (и я не участвовал в обсуждениях или обновлениях с Postgres 10 до 12); но относительно вашего вопроса о том, можно ли просто создать tar-архив приложения как резервную копию и восстановить его, ответ — да, но вы должны не только архивировать директорию /var/discourse, но также использовать docker save для ваших образов.

Главная “подводная камень” — сохранить правильное имя репозитория образов и теги, и тогда всё будет работать.

Надеюсь, это хоть немного ответит на ваш вопрос:

Как сделать резервную копию и восстановить всю папку приложения /var/discourse?

Ответ: вы должны архивировать как вашу папку, так и образы Docker (как в примере выше), используя docker save для образов (для резервного копирования) и docker load для восстановления.

Имейте в виду, что этот метод не официально поддерживается; но из любопытства я хотел понять, как это сделать с точки зрения системного администратора, и обнаружил, что это проще, чем я указывал в своих предыдущих ответах.

Примечание 1:

Возможно, вам стоит переместить все резервные копии из вашей директории backups/default (вне структуры каталогов) перед тем, как создавать tar-архив всего в /var/discourse/ и хранить эти резервные копии (отдельно), поскольку эти файлы очень большие…

Примечание 2:

Такой тип резервного копирования не поддерживается и поэтому не рекомендуется для большинства системных администраторов Discourse. Я рекомендую пользователям следовать рекомендованному (и официально поддерживаемому) методу резервного копирования и восстановления Discourse.

Оставайтесь любопытными!

Берегите себя.


Для получения более подробной информации, включая скриншоты, пожалуйста, ознакомьтесь с моим полным постом здесь:

Это отличный подход! Спасибо!

Одна проблема на сервере восстановления.

./launcher logs app

2020-06-18 13:33:56.434 UTC [127] FATAL: data directory “/shared/postgres_data” has wrong ownership
2020-06-18 13:33:56.434 UTC [127] HINT: The server must be started by the user that owns the data directory.
./run: 3: echo: echo: I/O error
2020-06-18 13:33:57.448 GMT [128] LOG: skipping missing configuration file “/shared/postgres_data/postgresql.auto.conf”


Возможно, это связано с отсутствием некоторых опций tar? Я добавил -p и -s при извлечении, но это не помогло.

Исходный сервер (вне Docker):

ls -la /var/discourse/shared/standalone/postgres_data/

drwx------ 7 messagebus messagebus 4096 May 25 13:16 base

Исходный сервер (внутри Docker (./launcher enter app)):

ls -la /var/lib/postgresql/10/main/

drwx------ 5 root postgres 4096 May 25 23:28 base


Сервер восстановления вне Docker:

ls -la /var/discourse/shared/standalone/postgres_data/

drwx------ 7 messagebus messagebus 71 May 25 11:16 base

Сервер восстановления внутри Docker:

drwx------ 5 root postgres 41 May 25 23:28 base


./launcher rebuild app исправит это, но это не по теме.

Есть какие-то идеи?

Кажется, вы имели в виду docker save -o /tmp/my.discourse.docker.base.tar discourse/base:2.0.20200512-1735, исходя из вашего процесса восстановления. В любом случае, отличное объяснение!

Но, как вы и сказали, я не думаю, что это официально поддерживаемый подход (хотя также не считаю, что что-то ещё может вызвать ошибки, если только команда Discourse не начнёт использовать более одного базового образа в процессе пересборки).

Похоже, что та же проблема описана здесь:

https://meta.discourse.org/t/postgresql-12-update/151236/298?u=lucasbasquerotto

В разделе FAQ пока нет ответа на этот конкретный вопрос, но, возможно, команда Discourse добавит решение, учитывая, что с этой проблемой столкнулись уже более одного человека. В FAQ есть статья о некорректном завершении работы исходного кластера, которая может быть связана с вашей проблемой.

Метод, который я использовал и который не требует docker save или полного переноса (tar+untar) каталога /var/discourse: