> Это как раз тот самый метод про смекалку и кашу из топора.
> Вы восстанавливаете полностью кластер на другой путь [НЕ БАЗУ, весь кластер, просто
> остальные базы при этом восстановлении имеют нулевой размер], и потом каким-то
> хитрым образом "загружаете"...
> Через дамп поди ? :)
> Смекалка и каша из топора.... pg_dump ... | psql ...
Но всё достаточно легко заворачивается в скрипт и работает не чавкая.
> Знаете, после нормальных СУБД - это выглядит как откат в каменный век...
Какие СУБД вы называете нормальными? Оракл, вероятно. Немного сталкивался и лично у меня тоже не мало вопросов к нему (правда там я вообще без понятия, как бэкапы строятся (ну кроме таких же дампов).
Мне энтерпрайзности Оракла хватило, когда кластер без ДБА жить практически не умеет: постоянно надо что-то делать, чтобы работало и не падало (работал с "Борлас" со стороны заказчика). Одноузловая СУБД - работает не плохо. Кластер - нахер надо сопровождать.
У нас на Слонике БД крутятся с минимумом управляющих воздействий. В основном для профилактики и при обновлениях прикладного ПО, для контроля.
> вместо решения задачи- вам приходится решать ТЕХНИЧЕСКИЕ УСЛОВНОСТИ. Вместо бэкапа- вы
> делаете последователность странных действий. Когдато это было интересно, но потом такие
> действия в нормальных базах стали частью скрытой от администратора логики, ввиду
> абсолютной рутинности и бессмысленности ручного управления ею...
А в чём проблема? Берите централизованную систему резервного копирования, которая будет делать всю рутинную работу. И уж в энтерпрайзе централизованная СРК должна быть, верно?
Вообще-то делать бэкапы прода и пару сотен ТБ - это настолько на крайний случай, о которых в кошмарах вспоминают. А для оперативного резервирования - многоузловой кластер, который и с балансировкой и с горячим резервированием поможет.
Ну и лицензия PostgresPro тоже поможет снять многие проблемы, если что.
