Никто не ставит под сомнение, что бекапы СУБД должны быть. Postgresql Postgresq Pro или MS SQL - бекапы быть должны.
Не смотря на то, что некоторые руководители компаний, имеющие в своем составе it инфраструктуру при слове LINUX начинают сильно нервничать, от Linuxа никуда не деться. Новости, которые уже не новости сообщают: "Самая знаменитая Российская СУБД прекращает поддерживать Windows". В качестве альтернативы Microsoft Windows в России широко внедряется Astra Linux, прошедшая сертификацию СЗИ ФСТЭК России по первому, высочайшему, уровню доверия.
Исходные данные:
Настройка логирования 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
Решение проблемы: добавление пользователя 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/*"
Вижу картину без обратной связи:
Проблему по выводу логов наблюдаем? Нет! А она есть! Что наблюдаем: зависший процесс на 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
При применении параметров есть особенность: перегружать сервер не требуется. Достаточно открыть новую сессию.
Повторный запуск basebackup:
100% успеха!!!