xander1983 Если коротко, то я уже давно внедрил PostgreSQL и горячую репликацию с помощью Barman, каждую ночь делается полный backup, далее в течение дня архивируются WAL, на след. день процесс повторяется.Вот этого не надо. Надо изложить последовательность действий в случае если в главном датацентре пожар, наводнение, землятрясение и т.д.
Как ты делал бакап неинтересно, интересно как будешь восстанавливаться.
Сколько времени будет потеряно (придется вводить снова) RPO
Сколько времени будешь восстанавливать RTO
https://www.enterprisestorageforum.com/storage-management/rpo-and-rto-understanding-the-differences.html

xander1983 Это понятно, но в моем случае я хочу чтобы весь процесс был повторяемым. Для меня или для того кто придет мне на смену. Вот и пропиши инструкцию: куда смотреть и что делать. В этом и суть вашего плана.
Потом надо будет провести "учебную тревогу"

xander1983 Еще хотел поинтересоваться у знающих людей, а вот например если тебе хакеры сломали сервер, получили доступ к ББДД и внесли изменения в данные, это считается как disaster или нет? А если это было обнаружено через, допустим, 24 часа после внесения изменений? Самое страшное это не хакеры, а вполне себе нормальные сотрудники, которые хотели как лучше, а получилось как всегда.
И ответ на этот вопрос (не кто виноват, а что делать) тоже будет в вашем документе: что будете предпринимать.

xander1983 Полагаю что в данном случае откатить все на 1ое число это не вариант, потому что теряется вся инфа загруженная 2го числа. Вручную все это исправлять -- возможно тоже не вариант из за объема. И как быть в этой ситуации лично для меня не очевидноДва момента:
во-первых это никак не DR (это хуже) и поэтому здесь это оффтопик.
во-вторых это не вам решать вариант или нет. Зовете пользователей, начальство, выкладываете варианты/риски/оценки по результатам совещания принимается решение. Вот его (решение) и выполняете.

xander1983 Ну то есть нету никаких "best practices" на этот счет? Уверен же что я не первый который может столкнуться с такой ситуацией.
Конечно нет. Тут ситуация выбора из двух зол, то есть потери будут в любом случае.

xander1983 а когда все сломаетсякогда все сломается вариант один - восстанавливать. И даже в этом случае надо уведомить начальство, получить формальное одобрение.

xander1983 но хочется же быть готовым к такой ситуации.изучайте свою базу и приложение (что откуда берется и куда затем деется). Тогда появляется вариант заскриптовать изменения сделаные пользователями второго числа после сбоя (давайте забудем про таинственных хакеров) при условии, что эти изменения не зависят от активности предыдущего дня.
Учитесь генерить скрипты. Уверен, что эти многомегабайтные скрипты softwarer не вручную набивал

вместо подготовки к неизвестным сбоям лучше запланируйте Учебную тревогу.
Уверяю, открытий чудных будет много.
Что толку в свежеподнятой базе если апп сервер остался в обесточенном ЦОД. А как он (апп сервер) узнает, что база уже на другом сервере (строка подключения, ДНС, актив директори). А какой нибудь файл сервер с шарой для "очень важного обмена данных" будет доступен?
Конечно это задача не для ДБА, а для начальника АйТи по конторе - отрисовать и протестировать все зависимости.
Еще веселей будет если проводить тесты будут не те кто писал инструкции.

Relic Hunter если ИТ инфраструктуре нужна высокая доступность, то её так и нужно проектировать изначально, с дублированием всех ресурсов.Хотел бы я быть таким же умным до, как моя жена потом.
И потом если бюджет позволяет, то почему дублировать. Одну реплику сделаем синхронной для HA, другую асинхронной с отложенной записью для DR.

xander1983 Коим я и являюсь.Ну тогда вам и карты в руки.
Проводите мысленный эксперимент: что-то случилось.
Что будете делать (порядок действий)
Сколько займет восстановление в самом лучшем случае
На какую дату восстановим в лучшем случае.

Если данные по оценкам RTO, RPO устраивают заказчика (бизнес), то все замечательно (осталось только протестировать план на предмет, а не слишком ли оптимистичные оценки).
Если не устраивают, то появляется бюджет в рамках которого можно что-то предпринимать (вплоть до того, чтобы переводить инфраструктуру в облака)

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