Как сделать бекап PostgreSQL на удалённое хранилище

Содержание

Надёжный бекап — это гарантия сохранности данных и уверенности в работе проекта. Рассказываем, как настроить резервное копирование PostgreSQL и выгрузку в облако без головной боли.

Потерять данные можно в любой момент — достаточно сбоя, ошибки в команде или внезапного падения сервера. Особенно если база развёрнута на VPS без предварительной настройки резервного копирования. Чтобы не рисковать, стоит заранее настроить бекап и отладить его отправку в облачное хранилище. В статье рассказали, как организовать резервное копирование PostgreSQL с автоматической загрузкой копий на Google Drive и Yandex Cloud. Пошагово разобрали установку утилит, шифрование и сжатие файлов, написание скрипта и настройку по расписанию через cron.

Аренда VPS/VDS от 219 руб/месяц

Преимущества VPS в AdminVPS:

✓ Бесплатное администрирование

✓ Только быстрые NVMe-диски

✓ Защита от DDoS-атак

✓ Быстрая техподдержка

Аренда VPS/VDS виртуального сервера от AdminVPS — это прозрачная и честная услуга с доступной ценой

Что понадобится для резервного копирования

Для регулярного бекапа PostgreSQL и отправки копий в облако потребуется несколько утилит. Основной инструмент — pg_dump. Он входит в пакет postgresql-client (для Debian/Ubuntu) или postgresql (для RHEL/CentOS) и отвечает за создание дампов.

Чтобы выгружать данные на внешние хранилища, понадобятся:

rclone или gdrive для отправки файлов в Google Drive;
awscli или s3cmd — для работы с Yandex Cloud по протоколу S3;
gnupg или openssl если планируете шифровать резервные копии;
gzip или tar для сжатия дампов перед отправкой.

На Ubuntu всё устанавливается командой:

sudo apt-get update
sudo apt-get install -y postgresql-client awscli rclone gnupg2 gzip cron

Для систем на базе RHEL используйте:

sudo yum install postgresql awscli rclone gnupg2 gzip cronie

Если выбрали rclone, настройте хранилище через команду rclone config. При подключении Google Drive достаточно выбрать тип drive и пройти шаги авторизации. Если используете gdrive, его нужно скачать вручную с GitHub, распаковать и установить. Первый запуск gdrive about откроет окно авторизации в браузере и сохранит OAuth-токен.

На VPS с root-доступом установка проходит быстрее — не нужно лишний раз вызывать sudo, а настройка cron и прав доступа упрощается. Если сервер работает на SSD, это дополнительно ускоряет архивирование и передачу копий. На VPS от AdminVPS root-доступ разрешён по умолчанию, что упрощает установку пакетов и настройку cron-скриптов. SSD-диски на таких серверах дают хорошую скорость чтения и записи, поэтому бекап и восстановление проходят быстрее.

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

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

Пример базовой команды для одной базы:

PGPASSWORD="пароль" pg_dump -U postgres -h localhost имя_базы > /var/backups/pgsql/dbname_$(date +%F_%T).sql

Если вы не хотите каждый раз прописывать пароль в командной строке, можно заранее настроить файл ~/.pgpass. В нём прописываются учётные данные для подключения. Не забудьте выставить права доступа 600, иначе PostgreSQL просто проигнорирует файл по соображениям безопасности.

Если планируете в дальнейшем восстанавливать базу через pg_restore, удобнее сразу использовать архивный формат:

PGPASSWORD="пароль" pg_dump -U postgres -Fc имя_базы > /var/backups/pgsql/dbname_$(date +%F_%T).backup

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

Автоматизация бекапа через скрипт и cron

Чтобы не запускать бекап вручную каждый день, проще один раз написать скрипт и доверить всё cron. Вот пример простого bash-скрипта:

#!/bin/bash

# Настройки
BACKUP_DIR="/var/backups/pgsql"
TIMESTAMP=$(date +%F-%H-%M)
PGDATABASE="mydb"
PGUSER="postgres"
PGPASSWORD="пароль"  # Рекомендуется задавать через переменные окружения, а не в теле скрипта

# Экспорт переменной для pg_dump
export PGPASSWORD

# Создание каталога, если его нет
mkdir -p "$BACKUP_DIR"

# Резервное копирование
BACKUP_FILE="${BACKUP_DIR}/${PGDATABASE}_${TIMESTAMP}.sql"
pg_dump -U "$PGUSER" "$PGDATABASE" > "$BACKUP_FILE"

# Проверка на успешность дампа
if [[ $? -eq 0 ]]; then
  gzip "$BACKUP_FILE"
else
  echo "Ошибка при создании дампа базы данных $PGDATABASE" >&2
  exit 1
fi

Что делает этот скрипт:

создаёт папку для хранения копий, если её ещё нет;
устанавливает текущую дату и время в качестве метки для имени файла;
задаёт параметры подключения к базе PostgreSQL (имя базы, пользователь, пароль);
экспортирует переменную PGPASSWORD, чтобы pg_dump мог подключиться без ввода пароля;
запускает pg_dump и сохраняет дамп в формате .sql;
проверяет успешность выполнения дампа;
если всё прошло успешно — сжимает файл в .gz, чтобы сэкономить место;
в случае ошибки выводит сообщение и завершает выполнение с кодом 1.

Сделайте файл исполняемым:

chmod +x /usr/local/bin/script.sh

А затем добавьте задачу в crontab, чтобы бекап выполнялся автоматически. Например, каждый день в 2:00:

0 2 * * * /usr/local/bin/script.sh

