В облако на работу: Архивирование postgres. Дайте два27.05.2024 13:15

В прошлых публикациях мы, не торопясь, после настройки персонального рабочего места на РедОС 7.3, посмотрели РедОС 8 и почти полностью собрали рабочую сеть 1С на отечественной ОС подходящую для работы среднего размера компании. С веб-серверами, доменной авторизацией и прочая прочая… Осталось настроить регулярное архивирование, чтобы не потерять нажитое. Тех, кто заинтересовался, прошу под кат…

Урок информатики в школе. Учитель поворачивает рубильник:
— Всё, урок закончен!
— Но мы же не сохранились! — в ужасе кричат дети.
Учитель, смягчившись, поворачивает рубильник обратно
— Ладно, сохраняйтесь.
anekdot.ru©

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

(уберу его под кат)

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

В мирах Microsoft есть набор из трех вариантов от вендора, слово «счастье» вы складываете из него, возможно докупая кубики у сторонних производителей при том же базовом наборе.
В мирах Postgres кто во что горазд и утилит резервного копирования тоже гораздо больше. Хорошо еще, что лидеры рынка, подсматривают фичи друг и друга и в непродолжительное время выкатывают их в прод.

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

Бэкапы нужны для факапов.

Пожалуй основное отличие 1С от других систем это то, для чего собственно нужен архив.
Как и то, что здесь он почти наверняка есть и проверен.

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

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

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

Об отказоустойчивости планирую отдельный выпуск, есть что показать, не переключайтесь.

У малышей и где руководство скупердяйничает, базы спасают ежедневной выгрузкой из конфигуратора, а не из СУБД.

В итоге

Архив нужен

В большинстве своем для создания и поддержания контура разработки и/или тестирования (свежая копия рабочей базы, обновленные актуальными данными базы разработчиков и база для экспериментов бухгалтерии/HR, для различных аудиторов).
Здесь желательно иметь переносимый между различными редакциями железа и версиями СУБД архив, зато нет особых запросов по скорости его создания.
Этот же архив уезжает на долгосрочное хранение поэтому желательно его иметь одним файлом.
Для восстановления определенных объектов рабочей базы.
Как известно, самый страшный (по крайней мере самый большой) вирус находится между стулом и клавиатурой. Частенько вы его видите в зеркале, частенько это бухгалтер с полными правами и «я что то нажала и оно что то сломалось».
В любом случае это восстановление не требует непрерывной архивации, потому что момент времени вспоминается обычно смутно.
Здесь желательно иметь архив рабочей базы ± 30 мин в течении рабочего дня.
Делаться он должен быстро и не мешать в работе пользователям.
Несколько особняком, но скорее сюда же относятся различные обновления конфигураций, перед которыми лучше сохраняться, чем нет.

Миры 1С занимают хорошо если 1% как приложения СУБД и у тех и у других вендоров, поэтому пользоваться в плане утилит надо тем что есть.

Хотя… Наверное если хорошо попросить разработчиков Postgres Professional, сделать бэкап файлов одной базы инстанса Postgres и его восстановление в другой инстанс в теории возможно, надо только все аккуратно прописать в системном каталоге. Это все равно будет в рамках одной версии СУБД и железа, но хоть чем то напоминать старый добрый бэкап Microsoft.

Отсюда и утилит резервного копирования будет две с различным функционалом и различным подходом к вопросу.

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

Тем кто не любит много букв

Сравнение вариантов архивации

Как итог:

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

По поводу других проверок, немного отстал от темы, возможно 1С гарантируют еще что-то.

Кроме этого минимальный размер архива.

Вполне пригоден pg_dump, если SLA вам это позволяет.

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

Как вариант не сжимать вовсе ничем и получить космическую скорость, тогда приготовить в два-три раза больше места.

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

Остальные буквы

И да. Вы же не храните архивы на сервере СУБД, поэтому перед архивированием обычно нужно подмонтировать сетевой ресурс/убедиться что он смонтирован.

Если в сети используется доменная авторизация, то пригодятся знания и keytab из прошлой публикации.

