Делаем бекап проекта простым путём

Сегодня 07.07.2022. Два дня назад я очень глупо и почти случайно потерял всё, что было на этом сервере. Бэкапы были только от мая — это лучше, чем ничего, однако регулярного резервирования не было. Тут либо жизнь меня ничему не учит, либо уже научила и я стал достаточно аккуратен, чтобы не ронять проды как слон в посудной лавке, позволив себе облениться ¯\_(ツ)_/¯

В общем, бекапы развернул, всё настроил; делал это в течение нескольких часов на протяжении двух дней. Жаль, я не помню что я мог или потерял окончательно, так что если не досчитаетесь каких-то постов — ну штош.

До этого я не парился с бекапами: ну есть же какие-то, сервак не шатаю, по счетам плачу сполна, чё ему будет-то? Вчера я психанул и забацал простой скрипт, который делает всё за меня.

В этот раз я поленился правильно, как должно: не хочешь заниматься рутиной — автоматизируй и не занимайся.

Поскольку проекты развёрнуты по-старинке, на сервере нет докеров или чего-то сложного, значит и решение элементарно: bash + mysqldump + gzip + rsync + crontab + запасной сервер.

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

Дано

• проект на srvprod.org
  • файлы проекта
  • БД проекта (MariaDB/MySQL)
• подгоревшее кресло
• запасной сервер srvbak.com
  • с кучей свободного места
  • с доступом по ssh

Решение

Для начала надо настроить связь между серверами, точнее, с прода на резервный. Это делается за две минуты. Буквально. То есть, нет, я не засекал, но тут всё очевидно.

На проде srvprod.org:

$ ssh-keygen
<enter><enter><enter><enter><enter><enter>...
$ cat ~/.ssh/id_rsa.pub

Вывалится публичный ключ, хватай его в буфер обмена.

На резервном srvbak.com:

$ echo "<ключ>" >> ~/.ssh/authorized_keys

Теперь пытаемся подключиться вручную с прода на резервный:

$ ssh nagibator666@srvbak.com

Подключился — молодец, треть дела сделано.

Теперь надо слить БД и упаковать файлы проекта. Для первого используется mysqldump пайпом в gzip. Для второго — любимый tar -zcf.

$ mysqldump -q <параметры> <имябд> | gzip > <путь/к/файлу>sql.gz
$ tar -zcf <имяфайла>.tar.gz <путь/к/проекту>

Два полученных файла отправляем rsync-ом (или scp) на дальний сервер. Но сначала надо проверить — восстановимы ли вообще эти бекапы. Для БД это делается через:

$ zcat <путь/до/бекапа>.sql.gz | mysql -pu <юзербд> <имябд>

Для архива проекта:

$ tar -xzf <путь/до/бекапа>.tar.gz

Просматриваем, как угодно проверяем. Нормально — шлём. Это достаточно сделать однажды при настройке резервирования. Можно по желанию, время от времени, лишним не будет.

Файлы будем сохранять как локально на проде (для простоты), так и на дальнем сервере (для надёжности). Файловая структура будет строиться на основе даты и времени:

/backup/2022.02.03/12.34-sql.gz
маска:     |  |  |  |  |
          %Y.%m.%d %H.%M

На резервном сервере надо будет создавать директорию отдельной командой, сразу после аналогичной локальной:

$ mkdir -p /backup/$(date +%Y.%m.%d)
$ ssh nagibator666@srvbak.com "mkdir -p /backup/$(date +%Y.%m.%d)/"

Таким образом мы сможем сортировать список файлов и директорий по именам туда-сюда без мешанины и чётко будем знать когда и во сколько снят снимок.

Вроде всё основное сделали, осталось отправить:

$ # оба варианта по сути идентичны:
$ rsync --progress <имяфайла> nagibator666@srvbak.com:/backup/2022.02.03/<имяфайла>
$ scp <имяфайла> nagibator666@srvbak.com:/backup/2022.02.03/<имяфайла>

Я выставил первой отправку дампа БД, второй — архив файлов, третий — лог резервирования. Данные в БД меняются чаще, чем файлы (которые, вообще-то, можно и гитом рулить), а лог — ну раз пишем, то пусть будет.

Вот готовый гист:

Изучаем, заполняем переменные, корректируем и вешаем это добро на крон, скажем, каждые 4 часа ежедневно:

* */6 * * * .../backup.sh

Сюда можно накрутить чего ещё угодно твоему извращённому вкусу. Для меня пока остались вот эти конкретные вещи (в первом приближении):

• автоочистка старых бекапов с обеих сторон:
  • локальные бекапы на проде надо хранить недолго, ибо:
    • они ненадёжны по определению, хранить их там — в принципе не очень смысленно, ибо одна точка отказа;
    • они занимают место на диске прода, и чем их больше, и чем они больше, тем быстрее от них хочется избавиться;
  • хранение на резервном сервере должно быть намного дольше, но там диск тоже не резиновый;
• логирование хешей файлов: я должен знать, что в логах фигурируют одни и те же файлы с одинаковыми хешами и они не пострадали при пересылке на удалённый сервер (например, если почему-то, внезапно, так случится — закончится место на диске или дамп базы завершился с ошибкой и файл недозаписался);
• не пытаться отправить файл, который не был создан;
• чё-то ещё, забыл…

Ну вроде всё. Может ещё дополню пост раз-два.

P.S.: вот это — лютое говно.