/report

@Wow4ick: Роман Жарков @confguru @Komzpa @pasha_golub @obartunov

> Почему же...

Да потому, что, например, "завтра" разработчики внедрят в production парочку mat.view, которые "с нуля" будут создаваться, допустим, час (вместо обычных 10 минут) — и "прощай, RTO".

> Имея приличный по размеру и скорости носитель информации вполне себе...

И при чём тут "приличный по размеру и скорости носитель" вообще, кстати?
У Вас где-то завалялся CPU бесконечной производительности (скорость света уже не предел)? ;)

А ведь он необходим, чтобы "ускорять" разворачивание дампов выше какого-то порога (даже если весь дамп уже "магически" лежит на RAM disk, например)!
Разворачивание дампа — это же ведь тупо исполнение SQL-запросов, не более того.
Т.е. это и parsing и planning, и особенно parsing данных copy, и уж тем более создание индексов и т.п. — всё это Вы никуда не "спрячете".

А вот у backup-ов всех этих дефектов нет в принципе — скопировал, запустил (выполнилось recovery) и СУБД снова работает.

> Я искренне не понимаю когда резеврную копию (разных разновидностей) обзывают разными словами

Потому что это — совершенно разные технологии (с разным предназначением), и называть их одним словом неправильно, Вам не кажется?

> и вокруг этого устраивают холивары

Да при чём тут "холивары"?!
Это вопрос применения инструментов по назначению (и компетентности применяющих), вот и всё.

Привет. Тут есть опытные по sql?Нужна помощь для написания sql запроса.

Да пофиг на это время восстановления. Вы только из-за него каждый Божий день свою картинку с бетменом шлете?
Если мы достали из шкафа ночную копию, то у нас уже большие проблемы, потому что мы все данные за день потеряли.

Да при том что есть всего лишь 2 вида копий: логические (выполняются средствами/операторами среды) и физические в каждой возможно наличие подвидов, в зависимости от области...
Все остальное имеет смысл сравнивать только в контексте задачи и граничных условий...

> Да пофиг на это время восстановления.

Нет, не "пофиг", разумеется, о чём Вы?!
RTO — это про невозможность (или существенное ограничение) работы [какой-то части] бизнеса в то время, когда база данных отсутствует.
И всё это время теряются деньги (т.е. теряется доход и/или репутация, или впустую происходят или "взлетают" расходы и т.п.).
А первоочередная задача production DBA — этого не допустить.
Т.е. их для этого, в первую очередь, нанимают (и терпят, допустим, 60000$ / год расходов на каждого из этих бездельников ;) ).

> Вы только из-за него каждый Божий день свою картинку с бетменом шлете?

Нет, не каждый (и картинка эта не моя, а @vkukharik, кстати), не передёргивайте.

> Если мы достали из шкафа ночную копию, то у нас уже большие проблемы, потому что мы все данные за день потеряли.

А вот это уже называется RPO. И к нему относится примерно всё вышеописанное, только причины убытков несколько другие.

Дайте людям возможность сделать ошибку. И получить свой личный опыт.

Бу-бу-бу, продукшон деньги айпио.
Какое отношение это имеет к несчастным скриптомакакам, которые сюда приходят спросить про то, какие кнопки нажимать, чтобы в постгрес залогинило?

> Да при том что есть всего лишь 2 вида копий: логические (выполняются средствами/операторами среды)
и физические в каждой возможно наличие подвидов, в зависимости от области...

Хмм... а откуда эти "определения"?
Потому что в PostgreSQL, например, как дампы, так и backup-ы выполняются "средствами среды" (если таковой считать и утилиты, входящие в комплект).

> Все остальное имеет смысл сравнивать только в контексте задачи и граничных условий...

Ну так про контекст-то тут и речь. Одно — средство для DR, другое — нет.

И дамп, опять-таки — не копия, а подробная инструкция для создания приблизительной копии. ;)

А почему эти люди должны иметь возможность свободно забивать головы читающим это новичкам всякой чушью?
Я лично считаю, что всё это отстой только вредит сообществу PostgreSQL. ;)

Вон, вчера я посоветовал сделать pg_dump человеку, у которого в серванте на хецнере за $80 в месяц место закончилось. Расскажите ему про методы продукшон дибиэйев и про то, что pg_dump — не бекап.

А то я такой урон сообществу этим советом нанес, не дай Бог.

"Ворчали старики..."

Свой опыт (пусть и горький) на той и свой - запоминается лучше.

Ого, сегодня весело в группе🤦‍♀️

Ярослав, ваша позиция понятна и логична.

Однако есть 2 нюанса:
- вы раз за разом утверждаете, что pg_dump* это не бэкап, хотя это противоречит официальной документации: https://www.postgresql.org/docs/current/backup.html
 тут требуется как минимум объяснить, почему оно так.
- эмоциональный фон ваших утверждений крайне агрессивен, это также вредит сообществу PostgreSQL.

> отношение это имеет к несчастным скриптомакакам

Это надо в азбуку поместить, под буквой "У" — "Уважение к коллегам". ;)

> какие кнопки нажимать, чтобы в постгрес залогинило?

А мы-то все со знанием postgres родились, да?

Да и вообще, какого почему "новичков" именно в PostgreSQL кто-то считает новичками (а то и кем похуже) в IT вообще?!
Они вполне могут быть прекрасными программистами [баз данных], просто эту ещё не видели.

Проклянет то он в конце концов вас )

Я ему посоветовал сделать хоть какой-то бекап перед тем, как он полезет своими кривыми руками ломать всю базу.