Учения по восстановлению Postgres: три ошибки, которые нашлись только на практике

14 августа 2026

Копии снимались полтора года и ни разу не разворачивались целиком. Выделил субботу, поднял пустую виртуалку и попробовал восстановить продовую базу с нуля. Ни один из трёх сюрпризов не был виден по логам бэкапа — все они рапортовали «успешно».

1. Дамп был, роли не было

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

pg_dumpall --globals-only > globals.sql
test -s globals.sql

2. Пароль от репозитория копий лежал только на том сервере, который восстанавливаем

Классическая петля. Ключ доступа к хранилищу хранился в переменных окружения на той же машине, чей диск мы и потеряли в сценарии учений. Теперь копия ключа лежит офлайн, и проверка «умею ли я вообще открыть репозиторий с чужой машины» — первый шаг учений, а не последний.

3. Восстановление занимает не то время, которое я называл

В голове было «минут двадцать». По факту — час сорок: почти всё съели распаковка и построение индексов на слабом диске. Если бы это была авария, я бы полтора часа обещал людям «вот-вот поднимется». Теперь в заметке лежит честная цифра, измеренная секундомером.

Что изменилось в расписании

Раз в квартал — полное восстановление на отдельную виртуалку и сверка числа строк в трёх крупнейших таблицах. Раз в месяц — дешёвая проверка целостности репозитория. Учения занимают полдня, но это единственный способ узнать, что копии настоящие.