Это стандартное расписание для cron: запуск каждый день в 2:00 ночи. Разберём, что означает каждая часть:

0 — минута;
2 — час;
* — каждый день месяца;
* — каждый месяц;
* — каждый день недели.

Если нужно другое расписание, можно менять параметры:

30 23 * * * — запуск каждый день в 23:30;
0 4 * * 1 — каждую неделю по понедельникам в 4:00 утра;
*/15 * * * * — каждые 15 минут;
0 */6 * * * — раз в 6 часов.

Если скрипт не отрабатывает как положено, направьте его вывод в лог. Это поможет отследить ошибки. Удобно добавить логирование прямо в крон:

0 2 * * * /usr/local/bin/script.sh >> /var/log/pgsql_backup.log 2>&1

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

Отправка резервной копии в Google Drive

После того как база сохранена и архив готов, его можно автоматически выгружать в Google Drive. Для этого подойдут два проверенных инструмента: rclone и gdrive.

Если вы настроили rclone и создали подключение с именем gdrive, достаточно одной команды:

rclone copy /var/backups/pgsql gdrive:backup-folder

Она отправит весь каталог /var/backups/pgsql в папку backup-folder в вашем Google Drive. Если нужно загрузить конкретный файл, укажите его явно:

rclone copy /var/backups/pgsql/mydb_2025-05-17_02-00.sql.gz gdrive:backup-folder

Альтернатива — утилита gdrive. Она тоже умеет загружать файлы, но требует указать folder_id, который можно взять из URL вашей папки в Google Drive (всё, что после folders/):

gdrive upload --no-progress --parents <folder_id> /var/backups/pgsql/mydb_2025-05-17_02-00.sql.gz

При первом запуске gdrive проведёт вас через авторизацию: откроет ссылку в браузере, где нужно подтвердить доступ. После этого OAuth-токен сохранится на компьютере.

Токены для rclone и gdrive хранятся в ~/.config/rclone или ~/.gdrive. Убедитесь, что эти файлы доступны только владельцу и закрыты для других пользователей:

chmod 600 ~/.gdrive
chmod -R 600 ~/.config/rclone

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

Отправка резервной копии в «Яндекс Облако»

Для хранения бекапов за пределами сервера отлично подойдёт Yandex Cloud. Оно совместимо с S3-протоколом и хорошо работает с инструментом awscli, который легко подключается к хранилищу через специальную точку доступа.

Сначала установите awscli, если он ещё не установлен:

sudo apt install awscli

Затем в интерфейсе Yandex Cloud создайте сервисный аккаунт, назначьте ему роль storage.editor и выпустите статический ключ доступа. После этого выполните настройку:

aws configure

В ответах укажите:

Access Key ID и Secret Access Key из консоли;
регион — ru-central1;
формат вывода можно оставить по умолчанию (json или text).

Когда всё готово, загрузите файл с дампом в нужный бакет (облачную папку):

aws --endpoint-url=https://storage.yandexcloud.net s3 cp /var/backups/pgsql/mydb_2025-05-17_02-00.sql.gz s3://mybucket/pgsql-backups/

Параметр --endpoint-url=https://storage.yandexcloud.net нужен, чтобы awscli отправлял файл именно в Yandex Cloud.

Ключи по умолчанию сохраняются в ~/.aws/credentials, и к ним должен быть доступ только у вас. Проверьте права:

chmod 600 ~/.aws/credentials

Также не стоит использовать root-ключи учётной записи. Лучше создать отдельного сервисного пользователя с правами только на запись в конкретный бакет.

Как восстановить базу из резервной копии

Когда приходит время вернуть данные из бекапа, всё зависит от того, в каком формате был сделан дамп. Если это обычный SQL-файл, восстановление можно провести с помощью psql. А если копия была сделана в архивном формате (-Fc), подойдёт pg_restore.

Для SQL-формата действия такие:

createdb restore_db
psql restore_db < /var/backups/pgsql/mydb_2025-05-17_02-00.sql

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

Если дамп сделан в формате custom, используется команда:

createdb restore_db
pg_restore -U postgres -d restore_db /var/backups/pgsql/mydb_2025-05-17_02-00.backup

Пароль можно не вводить вручную каждый раз. Достаточно настроить файл ~/.pgpass с нужными данными и установить на него права доступа:

chmod 600 ~/.pgpass

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

Если нужно, можно восстановить только структуру базы без данных или наоборот только данные. Для этого у pg_restore есть параметры --schema-only и --data-only.

Безопасность бекапов: как защитить самое ценное

Бекап — это не просто копия. Это последний шанс восстановить систему, когда всё остальное уже сломалось. Поэтому к его защите стоит подходить не менее серьёзно, чем к самой базе.

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

gpg --symmetric --cipher-algo AES256 /var/backups/pgsql/mydb_2025-05-17_02-00.sql.gz

На выходе вы получите .gpg-файл, расшифровать который можно только зная пароль. Храните его отдельно и не передавайте никому.

Файлы с бекапами и любые чувствительные конфиги, такие как ключи, пароли, токены, должны быть доступны только администратору. Установите строгие права:

chmod 600 /var/backups/pgsql/*
chmod 600 ~/.pgpass ~/.config/rclone

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

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

Хранить десятки однотипных архивов за последние месяцы смысла нет. Лучше настроить ротацию, например, оставлять только последние 7 дней. Это можно автоматизировать с помощью скрипта или встроенных инструментов самого хранилища. Главное — не захламлять систему тем, что уже не пригодится.

Заключение

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

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

Читайте в блоге: