1С + postgres бэкап

Кстати, ты там выше писал, что pg_dump - фигня и это не бэкап.

И правильно там выше писали. Объясняли, почему, давали ссылки… это понятно?

1С в документации рекомендуют использовать pg_dump.

О да, ведь 1С, а особенно их документация, написана профессиональными DBA.

Напиши им, что они дураки и не умеют своей программы резервные копии делать.

Суть такова, что всякий, кто использует дампы для DR в нетривиальной ситуации – «дурак и не умеет делать резервные копии», вот и всё.

О да, ведь 90% баз 1С измеряется в Gb или в десятках Gb. И для подавляющего большинства пользователей 1С дамп с последующим восстановлением из него за 20-50 минут - это вполне себе резервное копирование.

Не в каждом предприятии DBA есть, не каждое предприятие испытывает в нём потребность.

Суть такова, что всякий кто громоздит отдельные сервисы там, где хватит 0 * * * * pg_dump bp | gzip > /home/backup/bg.sql.zip в кронтабе такой же дурак, как и тот, кто дампами кластер облачного saas 1C-провайдера «бэкапит». KISS

Добрый день. Спасибо, сам скрипт не использовал, но на его основе написал небольшой свой. Не знал, что великий срачь пробудил тут.

но на его основе написал небольшой свой

воть, так возможно лучше… зато точно понимаешь что и как работает… я свой скрипт пишу с 2017 года… так что возможно и твой будет развиваться

И для подавляющего большинства пользователей 1С дамп с последующим восстановлением из него за 20-50 минут - это вполне себе резервное копирование.

Ну так уже из серии «админов локалхоста». Что это за «предприятия», которым совершенно плевать что на потери данных, что на простои?

И backup при тех же услових «восстанавливался» бы где-то минуту, скорее всего.

всякий кто громоздит отдельные сервисы там

Какие ёще «сервисы»?!

Даже если потребности настолько скромные, то примерно так же легко настроить хоть pg_basebackup в cron (плюс архив WAL), а результат гораздо лучше.

Что это за «предприятия», которым совершенно плевать что на потери данных, что на простои?

Простои из-за того, что БП\ЗУП была недоступна час? Практически любое предприятие с численностью до 500 человек. А то, глядишь, и того больше.

pg_basebackup в cron (плюс архив WAL), а результат гораздо лучше.

Я ж не утверждаю, что pg_dump есть правильный способ бэкапить данные. Я спорю с тем, что одинэсника сферического «рога и копыта», состоящего из одного склада и трёх рабочих мест в торговом зале, можно называть дураком за то, что он свою КА за год на 500Мб вырастающую «бэкапит» через pg_dump. Он не DBA, и не обязан им быть. И директор тоже не дурак, если не хочет платить от 50 тысяч в месяц для того, чтобы в случае возможной поломки сервера не потерять один раз 100 тысяч.

«Заплатит» 100 тысяч раз в 3 года, потом ещё раз «заплатит» 100 тысяч за два простоя по одному часу, пока база из pg_dump восстанавливается. А так бы заплатил 3 600 000 (это если за 50К найдёт DBA нормального) + ещё полтора налогами. Кто тут дурак, кто ради 200 тысяч тратит пять миллионов, или тот кто оценив риски принимает допустимым простой кратковременный?

А когда речь идёт об условных Лентах и ДНСах, то там бюджет, опять же, не такой (есть возможность отдельного DBA нанять) и сферический одинэсник не будет спрашивать про «как бэкапить базу».

Простои из-за того, что БП\ЗУП была недоступна час?

Вопрос про потерю данных ты игнорируешь вполне успешно (как тебе кажется), да?

можно называть дураком за то, что он свою КА за год на 500Мб вырастающую «бэкапит» через pg_dump.

Опять-таки, альтернативный вариант и в этом случае лучше по всем показателям.

И почему тут надо терпеть альтернативно одарённых (я, если что, о тех, кто «впаривает» pg_dump «одинэсникам сферическим» вместо адекватных средств, как некоторые в этом треде)?

если не хочет платить от 50 тысяч в месяц для того

А это уже передёргивание. pg_basebackup (и ему подобные) настроить так же легко, если о них знать.

Кто тут дурак, кто ради 200 тысяч тратит пять миллионов, или тот кто оценив риски принимает допустимым простой кратковременный?

А что ты их «отмазываешь», используя взятые с потолка цифры и проблемы?