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

1️⃣ Читал статью на хабре, как разработчик случайным запросом очистил базу пользователей и похоронил коммерческий проект, так как бэкап был месячной давности.

2️⃣ Мне в личные сообщения написал человек и попросил помочь. У него умер рейд массив на контроллере домена. Он бэкапился встроенным резервным копированием винды. При восстановлении оказалось, что ничего не восстанавливается, система пишет, что не видит бэкапа в указанном месте.

В обоих случаях бэкапы вроде бы и делались, но не проверялись. По факту оказалось, что их нет.

3️⃣ Эта история более насыщенная, так как я в ней лично поучаствовал. Обратился старый заказчик, которому я несколько лет назад настраивал инфраструктуру. Но не поддерживал её. Если кому-то что-то настраиваю, то сразу предупреждаю, что поддерживать не буду. У меня нет такой возможности. Всё аккуратно передаю и объясняю, чтобы дальше без моего участия можно было вести дела.

Но тут сделал исключение. Был поздний вечер, уже собирался спать, всё выключил. Ну и как обычно проверил Telegram. А там умер виндовый сервер с кучей баз 1С. Утром придут люди и «прибьют меня».

Базы были как файловые, так и в MSSQL. Бэкапы файловых баз были, скульных – свежих нет. Но бэкап это пол дела. Системы то самой нет. Надо всё с нуля поднимать и настраивать, восстанавливать лицензии, делать публикации. На дворе ночь, подменного сервера нет.

Сервер вёл себя странно. Он нормально загружался до своей заставки с часами. А дальше ни на что не реагировал. Если раз 10 нажать CTRL+ALT+Delete, падает в чёрный экран и больше ни на что не отвечает. Но при этом курсор двигается, активен порт RDP, но удалённые соединения не устанавливаются. Залогиниться не получалось даже локально.

Загрузился в режиме восстановления, успешно зашёл в систему. Весь системный лог в ошибках. Службы не запускаются, какие-то файлы недоступны, на диске ошибки. Но при этом sfc /scannow и DISM /Online /Cleanup-Image /RestoreHealth ошибок не показывают.

Запускаю chkdsk C: /f /r и перезагружаю. Во время проверки долго висит на 15%, по графикам VM видно, что очень активно шерстит NVME дисками. В итоге проверка до конца не доходит, аварийно вырубается и система заново загружается с теми же проблемами.

Я не верил, что эту систему можно оживить. Слишком много каких-то неведомых проблем. Заказчик предложил удалить программу Обновлятор-1С, так как впервые система зависла и начались проблемы во время её работы. Я знаю эту программу. Она довольно старая и известная. Cам не раз пользовался. Каких-то глобальных проблем с ней не видел. Стояла купленная лицензионная версия.

Не думал, что удаление программы на что-то повлияет. Загрузился в безопасном режиме, удалил программу, перезагрузился. Система запустилась как ни в чём ни бывало. Никаких ошибок ни с диском, ни с файлами, ни со службами. Я не знаю, что она там делала и как ломала систему. Но факт есть факт. Дело реально было в ней.

☝️ Мораль тут какая? Бэкапить надо не только данные, но и системы. Иначе в час ИКС ты просто не будешь знать, что тебе делать. Надо искать и железо, и систему восстанавливать. А потом на неё данные накатывать. Это очень долго. Наверняка окажется, что и версий подходящих нет. Я практически всегда делаю бэкап и виртуальной машины и отдельно данных. Ну и по возможности всё это проверяю. Если не проверять, то очень велика вероятность, что в час ИКС ничего восстановить и не получится. Бэкапы могут месяцами не создаваться или создаваться битыми. Для баз данных это очень актуальная тема.

Кстати, описанная инфраструктура была построена примерно вот так. Уже не первый раз убеждаюсь, что это работает просто и надёжно. И почти не требует обслуживания. Главное, бэкапы данных и виртуальных машин делать.

#backup

▶️ Очередная подборка авторских IT роликов, которые я лично посмотрел и посчитал интересными/полезными. Это видео из моих подписок за последнее время (обычно беру период в 2 недели), что мне понравились.

⇨ Postgresus - удобный домашний бекап баз данных
Коротенький обзор веб панели программы для бэкапа PostgreSQL серверов. Выглядит удобно и полезно. Скорее всего тоже попробую и сделаю отдельный обзор. Бэкапы она делает только полные, так что подойдёт только для небольших баз. У меня есть сервера, где как раз куча небольших баз 1С. Возможно, с этой панелькой будет удобно их бэкапить и быстро восстанавливать.

⇨ Self-Host Your Own Automation Platform with n8n + Docker
Очередной обзор и примеры использования платформы для автоматизации n8n. Это очень популярная и функциональная штука. Я пару раз за неё садился и пытался к чему-нибудь приспособить, но ничего дельного не получалось. Её на самом деле с наскока трудно освоить, хоть она и позиционируется как простое no-code решение. Кто не знаком с ней, рекомендую посмотреть. Может приспособите её куда-то к себе.

⇨ Сжатие текста в Angie: статика, динамика, производительность
Обзор и тесты различных режимов сжатия в веб сервере. Я всё это неплохо знаю и в своё время тестировал и использовал различные алгоритмы: gzip, brotli, zstd. Про последний делал отдельную заметку с описанием настройки. Я лично почти везде включаю zstd на веб серверах.

⇨ Zabbix 7.4 Host Wizard Overview
Видео актуально, если вы не собираетесь обновляться до 7.4, но хотите посмотреть, как выглядит новый интерфейс добавления хостов в Zabbix Server.

⇨ OAuth 2.0 — Простым языком на понятном примере
Автор подробно и с примерами показал, как работает OAuth и OpenID Connect. Часто упоминаю эти технологии, когда рассказываю про тот или иной софт. Если не знаете, что это такое, то посмотрите видео.

⇨ Grafana Alloy, NEW log + metric collector replaces everything!
Обзор инструмента Grafana Alloy. Думал это что-то новое, но не особо то и новое. Год уже точно существует. Честно говоря, впервые услышал про этот продукт. Никогда не видел и не слышал. Он собирает логи и метрики. По сути это аналог promtail, opentelemetry collector и т.д.

⇨ ALT Linux 10 установка КриптоПРО 5 с поддержкой ключей от 4-й версии
Настройка работы КриптоПРО на рабочей станции ALT.

⇨ Устанавливаем Fedora Server 42 — Идеальный дистрибутив для self-hosting?
Практической пользы нет, но мне было любопытно посмотреть. Вообще не знал, что у Fedora есть сервер. После видео так и не понял, зачем он нужен.

⇨ Прямое подключение NAS к ПК по 10GbE
Видео простенькое, для обычных пользователей. Но мне было интересно посмотреть, что за адаптеры с подключением по usb-c используются для этого (цена ~6 т.р.), какие провода и т.д. На практике я вообще никогда не настраивал такие интерфейсы. Были кое-где на арендных серверах, но там настраивать ничего не надо. Сразу выдают настроенные.

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

#видео

Раз уж я рассмотрел панели для управления бэкапами (Postgresus и Pgbackweb) в виде дампов в Postgresql, было бы логично рассмотреть и вариант со своими велосипедами на bash. Поделюсь тем, что использую я.

Сначала полный текст скрипта для бэкапа:

#!/bin/bash

BASES=`/opt/pgpro/1c-16/bin/psql -U postgres -l | grep "_buh\|_zup" | awk '{print $1}'`
DATA=`date +"%Y-%m-%d_%H-%M"`
LOGDIR=/var/lib/pgpro/service_logs
BACKUPDIR=/var/lib/pgpro/backup

