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

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

Раз уж я рассмотрел панели для управления бэкапами (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

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

PBS умеет бэкапить как виртуальные машины с уровня гипервизора, так и файлы внутри виртуальных машин с помощью Proxmox Backup Client. Сервер бэкапов делится на Datastores со своими бэкапами и настройками доступа. Каждый Datastore штатно может быть синхронизован с другим удалённым Datastore на другом PBS. Это позволяет строить распределённые системы хранения данных, где бэкапы синхронизируются автоматически и хранятся в соответствии с заданными локальными политиками хранения. Получается удобная и функциональная распределённая система бэкапов. И при этом полностью бесплатная.

Имеем 2 разных PBS: pbs-local и pbs-remote. На первый бэкапятся виртуальные машины и затем бэкапы синхронизируются в режиме Push на второй сервер. Рассказываю, как это настроить.

1️⃣ На pbs-remote идём в Configuration -> Access Control и создаём пользователя, под которым будет подключаться pbs-local. Велик соблазн везде использовать root и полные права, но не рекомендую так делать. Тут же в разделе Permissions добавляем новому пользователю следующие права:

Path: /datastore/{store}
Role: DatastoreBackup

{store} - название Datastore, куда будут синхронизироваться бэкапы. Можно создавать для каждого Datastore своего пользователя, можно использовать одного для всех. Тут уже решайте сами, как будете дробить доступ.

2️⃣ На pbs-local идём в Configuration -> Remotes и добавляем pbs-remote, используя созданную выше учётную запись.

3️⃣ На pbs-local в разделе Configuration -> Access Control -> Permissions для пользователей локальных Datastore, которые будут синхронизироваться, добавьте права:

Path: /remote
Role: RemoteSyncPushOperator

4️⃣ На pbs-local идём в Datastore, выбираем тот, что хотим синхронизировать. Переходим в раздел Sync Jobs и добавляем задачу Add Push Sync Job. Выбираем добавленный на шаге 2 remote и выбираем остальные параметры, в том числе расписание синхронизации.

На этом всё. Теперь можно либо дождаться времени выполнения, либо запустить синхронизацию принудительно. По завершении на pbs-remote будет копия всех бэкапов. То есть на обоих серверах раздел Content будет идентичным. Можно подключить pbs-remote к какому-то гипервизору и там проверять восстановление и запуск виртуальных машин. Это удобно делать, расположив PVE и PBS на одном железном сервере. Получается универсальный инструмент и для дополнительной копии бэкапов, и для их проверки.

Отдельно отмечу, что синхронизация хорошо переносит нестабильные соединения. Процесс не прерывается при разрывах связи и её отсутствии в течении нескольких минут. При возобновлении связи синхронизация продолжается.

Ту же самую процедуру синхронизации можно проводить в обратном направлении, то есть по модели Pull, когда удалённый сервер сам подключается к локальному и забирает данные. Можно всё это комбинировать. Например, VM бэкапятся в локальный Datastore, куда и них есть доступ. Потом на этом же PBS эти бэкапы по модели Pull копируются в рамках этого же сервера, но в другой Datastore, куда доступ ограничен. А с этого Datastore бэкапы по Pull или Push копируются на удалённый сервер.

Настройки очень гибкие и зависят от вашей инфраструктуры, режима параноидальности и доступного места для хранения. Напомню, что в каждом Datastore могут быть свои политики хранения бэкапов. Где-то храним 5 последних копий, а где-то 7 дневных копий, 4 недельных и 6 месячных. А куда-то складываем месячные и вообще не удаляем.

В 4-й версии PBS будет ещё пачка приятных нововведений. Например, хранение бэкапов в S3. И всё это бесплатно.

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

#proxmox #backup

На канале в разное время было много упоминаний про консольную утилиту для бэкапа restic. Она популярна в последнее время, много статей и роликов видел с её участием. Не буду много про неё рассказывать, перечислю только основные плюсы. А далее покажу один практический пример.

▪️Есть под все популярные системы, состоит из одного бинарника на go, есть в базовых репозиториях.
▪️Все данные по умолчанию шифруются.
▪️Формат хранения данных в виде снепшотов с дедупликацией.
▪️Поддерживает хранилища: локальная директория, SFTP, S3, свой сервер rest с доступом по HTTP и некоторые другие.
▪️Встроенная проверка целостности данных.
▪️Все параметры можно передавать ключами и переменными.

Я покажу далее, как забэкапить данные с помощью restic в S3 бакет на примере хостера Selectel. Настройка будет плюс-минус идентичной для любого облачного провайдера. У меня S3 бэкапы лежат там, поэтому показываю на данном примере. У хостеров может быть немного запутанной схема предоставления доступа к бакетам, так что иногда приходится повозиться немного, если делаешь впервые.

1️⃣ Создаю бакет у провайдера. В данном случае иду в раздел Инфраструктура ⇨ S3 ⇨ Бакеты. Создаю новый:
◽️Тип бакета: Приватный
◽️Класс хранения: Холодное хранение
◽️Версионирование: отключено (restic сам будет заниматься версионированием)
◽️Тип адресации: vHosted

Далее в разделе Аккаунт ⇨ Сервисные пользователи добавляю нового пользователя, роль - Пользователь S3, Проект - выбранный проект, где создан бакет. Тут же перехожу во вкладку Доступ и создаю S3-ключи. Нужно записать Access key и Secret key. Они нам понадобятся при настройке Restic.

Возвращаюсь в настройки бакета, перехожу на вкладку Политика доступа, создаю политику, где выбираю полный доступ для только что созданного пользователя.

Бакет сделали, доступ настроили. Я получил следующие данные:
S3_HOST=https://s3.ru-1.storage.selcloud.ru
S3_BUCKET=restic55
ACCESS_KEY_ID=XXXXXXXXXX
SECRET_ACCESS_KEY=YYYYYYYYYY

2️⃣ Идём на сервер и устанавливаем Restic:

# apt install restic

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

# unset HISTFILE
# export AWS_ACCESS_KEY_ID=XXXXXXXXXX
# export AWS_SECRET_ACCESS_KEY=YYYYYYYYYY
# export RESTIC_PASSWORD="ZZZZZZZZZZ"

Пароль RESTIC_PASSWORD нужно обязательно сохранить. Без него бэкапы не расшифровать, доступа к ним не будет. Инициализируем репозиторий:

# restic init -r s3:https://s3.ru-1.storage.selcloud.ru/restic55

Теперь туда можно бэкапить:

# restic backup -r s3:https://s3.ru-1.storage.selcloud.ru/restic55 /var/www

Проверяем список бэкапов. В терминологии restic это snapshots:

# restic snapshots -r s3:https://s3.ru-1.storage.selcloud.ru/restic55
....
18eba378 2025-09-01 18:59:24 debian12-vm       /var/www
....

У нас только один snapshot. Восстановим его:

# mkdir /tmp/restore
# restic restore 18eba378 -r s3:https://s3.ru-1.storage.selcloud.ru/restic55 --target /tmp/restore

В директории /tmp/restore будут файлы этого снепшота.

Restic может автоматически ротировать снепшоты. Для этого у него есть набор ключей с гибкими настройками. Например:

🔹--keep-last N – последние N бэкапов
🔹--keep-daily N – для последних N дней, в которых есть один или несколько снимков, сохранять только самый последний снимок за каждый день
🔹--keep-within-daily duration – сохранять по одному последнему снимку, сделанному в течение указанного duration.

И так далее для разных временных отрезков. Наглядный типовой пример политики хранения:

--keep-within-daily 7d --keep-within-weekly 1m --keep-within-monthly 1y

Храним 7 дневных бэкапов, 4 недельных, 12 месячных.

Вы можете написать свои bash костыли для Restic, а можете взять что-то готовое. Например, вот репозиторий, где есть скрипт для бэкапа в S3 с логированием, с некоторыми проверками, с хранением параметров и пароля доступа в отдельных файлах.

⇨ 🌐 Сайт / Исходники / Документация

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

#backup #restic #s3

🔥 Бэкап баз postgresql с помощью restic!

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

⇨ Restic: эффективное резервное копирование из Stdin

Автор с помощью restic дампит базы данных в Kubernetes. Я немного переделал его решение для своих локальных бэкапов. Основная проблема, которая там решена - корректная отработка ошибок снятия дампа. Я до этого сам не догадался, правда не сильно и пытался, поэтому дампил по старинке сначала в файл, проверял, а потом уже куда-то на хранение отправлял.

Но можно всё это сделать на лету и с проверкой ошибок. То есть делается дамп и тут же через pipe отправляется в restic. Этот способ удобен по нескольким причинам:

1️⃣ Самое основное - сырые дампы в restic очень хорошо дедуплицируются и экономят место. Если между дампами небольшие изменения, то даже хранение большого количества файлов за разные дни не съедает место на хранилище в отличие от обычного хранения в исходном виде на файловой системе.

2️⃣ Прямая отправка данных с pg_dump в restic исключает промежуточное сохранение, что существенно экономит ресурс SSD дисков, если у вас много баз приличного размера. Да и банально быстрее получается.

3️⃣ Если во время снятия дампа будет ошибка, то такой бэкап помечается отдельным тэгом и по этому тэгу вы сможете понять, что у вас какая-то проблема. Я специально проверил этот момент. Отрабатывает корректно. Если дамп прерывается по какой-то причине и не завершается без ошибок, то этот бэкап помечается отдельным тэгом.

В статье у автора подробно всё рассказано, не буду на этом останавливаться. Покажу свой итоговый скрипт, который бэкапит дампы условно локально, а не в S3. Если надо в S3 или куда-то ещё, то просто измените переменную REPO_PREFIX в скрипте и добавьте переменных для доступа к бакетам. Плюс, я поменял формат хранения данных. Вместо tar выгружаю в текстовый sql файл. Мне так удобнее. Ещё исправил там небольшую ошибку, которую выявил во время тестов. В строке:

restic forget -r "${REPO_PREFIX}/$db" --group-by=tags --keep-tag "completed"

Надо убрать ключ --group-by=tags, иначе команда на очистку будет возвращать ошибку:

refusing to delete last snapshot of snapshot group "tags [job-8dd4f544]"

Это, как я понял, связано с тем, что ключ --keep-tag не позволяет удалить при группировке по тэгам полную группу тэгов, если в ней не останется хотя бы одного снепшота. А так как у нас все тэги с job уникальны, все проблемные снепшоты будут с уникальными тэгами и по сути одни в группе. Поэтому группировку --group-by=tags надо убрать. По крайней мере у меня, когда я убрал, ошибка ушла и очистка стала нормально отрабатывать. В доках это так объясняется: "The forget command will exit with an error if all snapshots in a snapshot group would be removed as none of them have the specified tags."

И ещё важный момент. Не забудьте сохранить пароль от репозитория, который тоже задаётся в скрипте. Так как пароль передаётся в виде переменной окружения, его можно хранить где-то отдельно и подгружать перед запуском основного скрипта. Я в предыдущей заметке про restic упоминал об этом и показывал пример в конце.

Сам скрипт прикрепил к сообщению. Также продублировал его в публичный репозиторий. Не забудьте поменять переменные под свои нужды и окружение.

Полезные материалы по теме:

▪️Описание Restic с примерами
▪️Мониторинг Restic с помощью Zabbix и Prometheus
▪️Бэкап с помощью Restic в S3 на примере Selectel

Restic очень удобный инструмент для бэкапов. Рекомендую присмотреться.

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

#backup #postgresql #restic