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

Question

Accepted Answer

PostgreSQL предлагает несколько методов **резервного копирования** — логические резервные копии (`pg_dump`) и физические резервные копии (базовая резервная копия + WAL для **восстановления на определённый момент времени**). Надёжная стратегия резервного копирования и восстановления необходима для защиты от потери данных, и критически важно, что **резервные копии должны быть протестированы**.

## Логические резервные копии — pg_dump

```bash
# pg_dump — dumps a database as SQL (or a custom archive) — portable, flexible
pg_dump -U user -d mydb -F c -f backup.dump      # custom format (compressed, flexible restore)
pg_dump -U user -d mydb > backup.sql              # plain SQL
pg_dumpall > all.sql                              # ALL databases + roles

# restore
pg_restore -U user -d mydb backup.dump            # from custom format
psql -U user -d mydb -f backup.sql                # from plain SQL
```

`pg_dump` создаёт логическую резервную копию (SQL или архив) базы данных — портативную (восстанавливаемую на разные версии/серверы), хорошую для небольших баз данных, миграций и выборочного резервного копирования. Но это снимок на определённый момент времени (без непрерывного восстановления).

## Физические резервные копии + восстановление на определённый момент времени (PITR)

```text
For larger/critical databases: a BASE BACKUP (a copy of the data files) + continuous
archiving of the WAL (write-ahead log) → enables POINT-IN-TIME RECOVERY:
  ✓ Restore the base backup, then REPLAY WAL up to ANY point in time
  ✓ Recover to JUST BEFORE a disaster (e.g. an accidental DROP TABLE at 2:47pm)
→ Tools: pg_basebackup, WAL archiving, and tools like pgBackRest / Barman automate this.
```

**PITR** мощный инструмент: непрерывно архивируя WAL, вы можете восстановиться на любой момент — не только к последней резервной копии — что критически важно для минимизации потери данных при бедствиях.

## Основные элементы стратегии резервного копирования

```text
✓ Regular, AUTOMATED backups (scheduled, not manual/forgotten)
✓ Store backups OFF the database server (and offsite / cloud) — survive hardware failure
✓ Retention policy (keep daily/weekly/monthly as needed)
✓ Combine: periodic base backups + continuous WAL for PITR (critical data)
✓ Backups from a REPLICA to avoid loading the primary
```

## Самое важное правило: ПРОТЕСТИРУЙТЕ ваши резервные копии

```text
⚠️ A backup you've never restored is NOT a reliable backup.
UNTESTED backups fail when you need them most (corrupt, incomplete, wrong process).
→ Regularly TEST restores to verify they actually work and you know the procedure.
```

## Почему это важно

Резервное копирование и восстановление — это **критическое** знание для ответственного управления PostgreSQL — защита от потери данных (из-за отказа оборудования, повреждения, случайного удаления, бедствий) — одна из наиболее важных ответственностей для любой production базы данных, поэтому понимание стратегий резервного копирования необходимо для знаний senior-уровня.

Понимание методов необходимо: **`pg_dump`** (логические резервные копии — портативные SQL/архивные дампы, хорошие для небольших баз данных, миграций и выборочного/кросс-версионного резервного копирования, но только снимки на определённый момент времени) и **физические резервные копии с восстановлением на определённый момент времени (PITR)** (базовая резервная копия + непрерывная архивизация WAL, позволяющая восстановиться на *любой* момент — что мощно для минимизации потери данных, как восстановление прямо перед случайным `DROP TABLE`, критически важно для критических данных).

Знание **основных элементов стратегии** (регулярное автоматизированное резервное копирование, их хранение вне сервера и offsite, политики хранения, объединение базовых резервных копий с WAL для PITR на критических данных, резервное копирование с реплик) — важное операционное знание.

Самое критическое — понимание того, что **резервные копии должны быть протестированы** — непротестированная резервная копия ненадежна и часто не работает именно тогда, когда она нужна (повреждение, неполные данные, незнакомый процесс восстановления) — это жизненно важный, часто игнорируемый принцип: регулярное тестирование восстановлений — это то, что делает стратегию резервного копирования действительно надежной.

Поскольку потеря данных может быть катастрофической (а восстановление возможно только с рабочими резервными копиями), и поскольку надлежащая стратегия (подходящие методы резервного копирования, PITR для минимальной потери, offsite хранение, и критически *протестированные* восстановления) — это то, что защищает данные организации, понимание резервного копирования и восстановления PostgreSQL — это критическое знание senior-уровня для ответственного управления базой данных — высокорисковая ответственность, где разница между протестированной стратегией и непротестированной может быть разницей между восстановлением после бедствия и постоянной потерей данных, делая это необходимым, часто релевантным топиком для любого, кто управляет production базами данных.