С помощью файла keytab получаем тикет авторизации, с его помощью монтируем сетевую шару примерно так:

#!/bin/bash
if! mountpoint -q /mnt/backup; then
kinit -k -t /1c/usr1cv83.keytab usr1cv83@TEST.LOC
mount -t cifs -o cruid=ХХХХХХХХ, sec=krb5, domain=TEST.LOC, sec=krb5, multiuser, dir_mode=0755, file_mode=0755, uid=1000, gid=1000 //<сервер долгосрочного хранилища/backup/1C> /mnt/backup
sleep 10
fi.

#далее если она смонтировалась начинаем архивирование

if mountpoint -q /mnt/backup; then
<строка архивирования, о которой поговорим далее>
sleep 60
umount /mnt/backup
fi.

Где ХХХХХХХХ это не то о чем все подумали, а id пользователя с правами доступа к каталогу хранения архивово получаемое

id -u usr1cv83

Переходим к самому резервному копированию

Исходные данные знакомые из предыдущих статей

Сервер 1С РедОС 8
Postgres 16 от PostgresPro
1С Предприятие 64-х 8.3.24.1467
все в домене test.loc.
Пользователь, от которого работает сервер 1С usr1cv83, пароли у всех 123456.
Все эти значения произвольные и должны в скриптах быть заменены на ваши.
все по железу 4ГБ RAM 50ГБ SSD 2 Ядра CPU
база Зарплата и управление персоналом КОРП, редакция 3.1 (3.1.29.62) демо

Чтобы было с чем сравнивать, первые два архива создаем штатными средствами 1С

