Перейти к основному содержимому

Резервное копирование и восстановление PostgreSQL

ОБЯЗАТЕЛЬНОДЛЯ НОВИЧКОВ
Разработчику Архитектору Инженеру

О чём эта глава — и о чём нет​

Здесь — резервное копирование и восстановление администратором — pg_dump, pg_basebackup, PITR, проверка, что бэкап действительно поднимается. Это ответ на вопрос "как вернуть базу после DROP TABLE, сгоревшего диска или ошибочной миграции".

Другая задача — автоматическое восстановление после обрыва питания при следующем старте сервера (redo/undo, WAL, checkpoint). Её разбираем в Восстановлении после сбоя. Обе темы опираются на один журнал WAL, но инструменты и сценарии разные: DBA восстанавливает копию, движок — согласованность после краша.

В managed-облаке снимки и PITR часто настраиваются в консоли — см. Администрирование БД в облаке.

Резервное копирование — общая теория​

Резервное копирование (бэкап, англ. backup) — процедура создания копии данных, размещённой отдельно от оригинала (другой носитель, другой ЦОД, облако). Резервная копия предотвращает безвозвратную потерю: повреждённые или удалённые данные восстанавливают из копии (полностью или с догоном журналов до точки во времени).

Типичные причины потери — отказ оборудования, сбой ПО, человеческий фактор, вредоносное ПО, стихийные и техногенные бедствия. Для организации важны и скорость возврата к работе, и объём допустимой потери данных — их формализуют как RTO и RPO (восстановление после сбоя, SLA в сопровождении).

Виды копирования при ротации​

ВидЧто попадает в копиюВосстановление
Полное (full)Вся БД или весь кластерОдин набор — база для быстрого restore "с нуля"
Дифференциальное (differential)Всё, изменённое с момента последнего полногоПолное + последний дифференциальный
Инкрементное (incremental)Изменения с момента последнего бэкапа (полного или инкрементного)Полное + цепочка всех инкрементов по порядку

Инкрементные копии компактнее, restore дольше и уязвимее к потере одного звена цепочки. Дифференциальные занимают больше места со временем, но restore проще. На уровне файловой системы те же идеи — в системном администрировании (rsync --link-dest, borg, restic).

Хранение и правило 3-2-1​

Копии держат на ленте, диске, в LAN, в облаке, на съёмных носителях — главное, чтобы часть копий пережила пожар, кражу или заражение основной площадки. Правило 3-2-1 (три копии, два типа носителей, одна вне площадки) — в основах ИБ.

Для PostgreSQL ниже — как эта теория ложится на pg_dump, pg_basebackup и архив WAL.

Классификация методов​

КритерийЛогическое копированиеФизическое копирование
УровеньОбъекты БД (таблицы, функции)Файлы кластера (страницы данных)
Утилитыpg_dump, pg_dumpallpg_basebackup, копия каталога данных
ВосстановлениеСовместимые мажорные версииТа же мажорная версия и ОС
РазмерМеньше (без "пустых" страниц)Больше
ГранулярностьОтдельная БД или объектыВесь кластер
Скорость restoreМедленнее (выполнение SQL)Быстрее (копирование файлов)

Данные нельзя "переписать заново" — без проверенных резервных копий потеря необратима. Резервная копия ценна только после тестового восстановления.

Логическое резервное копирование​

pg_dump​

Форматы — plain (SQL-скрипт), custom (-Fc, сжатие), directory (-Fd, параллельность), tar.

# Бинарный сжатый дамп одной базы
pg_dump -Fc -f backup.dump mydb

# Параллельный дамп в каталог (4 потока)
pg_dump -Fd -j 4 -f backup_dir mydb

# Только одна таблица
pg_dump -t public.products -Fc -f products.dump mydb

Просмотр содержимого без восстановления:

pg_restore -l backup.dump

Восстановление​

createdb mydb_restored
pg_restore -d mydb_restored backup.dump

После логического восстановления обновите статистику планировщика (pg_statistic в дамп не входит):

ANALYZE;

pg_dumpall​

Резервная копия всего кластера, включая роли и глобальные настройки:

pg_dumpall -f cluster.sql

Физическое копирование и PITR​

pg_basebackup​

Горячая копия каталога данных. Требует настройки WAL:

# postgresql.conf
wal_level = replica
archive_mode = on
archive_command = 'test ! -f /archive/%f && cp %p /archive/%f'
pg_basebackup -D /backup/base -Fp -Xs -P

Восстановление на точку во времени (PITR)​

  1. Восстановить физическую копию каталога данных.
  2. Создать postgresql.auto.conf / сигнал восстановления с параметрами:
restore_command = 'cp /archive/%f %p'
recovery_target_time = '2024-02-12 14:30:00'
recovery_target_action = 'promote'
  1. Запустить кластер в режиме восстановления до указанного момента.

Стратегия 3-2-1 и проверка​

  • 3 копии данных (рабочая + две резервные);
  • 2 типа носителей;
  • 1 копия вне площадки.

Проверка:

  • логический дамп: pg_restore -l backup.dump;
  • физическая копия: pg_controldata /path/to/data;
  • регулярное тестовое восстановление в изолированной среде (не реже раза в квартал).

Ограничения и риски​

Логическое:

  • не переносит статистику — нужен ANALYZE;
  • расширения из shared_preload_libraries ставятся вручную.

Физическое:

  • нельзя восстановить одну базу отдельно от кластера;
  • версия PostgreSQL и платформа должны совпадать.

Общее:

  • непротестированная процедура восстановления;
  • разрыв архива WAL;
  • повреждение файлов при передаче без контрольных сумм.

Практический минимум​

Код ITЗагрузка примера кода…

Контрольные вопросы​

  1. Когда выбрать pg_dump, а когда pg_basebackup?
  2. Почему после логического восстановления нужен ANALYZE?
  3. Что такое PITR и зачем архивировать WAL?
  4. Почему правило 3-2-1 не заменяет тестовое восстановление?

См. также​

Содержание