Урок информатики в школе. Учитель поворачивает рубильник:
— Всё, урок закончен!
— Но мы же не сохранились! — в ужасе кричат дети.
Учитель, смягчившись, поворачивает рубильник обратно
— Ладно, сохраняйтесь.
anekdot.ru©
А вы, конечно же, ждали поговорку про админов, которые уже делают бэкапы?
Обычно, статьи про резервное копирование начинают с нее. Самые смелые еще прикладывают картинку с деревянным бегемотом.
Далее, следуют страшные истории про накрывшиеся белым дымом сервера и датацентры. Гуру системного администрирования могут рассказывать их сотнями, также как и про то, как и чем лучше делать бэкапы.
В мирах Microsoft есть набор из трех вариантов от вендора, слово "счастье" вы складываете из него, возможно докупая кубики у сторонних производителей при том же базовом наборе.
В мирах Postgres кто во что горазд и утилит резервного копирования тоже гораздо больше. Хорошо еще, что лидеры рынка, подсматривают фичи друг и друга и в непродолжительное время выкатывают их в прод.
Поэтому давайте не будем углубляться в подробности самого процесса, а рассмотрим особенности, касающиеся 1С.
Назвать эту публикацию рецептом язык не поворачивается, здесь скорее бакалейная лавка умеренного ассортимента, каждый выбирает по вкусу и кошельку продуктовую корзину.
Бэкапы нужны для факапов.
Пожалуй основное отличие 1С от других систем это то, для чего собственно нужен архив.
Как и то, что здесь он почти наверняка есть и проверен.
В мирах 1С крайне редко требуется полное восстановление из бэкапа рабочей базы. История об этом конечно есть у каждого, но как правило это ...
Даже в малых компаниях, не говоря уже о средних и больших не экономят на железе.
Поэтому при наличии сисадмина с прямыми руками вас будет спасать отказоустойчивость, не надо ее путать с архивированием.
Об отказоустойчивости планирую отдельный выпуск, есть что показать, не переключайтесь.
У малышей и где руководство скупердяйничает, базы спасают ежедневной выгрузкой из конфигуратора, а не из СУБД.
В итоге
Архив нужен
- В большинстве своем для создания и поддержания контура разработки и/или тестирования (свежая копия рабочей базы, обновленные актуальными данными базы разработчиков и база для экспериментов бухгалтерии/HR, для различных аудиторов).
Здесь желательно иметь переносимый между различными редакциями железа и версиями СУБД архив, зато нет особых запросов по скорости его создания.
Этот же архив уезжает на долгосрочное хранение поэтому желательно его иметь одним файлом. - Для восстановления определенных объектов рабочей базы.
Как известно, самый страшный (по крайней мере самый большой) вирус находится между стулом и клавиатурой. Частенько вы его видите в зеркале, частенько это бухгалтер с полными правами и "я что то нажала и оно что то сломалось".
В любом случае это восстановление не требует непрерывной архивации, потому что момент времени вспоминается обычно смутно.
Здесь желательно иметь архив рабочей базы +- 30 мин в течении рабочего дня.
Делаться он должен быстро и не мешать в работе пользователям.
Несколько особняком, но скорее сюда же относятся различные обновления конфигураций, перед которыми лучше сохраняться, чем нет.
Миры 1С занимают хорошо если 1% как приложения СУБД и у тех и у других вендоров, поэтому пользоваться в плане утилит надо тем что есть.
Хотя… Наверное если хорошо попросить разработчиков Postgres Professional, сделать бэкап файлов одной базы инстанса Postgres и его восстановление в другой инстанс в теории возможно, надо только все аккуратно прописать в системном каталоге. Это все равно будет в рамках одной версии СУБД и железа, но хоть чем то напоминать старый добрый бэкап Microsoft.
Отсюда и утилит резервного копирования будет две с различным функционалом и различным подходом к вопросу.
За футшток взята выгрузка базы из конфигуратора 1С, метод вполне рабочий для небольших баз, с достаточно большим недостатком — с базой данных, которая выгружается в dt-файл, не должно быть никаких подключений
Тем кто не любит много букв
Сравнение вариантов архивации
Вариант | Скорость сек. | Размер архива Кб. |
выгрузка базы из конфигуратора 1С | 47,26 | 383421 |
выгрузка базы автономным сервером 1С | 27,47 | 383421 |
pg_dump 1 поток без сжатия tar без сжатия | 9,70+2,15 | 1094000 |
pg_dump 1 поток максимальное сжатие tar без сжатия | 49,13+0,74 | 466530 |
pg_dump 1 поток без сжатия tar + bzip2 максимальное сжатие | 9.49+125.42 | 385872 |
pg_dump 1 поток без сжатия tar + gzip максимальное сжатие | 9.52+45.31 | 432729 |
pg_dump 2 потока без сжатия tar + gzip максимальное сжатие | 7.95+45.21 | 432726 |
pg_probackup 2 потока максимальное сжатие FULL backup | 35,78 | 472000 |
Кто не любит буквы совсем может посмотреть видео
Как итог:
Если для вас не проблема в нерабочее время отключить всех пользователей, не стоит недооценивать штатные средства 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
- все развернуто в облаке ©Serverspace из оригинальных iso образов производителей для чистоты эксперимента.
- база Зарплата и управление персоналом КОРП, редакция 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 за предоставленное оборудование, без поддержки собрать такой пингвинариум мне было бы негде.
Планы на будущее:
Имея такой развернутый контур, грех не написать про отказоустойчивый кластер.
Надеюсь это и сделать, а потом уйти в лето.
Статья продолжает серию публикаций:
- Бесплатный вебинар "В облаке, как дома: Как настроить рабочее место пользователя 1С на базе РЕД ОС"
- В облаке, как дома: Устраиваемся поудобнее. Рабочее место пользователя 1С на базе РЕД ОС (HTTPS и архивирование)
- Три пингвина под окном… Обзор рабочих мест пользователя 1С, собранных на отечественных дистрибутивах linux
- Три пингвина под окном… Точки над Ё. Обзор рабочих мест пользователя 1С, собранных на отечественных дистрибутивах linux
- Установка 1С: Сервера взаимодействия. Заметки на полях
- Сервер 1С: Предприятие на Ubuntu 16.04 и PostgreSQL 9.6, для тех, кто хочет узнать его вкус. Рецепт от Капитана обратите внимание на дату публикации
- 1С в 1cloud.ru. Теплое, ламповое, свое отчет о походе в питерский офис ©Serverspace когда он еще не был Serverspace
Серия "Рецепты от Капитана" на всякий случай
- Подготовка к экзамену 1С: Специалист по платформе. Рецепты от Капитана
- Настройка сборки данных в Performance Monitor Windows Server. Рецепты от Капитана
- Сервер 1С: Предприятие на Ubuntu 16.04 и PostgreSQL 9.6, для тех, кто хочет узнать его вкус. Рецепт от Капитана
pg_dump на сайте документации Postgres Professional
pg_probackup на сайте документации Postgres Professional и github
сравнение архиваторов Linux
Запуск графических приложений (X11) по SSH на удаленном сервере Linux с помощью MobaXterm в Windows
скрипт для pg_dump
Комментарии (8)
pr0l
27.05.2024 12:26autopostgresqlbackup не подходит? сам раскладывает по дням неделям и месяцам
capitannemo Автор
27.05.2024 12:26Спасибо. Надо будет посмотреть. Прямо космолет какой то.
Сами его используете?
edu_RDTEX
27.05.2024 12:26Начинаем через 10 минут! Подключайтесь к трансляции!
https://t.me/oraclemasters
Eremkin
27.05.2024 12:26не стоит недооценивать штатные средства 1С, они по крайней мере гарантируют, что выгруженный файл загрузится обратно.
Ой не факт что гарантированно. Для таких случаев периодически надо делать процедуру тестирования и исправления (штатное средство самой платформы 1С). Да и в стандартах 1С говорится что dt-файл не является бэкапом. Хотя кого это волнует собственно ))
capitannemo Автор
27.05.2024 12:26В-Внимательность
Я же написал загрузится обратно, а не оттестирует логику БД
dtkbrbq
На маленькой базе это все конечно хорошо, но что делать когда база весит 1Тб, ее бекап по 10Гбит сети занимает 2.5 часа(через pgdump, без сжатия), а восстановление - 9 часов. При этом узких мест нигде не наблюдается.
capitannemo Автор
Каждый конкретный случай надо смотреть.
Как минимум не тормозит ли сеть
Если не подходит вариант pg_probackup а восстанавливать надо ежедневно то см. скрипт из публикации
pg_dump умеет пропускать таблицы
смотрите базопузомером размеры пропускаете то что не менялось/не нужно и ускоряете восстановление