Как настроить автоматическое резервное копирование PostgreSQL

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

Почему автоматизируют резервные копии PostgreSQL

Ручное резервное копирование работает до тех пор, пока его нет. Кто-то забывает, кто-то в отпуске, кто-то предполагает, что это сделал другой человек. Автоматизация устраняет эти режимы отказов.

Стоимость ручных процессов резервного копирования

В ручных процессах вводится изменчивость. Однажды ты запустишь резервную копию в 2 часа ночи, на следующей неделе в 18:00. Иногда вы сжимаете выход, иногда нет. Резервный сценарий живет на чьем-то ноутбуке вместо управления версиями. Когда наступает катастрофа, вы обнаруживаете, что последняя резервная копия была три недели назад, и никто не заметил.

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

Как выглядит хорошая автоматизация резервного копирования

Надежная автоматизация резервного копирования имеет несколько ключевых характеристик. Он работает без вмешательства после настройки. Он сохраняет резервные копии в местах, отличных от исходной базы данных. Это немедленно уведомляет вас о неудачах. И он поддерживает достаточно исторических резервных копий, чтобы восстановиться от проблем, которые вы обнаруживаете через несколько дней или недель.

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

Использование pg_dump с кроном

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

Основной сценарий pg_dump

Создайте резервный сценарий, который обрабатывает фактический процесс сброса:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
#!/bin/bash

TIMESTAMP=$(date +%Y%m%d_%H%M%S)
BACKUP_DIR="/var/backups/postgresql"
DATABASE="myapp_production"
BACKUP_FILE="${BACKUP_DIR}/${DATABASE}_${TIMESTAMP}.sql.gz"

# Create backup directory if it doesn't exist
mkdir -p "$BACKUP_DIR"

# Run pg_dump with compression
pg_dump -h localhost -U postgres -d "$DATABASE" | gzip > "$BACKUP_FILE"

# Check if backup succeeded
if [ $? -eq 0 ]; then
    echo "Backup completed: $BACKUP_FILE"
else
    echo "Backup failed!" >&2
    exit 1
fi

# Remove backups older than 7 days
find "$BACKUP_DIR" -name "*.sql.gz" -mtime +7 -delete

Сохранить это как /usr/local/bin/pg-backup.sh и сделать его исполняемым:

1
chmod +x /usr/local/bin/pg-backup.sh

Сценарий создает умноженные, сжатые резервные копии и автоматически удаляет старые. Сжатие gzip обычно уменьшает размер резервного копирования на 80-90% для типичных баз данных.

Настройка графиков крон

Чтобы запустить резервную копию в предпочтительное время. Редактировать кронтаб:

1
crontab -e

Добавить строку для ежедневных резервных копий в 3 часа ночи:

1
0 3 * * * /usr/local/bin/pg-backup.sh >> /var/log/pg-backup.log 2>&1

Для часовой резервации в рабочее время:

1
0 9-18 * * 1-5 /usr/local/bin/pg-backup.sh >> /var/log/pg-backup.log 2>&1

Перенаправление журнала захватывает как stdout, так и stderr, так что вы можете устранить ошибки.

Проверка подлинности

Избегайте ввода паролей в скрипты. Вместо этого используйте файл .pgpass:

1
2
echo "localhost:5432:myapp_production:postgres:yourpassword" >> ~/.pgpass
chmod 600 ~/.pgpass

PostgreSQL считывает учетные данные из этого файла автоматически, когда параметры подключения совпадают. Требуются строгие разрешения (600); PostgreSQL игнорирует файл, если другие могут его прочитать.

Кронные рабочие места работают по минимальному графику без полной настройки среды. Этот базовый подход работает, но вы хотите, чтобы мониторинг знал, когда резервные копии потерпят неудачу.

Добавление мониторинга и оповещения

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

Уведомления по электронной почте

Изменение сценария резервного копирования для отправки электронной почты по отказу:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

#!/bin/bash

TIMESTAMP=$(date +%Y%m%d_%H%M%S)
BACKUP_DIR="/var/backups/postgresql"
DATABASE="myapp_production"
BACKUP_FILE="${BACKUP_DIR}/${DATABASE}_${TIMESTAMP}.sql.gz"
ADMIN_EMAIL="admin@example.com"

mkdir -p "$BACKUP_DIR"

pg_dump -h localhost -U postgres -d "$DATABASE" | gzip > "$BACKUP_FILE"

if [ $? -eq 0 ]; then
    echo "Backup completed: $BACKUP_FILE"
else
    echo "PostgreSQL backup failed at $(date)" | mail -s "ALERT: Database backup failed" "$ADMIN_EMAIL"
    exit 1
fi

find "$BACKUP_DIR" -name "*.sql.gz" -mtime +7 -delete

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

Интеграция Webhook

Для командного чата уведомления, скрутите к веб-хук:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
send_notification() {
    local message="$1"
    local webhook_url="https://hooks.slack.com/services/YOUR/WEBHOOK/URL"

    curl -s -X POST -H 'Content-type: application/json' \
        --data "{\"text\":\"$message\"}" \
        "$webhook_url"
}

