Найти тему
POSTGRESQL

Postgres Pro на Astra Linux. Обход подводного камня при создании бекапов.

Никто не ставит под сомнение, что бекапы СУБД должны быть. Postgresql Postgresq Pro или MS SQL - бекапы быть должны.

Не смотря на то, что некоторые руководители компаний, имеющие в своем составе it инфраструктуру при слове LINUX начинают сильно нервничать, от Linuxа никуда не деться. Новости, которые уже не новости сообщают: "Самая знаменитая Российская СУБД прекращает поддерживать Windows". В качестве альтернативы Microsoft Windows в России широко внедряется Astra Linux, прошедшая сертификацию СЗИ ФСТЭК России по первому, высочайшему, уровню доверия.
Исходные данные:

Тип ОС
Тип ОС
Версия Postgres Pro
Версия Postgres Pro
Директории для инициализации кластера
Директории для инициализации кластера

Настройка логирования Postgresql

mcedit /data/pg_data/postgresql.auto.conf
log_directory = '/log/pg_log'
log_line_prefix = '%m [%p] %u@%d/%a'

Создаю скрипт для basebackup через crontab:

postgres@astra:~$ vim /postgres/scripts/basebackup.sh
postgres@astra:~$ chmod 0770 /postgres/scripts/basebackup.sh
postgres@astra:~$ chmod +x /postgres/scripts/basebackup.sh

Создаю задание в планировщике для basebackup.sh :
# Бекап:
0 21 * * * /postgres/scripts/basebackup.sh
Не рабочий crontab
Не рабочий crontab

Решение проблемы: добавление пользователя postgres в группу crontab:

sudo usermod -a -G crontab postgres

Проведу тестовый запуск basebackup.sh с наблюдением за процессом:

/postgres/scripts/basebackup.sh
watch -n 1 "ps ax | grep basebackup | grep -v grep; tail -n 20 /postgres/scripts/basebackup.log; df /data; df -h /data; du -s /backup/*"

Вижу картину без обратной связи:

Нет ответа от скрипта basebackup.sh
Нет ответа от скрипта basebackup.sh
Наблюдаю зависший процесс basebackup
Наблюдаю зависший процесс basebackup
Остановка создания basebackup на 89%
Остановка создания basebackup на 89%
Log-файл basebackup
Log-файл basebackup
Log-файл postgresql
Log-файл postgresql

Проблему по выводу логов наблюдаем? Нет! А она есть! Что наблюдаем: зависший процесс на 89% и тишину в логах.
Где же зарыта собака???

Если обратиться к документации и настройкам basebackup, то должна создаться базовая резервная копия в едином архиве и архив wal-файлов. Из лога basebackup видно, что пока базовая резервная копия не достигла 89% своего размера все шло нормально. Далее работа процесса прекращается.
Вопрос: что остановило процесс???
На самом деле все просто. Видно, что когда размер файла basebackup доходит до определенного размера процесс останавливается. Логично напрашивается вывод, что стоит блокировка на размер создаваемых файлов. Просмотреть блокировки можно из-под УЗ postgres через команду:

ulimit -a

Обращаем внимание на параметр file size 2500000

Ограничения на работу с файлами
Ограничения на работу с файлами

Собака зарыта в параметр file size!!!

Снимаем ограничения на размер файла для УЗ postgres из-под root:

vim /etc/security/limits.conf

Вносим в конце 2 строчки:

postgres hard fsize unlimited
postgres soft fsize unlimited
Для УЗ postgres fsize = unlimited
Для УЗ postgres fsize = unlimited

При применении параметров есть особенность: перегружать сервер не требуется. Достаточно открыть новую сессию.

Повторный запуск basebackup:

-12

100% успеха!!!