for i in ${BASES};
    do
    echo "`date +"%Y-%m-%d_%H-%M-%S"` Start backup $i" >> $LOGDIR/backup.log
    /opt/pgpro/1c-16/bin/pg_dump -U postgres $i > $BACKUPDIR/$DATA-$i.sql 2>> $LOGDIR/dump.log
    BEGIN=`head -n 2 $BACKUPDIR/$DATA-$i.sql | grep ^'-- PostgreSQL database dump' | wc -l`
    END=`tail -n 3 $BACKUPDIR/$DATA-$i.sql | grep ^'-- PostgreSQL database dump complete' | wc -l`
    if [ "$BEGIN" == "1" ];then
      if [ "$END" == "1" ];then
          echo "Backup ${i} is OK" >> $LOGDIR/backup.log
          /usr/bin/pigz -c $BACKUPDIR/$DATA-$i.sql > $BACKUPDIR/$DATA-$i.sql.gz
          /usr/bin/rm $BACKUPDIR/$DATA-$i.sql
      else
          echo "Backup ${i} is corrupted" >> $LOGDIR/backup.log
      fi
    else
      echo "Backup ${i} is corrupted" >> $LOGDIR/backup.log
    fi
      echo "`date +"%Y-%m-%d_%H-%M-%S"` End backup $i" >> $LOGDIR/backup.log
      echo "=========================================" >> $LOGDIR/backup.log
done

Рассказываю, что тут происходит:

1️⃣ Завожу в переменную BASES список баз, которые мы будем бэкапить. Их можно указывать вручную, примерно так: BASES=("db01_zup" "db02_buh"). Можно брать список всех баз. В данном случае на сервере я маркирую базы метками _buh и _zup в названиях баз, чтобы по ним делать выборку. Если базу не нужно бэкапить, то эта метка не ставится. Можно придумать любую свою метку, например _back. Это позволяет автоматически бэкапить все нужные базы, не следя за их составом. Очень актуально, если создаёте и удаляете базы не вы, но вам нужны все бэкапы баз.

Можно использовать обратный подход. Бэкапить все базы, но вручную или по маске задавать исключения. Примерно так:

/opt/pgpro/1c-15/bin/psql -U postgres -l | grep -wv 'template0\|template1\|test-base\|_test' | sed -e '1,3d' | head -n -2 | awk '{print $1}'`

2️⃣ База дампится с помощью pg_dump без каких-либо дополнительных параметров. На выходе имеем обычный несжатый текстовый дамп.

3️⃣ В дампе проверяем наличие строки -- PostgreSQL database dump в начале дампа и -- PostgreSQL database dump complete в конце. Поэтому нам важно иметь дамп в текстовом формате. Если процесс снятия дампа прошёл без ошибок и в дампе присутствуют эти строки, то с большой долей вероятности с ним всё в порядке. Я ни разу не сталкивался с обратной ситуацией.

Соответственно, если строки присутствуют, пишем в лог файл, что Backup is OK, если есть проблемы, то Backup is corrupted. Дальше этот файл забирает либо мониторинг, либо хранилка логов. И если они видят фразу corrupted, то срабатывает триггер.

4️⃣ Если с дампом всё в порядке, то он жмётся архиватором pigz. Он работает многопоточно всеми доступными ядрами процессора. Если не хотите нагружать так плотно сервер, то количество потоков можно ограничить ключами. Я обычно снимаю дампы ночью и жму на всю катушку, чтобы побыстрее завершилось. Дампы потом ещё передавать надо. Это уже отдельная процедура и запускается с сервера бэкапов. С самого сервера СУБД к бэкапам доступа нет.

Получается автоматическая максимально простая и эффективная схема работы. Я вчера добавлял базы в веб панель. Честно говоря, меня это утомило. Если баз 1-2, то не проблема. А 15 штук добавлять уже надоедает. Бывает и больше. Плюс, надо вручную следить за ними, добавлять, отключать ненужные и т.д. Так что панель вроде и выглядит удобно, но если баз много, то удобства уже сомнительные.

Дальше у меня работает ещё один простой скрипт, который забирает эти дампы на тестовый сервер, распаковывает и заливает в СУБД. Расскажу о нём в следующей заметке.

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

#postgresql #backup #script