конфигуратором
DATETIME=$(date +%Y_%m_%d_%H_%M); time /opt/1cv8/x86_64/8.3.24.1467/1cv8 DESIGNER /IBName «demo» /N «Савинская З.Ю. (Системный программист)» /DisableStartupDialogs /DisableStartupMessages /DumpIB /mnt/backup/${DATETIME}_demo.bak.dt
автономным сервером
DATETIME=$(date +%Y_%m_%d_%H_%M); time /opt/1cv8/x86_64/8.3.24.1467/ibcmd infobase dump --db-server=localhost --dbms=PostgreSQL --db-name=demo --db-user=postgres --db-pwd=123456 --user=«Савинская З.Ю. (Системный программист)» /mnt/backup/${DATETIME}_demo.ib.dt
pg_dump 1 поток без сжатия tar без сжатия
DATETIME=$(date +%Y_%m_%d_%H_%M); time sudo -u postgres pg_dump -d demo --format=d --compress=0 --jobs=1 --file /mnt/backup/${DATETIME}_demo.bak && time tar --create --file=/mnt/backup/${DATETIME}_demo.bak.tar /mnt/backup/${DATETIME}_demo.bak/* && rm -rf /mnt/backup/${DATETIME}_demo.bak/*
pg_dump 1 поток максимальное сжатие tar без сжатия
DATETIME=$(date +%Y_%m_%d_%H_%M); time sudo -u postgres pg_dump -d demo --format=d --compress=9 --jobs=1 --file /mnt/backup/${DATETIME}_demo.bak && time tar --create --file=/mnt/backup/${DATETIME}_demo_compress.bak.tar /mnt/backup/${DATETIME}_demo.bak/* && rm -rf /mnt/backup/${DATETIME}_demo.bak/*
pg_dump 1 поток без сжатия tar + bzip2 максимальное сжатие
DATETIME=$(date +%Y_%m_%d_%H_%M); time sudo -u postgres pg_dump -d demo --format=d --compress=0 --jobs=1 --file /mnt/backup/${DATETIME}_demo.bak && time tar --use-compress-program='bzip2 --best' --create --file=/mnt/backup/${DATETIME}_demo.bak.tar.bz /mnt/backup/${DATETIME}_demo.bak/* && rm -rf /mnt/backup/${DATETIME}_demo.bak/*
pg_dump 1 поток без сжатия tar + gzip максимальное сжатие
DATETIME=$(date +%Y_%m_%d_%H_%M); time sudo -u postgres pg_dump -d demo --format=d --compress=0 --jobs=1 --file /mnt/backup/${DATETIME}_demo.bak && time tar --use-compress-program='gzip --best' --create --file=/mnt/backup/${DATETIME}_demo.bak.tar.gz /mnt/backup/${DATETIME}_demo.bak/* && rm -rf /mnt/backup/${DATETIME}_demo.bak/*
pg_dump 1 поток без сжатия tar + gzip максимальное сжатие
DATETIME=$(date +%Y_%m_%d_%H_%M); time sudo -u postgres pg_dump -d demo --format=d --compress=0 --jobs=2 --file /mnt/backup/${DATETIME}_demo.bak && time tar --use-compress-program='gzip --best' --create --file=/mnt/backup/${DATETIME}_demo.bak.tar.gz /mnt/backup/${DATETIME}_demo.bak/* && rm -rf /mnt/backup/${DATETIME}_demo.bak/*
pg_probackup 2 потока максимальное сжатие
#+это установка и инициализация
dnf install -y repo.postgrespro.ru/pg_probackup/keys/pg_probackup-repo-centos.noarch.rpm
dnf install -y pg_probackup-16
pg_probackup-16 init -B /mnt/backup/pg_probackup
pg_probackup-16 add-instance -B /mnt/backup/pg_probackup -D /var/lib/pgpro/1c-16/data --instance=5432
chmod +777 -R /mnt/backup/pg_probackup
#-это установка и инициализация
sudo -u postgres pg_probackup-16 backup -B /mnt/backup/pg_probackup --instance 5432 -j2 --backup-mode=FULL --compress --stream --compress-level=9 --temp-slot
#-это DELTA и просмотр результатов
sudo -u postgres pg_probackup-16 backup -B /mnt/backup/pg_probackup --instance 5432 -j2 --backup-mode=DELTA --compress --stream --compress-level=9 --temp-slot
pg_probackup-16 show -B /mnt/backup/pg_probackup --instance 5432

Для pg_dump в свое время нашел отличный скрипт, который позволяет архивировать все базы кластера (инстанса Postgres) по одной и по очереди, не перечисляя их.

С небольшими правками:

#!/bin/bash
#Location to place backups.
# оригинал gist.github.com/powellc/4162155
backup_dir=»/var/backups/databases/»
#String to append to the name of the backup files
backup_date=$(date +%Y_%m_%d_%H_%M)
#Numbers of days you want to keep copie of your databases
number_of_days=15
databases=$(psql -l -t | cut -d'|' -f1 | sed -e 's/ //g' -e '/^$/d')
#for i in $databases; do if [ »$i» != «postgres» ] && [ »$i» != «template0» ] && [ »$i» != «template1» ]; then
for i in $databases; do if [[ »$i» ~= »_prod» ]]; then
echo Dumping $i
#pg_dump ${i} > ${backup_dir}${i}\_${backup_date}.sql
#здесь вы подставляете строку архивирования из опубликованных выше например ${i} это имя базы
fi
done
find $backup_dir -type f -prune -mtime +$number_of_days -exec rm -f {} \;

На этом все. Надеюсь, что удалось вставить свои пять копеек занять место между многотомными публикациями Хабра, из них моя рекомендация в первую очередь от самих разработчиков — Postgres Professional в обязательном порядке и советом из одного предложения делать бэкапы средствами СУБД.

P/S Чтобы не забыть.
Запустить 1С как конфигуратор, так и клиента без установки графического интерфейса можно в MobaXterm, доустановив пакеты
dnf install -y xorg-x11-xauth xorg-x11-fonts-* xorg-x11-font-utils xorg-x11-fonts-Type1
и
mcedit /etc/ssh/sshd_config
проверив
X11Forwarding yes

Благодарности:

Благодарю компанию ©Serverspace за предоставленное оборудование, без поддержки собрать такой пингвинариум мне было бы негде.

Планы на будущее:

Имея такой развернутый контур, грех не написать про отказоустойчивый кластер.

Надеюсь это и сделать, а потом уйти в лето.

Статья продолжает серию публикаций:

Серия «Рецепты от Капитана» на всякий случай

Ссылки для более подробного изучения уберу под кат