if [ $? -eq 0 ]; then
    send_notification "PostgreSQL backup completed: $DATABASE"
else
    send_notification "ALERT: PostgreSQL backup failed for $DATABASE"
    exit 1
fi

Замените URL-адрес веб-хука на конечную точку Slack, Discord или другую точку обслуживания. Большинство чат-платформ принимают этот базовый формат JSON.

Проверка целостности резервного копирования

Наличие резервного файла не означает, что он может быть использован. Добавить этапы проверки:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
# Check file size (should be at least some minimum)
MIN_SIZE=1000
FILE_SIZE=$(stat -f%z "$BACKUP_FILE" 2>/dev/null || stat -c%s "$BACKUP_FILE")

if [ "$FILE_SIZE" -lt "$MIN_SIZE" ]; then
    send_notification "WARNING: Backup file suspiciously small ($FILE_SIZE bytes)"
fi

# Verify gzip integrity
if ! gzip -t "$BACKUP_FILE" 2>/dev/null; then
    send_notification "ALERT: Backup file appears corrupted"
    exit 1
fi

Проверка размера ловит случаи, когда подключение к базе данных потерпело неудачу, но сценарий не ошибался должным образом. Тест gzip проверяет, что сжатие не повреждено.

Выбор частоты резервного копирования

Как часто вы возвращаетесь, зависит от того, сколько данных вы можете себе позволить потерять. Это цель вашей точки восстановления (RPO).

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

Сроки рассмотрения

Запланировать резервные копии во время периодов с низким трафиком. pg_dump читает базу данных последовательно, но все же генерирует нагрузку. Большая свалка в часы пик может замедлить ваше приложение.

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

Размер базы данных тоже имеет значение. База данных 100 ГБ может занять 30 минут. Если вы хотите почасовые резервные копии, вам нужно, чтобы этот процесс завершился в течение часа.

Тестирование процесса восстановления

Резервные копии, которые вы никогда не проверяли, - это предположения, а не гарантии. Регулярные восстанавливающие тесты ловят проблемы, прежде чем они имеют значение.

Восстановление этапов проверки

Создайте тестовую среду и периодически восстанавливайте:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
# Create a test database
createdb -h localhost -U postgres myapp_restore_test

# Restore the backup
gunzip -c /var/backups/postgresql/myapp_production_20260203_030000.sql.gz | \
    psql -h localhost -U postgres -d myapp_restore_test

# Run basic validation
psql -h localhost -U postgres -d myapp_restore_test -c "SELECT count(*) FROM users;"

# Clean up
dropdb -h localhost -U postgres myapp_restore_test

Автоматизировать это как еженедельную работу и предупреждать о неудачах. Резервное копирование, которое не может быть восстановлено, бесполезно.

Процедуры документирования восстановления

Запишите точные шаги для восстановления. Включить:

Где хранятся резервные копии (все места)
Как получить доступ к учетным данным
Команды по восстановлению
Ожидаемое время восстановления
К кому обратиться, если возникают проблемы

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

Обычные ошибки автоматизации

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

Хранение на том же диске

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

Никаких ограничений на удержание

Неограниченное резервное сохранение в конечном итоге заполняет ваше хранилище. Установить четкие правила хранения и контролировать использование диска.

Игнорирование срока резервного копирования

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

Твердые данные

Пароли в скриптах в конечном итоге в контроле версий, журналах и списках процессов. Используйте .pgpass файлы, переменные среды или управление секретами.

Пропущенные уведомления о сбоях

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

Завершение

Автоматизированные резервные копии PostgreSQL предотвращают потерю данных, которая повреждает бизнес и разрушает выходные дни. Начните с cron и pg_dump для простых настроек, добавьте мониторинг и удаленное хранение по мере роста ваших требований или используйте специальный инструмент, для обработки сложности. Какой бы подход вы ни выбрали, регулярно тестируйте свои восстановления. Стратегия резервного копирования так же хороша, как и ваша способность восстанавливаться от нее.

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

Почему автоматизируют резервные копии PostgreSQL#

Стоимость ручных процессов резервного копирования#

Как выглядит хорошая автоматизация резервного копирования#

Использование pg_dump с кроном#

Основной сценарий pg_dump#

Настройка графиков крон#

Проверка подлинности#

Добавление мониторинга и оповещения#

Уведомления по электронной почте#

Интеграция Webhook#

Проверка целостности резервного копирования#

Выбор частоты резервного копирования#

Сроки рассмотрения#

Тестирование процесса восстановления#

Восстановление этапов проверки#

Процедуры документирования восстановления#

Обычные ошибки автоматизации#

Хранение на том же диске#

Никаких ограничений на удержание#

Игнорирование срока резервного копирования#

Твердые данные#

Пропущенные уведомления о сбоях#

Завершение#