1С + postgres бэкап

Привет

Есть решение

https://gist.github.com/andy-1983/91b7d0e21574468fb3ff3d9a6775f195

Это мой скрипт для архивации баз постгрес. Список архивируемых баз стоится динамически и бекапятся все базы кроме баз заканчивающихся на _bak*.

Начни архивацию с параметром weekly, и продолжай с параметром daily.

weekly делает полный архив, а daily – разностный.

Если хочешь, скину свое расписание архивации, для наглядности понимания.

По завершении архивации приходят уведомления в телеграмм

Там же чуть ниже сценарий восстановления архивов.

Только сейчас понимаю, что чтобы объяснить как все работает придется написать не одну страницу текста, но ты можешь посмотреть код и разобраться, если что спрашивай.

в каком дистрибутиве у тебя стоит постгри?

На centos 8. PostgreSQL Pro 12. Пока разбираю скрипт. Надеюсь, что-нибудь получится. Как понял он получает списко БД, записывает в переменную и затем из переменной делает бэкап БД из списка?

Он строит список баз, запрашивая его в кластере, тут ничего делать не нужно.

Нужно установить пакеты q, rdiff, pwgen, curl

q в пакете python2-q-text-as-data

Есть решение

Это не решение, это идиотизм. Того, кто использует pg_dump для backup-ов, нужно гнать в шею (если он выдаёт себя за DBA – и из профессии тоже).

Начни архивацию с параметром weekly, и продолжай с параметром daily.

«Шито ви сказали?! Business continuity? RTO? RPO? Не, не слышал.»

В общем, «dump is not a backup!».

Использовать нужно нормальные решения – pgBackRest, barman, pg_probackup, на худой конец pg_basebackup.

А что, бэкап средствами 1С не рассматривался? )

Ты хоть знаешь о чем говоришь? )))

Бэкаплю базы с постгреса 1С'ом. По расписанию. Полёт нормальный.

меня уже давно выгнали из DBA

Совершенно правильно сделали.

я своему коду больше доверяю,

Жаль только, что задачу disaster recovery он не решает. И создан исключительно исходя из полной безграмотности в основах профессии DBA.

что делают твои модные средства архивации чего не делаем мой сценарий

Решают эту задачу, в отличие от твоей игрушки.

А если кто то не выйдет из сеанса?

Решают эту задачу, в отличие от твоей игрушки.

скажи какую задачу не решает мой скрипт, или не пацан…

Он блокирует базу. Сама 1С рекомендует использовать средства СУБД. К тому же иногда бывает, что DT не загружается обратно (легендарная «Ошибка формата потока»). В общем, именно как бэкап оно не идеально. Как один из бэкапов - нормально, если есть возможность надолго блокировать базу.

Значит бэкапить нельзя.

Ну собственно бэкап постгреса тоже есть, но это на крайний случай. С 1С'ными пока проблем не было. Запускается по ночам.

не учи людей плохому, бекапы надо делать средствами СУБД

Жаль только, что задачу disaster recovery он не решает.

для такого случая я раз в неделю делаю pg_basebackup и архивирую WAL сегменты, у меня все сделано

задачу disaster recovery он не решает

1С + postgres бэкап (комментарий)

ему и не надо, для 1с востребована задача вести оперативный архив

Не затруднит на пальцах объяснить или дать ссылку, где для не-DBA объясняются кейсы, в которых pg_dump не подходит? Лично мне его достаточно: дамп содержит в точности то состояние базы, которое было на момент запуска, да и запускается когда никто из живых людей не работает. Но рассмотреть другие инструменты не против, особенно если они хорошо решают вопрос инкрементального бэкапа (сейчас полный дамп загружается в borgbackup, что в принципе работает неплохо).

Но ты, тем не менее, запросто советуешь эту муру «вместо того», когда спрашивают про backup.

Ок, это недостаток документации моего проекта, но не его самого…

если человек шаолинь, то это надолго

ты еще не сделал доклад по проблемам pg_dump для архивации, а продолжаешь портить экологию )))

дать ссылку, где для не-DBA объясняются кейсы, в которых pg_dump не подходит?

Тут дело не только в «кейсах», а в принципе. См. http://docs.pgbarman.org/release/2.12/#introduction

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

Backup – это не цель, а только средство, вот что нужно понимать.

Поэтому как-то чего-то когда-то «копировать» – это чистой воды шаманство, и задачу обеспечения business continuity может решить только «случайно», если повезёт.

К примеру: пусть RTO = 1 час, случилось неважно какое «бедствие» (disaster), базу нужно восстанавливать – а дамп восстанавливается десять часов.

Так вот умницу «DBA», который это устроил, нужно гнать в шею, потому что его стараниями организация получила 9 лишних часов простоя, и понесла, чаще всего, многие 1000$ прямых и косвенных потерь.

Но рассмотреть другие инструменты не против,

Лучше пересмотреть своё понимание задачи в целом.

бекапы надо делать средствами

приложений.

К примеру: пусть RTO = 1 час, случилось неважно какое «бедствие» (disaster), базу нужно восстанавливать – а дамп восстанавливается десять часов.

мы сейчас говорим не о Ъ базах каких ни будь АСУТП или еще чего с тысячей точек автоматизированного ввода, а про быдло-1С у меня самая жирная база весит без сжатия 4,5 гига, и ресторится она 20 минут.

Кластер в 140 гигов я восстанавливал за 3 часа.

админы локалхостов могут делать бекапы даже на дискеты, никому нет дела

RTO

Да, уже погулил. У меня этот параметр известен, устраивает. Особых требований здесь нет, это не офигеть какой энтерпрайз. Собственно, лично мне хотелось бы PiTR в нормальном виде (pg_dump иногда здорово просаживает производительность, так что запускается даже не каждый час), а RTO до лампочки - в худшем случае это минут сорок на самой большой базе, и мы это проходили.

Лучше пересмотреть своё понимание задачи в целом.

Расскажи, что не так с моим пониманием задачи, которую я же и ставлю? %)

Это как? Выгоняешь всех скриптами из конфигураторов и т.д.? Потом получаешь кучу архивных баз 1С, которые даже не дедуплицировать?

Никого не выгоняю, если кто не вышел, сам виноват )
Базы хранятся каждодневно за месяц, ну и где-то с полгода по одной в месяц. Объём заметен, но не особо напрягает.

Ну если базы не большие, проблем нет.

У меня этот параметр известен, устраивает.

А другие из указанных параметров не волнуют?

И да – пока устраивает. Проблема дампов не только в том, что они восстанавливаются долго. Основная проблема в том, что в общем случае невозможно предсказать, сколько они будут восстанавливаться (особенно после очередного изменения структруры базы).

Особых требований здесь нет, это не офигеть какой энтерпрайз.

Как уже кто-то написал выше, «админы локалхостов могут делать бекапы даже на дискеты, никому нет дела».

Т.е. дома можешь использовать любые «игрушки», а на работе таким заниматься (выдавая себя за DBA) не нужно.

Расскажи, что не так с моим пониманием задачи, которую я же и ставлю?

Вот именно в этом. Ставить эту задачу (определять целевые RTO и RPO) должен «бизнес», а не ты.

определять целевые RTO и RPO

хорошо, у нас эти показатели в норме, далее? я уже 100 раз пытался выяснить что мне дадут все эти модные штуки? все они работают с кластером целиком, а у нас на трех кластерах 450 баз, это такая особенность наша. Бывает необходимость найти подходящий архив, и я восстанавливаю 3-4 подряд, пока бухи скажут что «все ок». поэтому бекап кластера только на случай катастрофы.

Основная проблема в том, что в общем случае невозможно предсказать, сколько они будут восстанавливаться

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

disaster

если на этот случай… то лучше всего поднимать slave данных, все архивации получаются просто оперативным вариантом. не так ли?

А другие из указанных параметров не волнуют?

Повторюсь: из фич, которые предоставляют более продвинутые инструменты, меня привлекает только нормальное PiTR, остальное в условиях маленькой компании это nice to have.

Основная проблема в том, что в общем случае невозможно предсказать, сколько они будут восстанавливаться (особенно после очередного изменения структруры базы).

Да, это я понял. У нас несколько баз в одном кластере (плохо, да), но основная и самая большая одна, и типичное время восстановления дампа годами держится на уровне 40 минут плюс-минус. И обычно это восстановление в новую базу для тестов, с рабочей такое случается крайне редко.

выдавая себя за DBA

Даже не пытался, я вообще разработчик. Просто «так получилось».

Ставить эту задачу (определять целевые RTO и RPO) должен «бизнес», а не ты.

«Бизнес» решил, что ему и день нормально будет работать без сервера 1С/PostgreSQL. Любые коррекции в лучшую сторону - это уже моё творчество.

хорошо, у нас эти показатели в норме, далее?

В чьей «норме»? И вообще, поконкретнее – какие они у вас и почему?

я уже 100 раз пытался выяснить что мне дадут все эти модные штуки?

Гарантии вместо надежд они дают (отвечаю в очередной раз)! И это не считая других преимуществ.

все они работают с кластером целиком, а у нас на трех кластерах 450 баз, это такая особенность наша.

Да, работают. А у тебя как-то не весь кластер бьётся, когда «летит» железо? Или это у вас там основной disaster – это кривые руки пользователей?

Бывает необходимость найти подходящий архив, и я восстанавливаю 3-4 подряд

Какая продуктивная деятельность! А если «подходящего» дампа вдруг нет, то они всё (кривыми) ручками заново вводят, да?

поэтому бекап кластера только на случай катастрофы.

А вышеописанное – это у вас повседневность?

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

Во-первых, не все (точнее, это не единственный способ, который они могут использовать).

что предоставлены родными средствами постгреса.

Во-вторых, уж не дампы.

если на этот случай… то лучше всего поднимать slave данных,

И как это поможет от вашей, я так понял, повседневной практики уничтожения данных пользователями?

не так ли?

Только отчасти, см. выше.

Повторюсь: из фич,

Причём тут «фичи»?! Т.е. потерять, к примеру, день (или сколько там?) работы организации целиком там у вас нормально?

меня привлекает только нормальное PiTR,

Да, кого волнует, сколько придётся «курить» и «перезабивать данные» – потерпят, не сахарные.

остальное в условиях маленькой компании это nice to have.

ORLY? Perhaps, someone lied told them that it’s hard or too expensive to do better?

типичное время восстановления дампа годами держится на уровне 40 минут плюс-минус.

Да, бывают тривиальные случаи (плюс везение).

«Бизнес» решил, что ему и день нормально будет работать без сервера 1С/PostgreSQL.

Вот это «бизнес»! Nice to have it.

Даже не пытался, я вообще разработчик. Просто «так получилось».

Та же фигня была. Сделал скриптик на баше с pgdump-ом и всё.
Инструмент должен соответствовать задаче.

Насчёт хранения бекапов ещё важный момент - их нужно перекидывать (сразу или чуть позже) на другой сервер/носитель, иначе неисправный БП в серваке может унести в могилу все винты вместе с бекапами.
Ну и человеческий фактор к тому же...

Да, кривые руки пользователей это основная причина восстанавливать архивы, все остальное повседневность

Это пока у тебя база маленькая. В один прекрасный момент тебе платформа скажет «не все данные были выгружены» и сформирует корректный .dt из которого базу ты развернуть сможешь. Но каких данных в нём не будет - вот это будет сюрприз.

Кстати, ты там выше писал, что pg_dump - фигня и это не бэкап. 1С в документации рекомендуют использовать pg_dump. Напиши им, что они дураки и не умеют своей программы резервные копии делать.

да и запускается когда никто из живых людей не работает

Это без разницы. pg_dump выдаст состояние БД на момент запуска утилиты. Пользователи если и почувствуют некую просадку в производители, то не сильно.

pg_dump выдаст состояние БД на момент запуска утилиты.

Это я упоминал.

Это без разницы.

Не совсем. Документ пополам не порвёт, конечно, но когда работают люди есть вероятность захватить лишь часть некой цельной по смыслу операции. С регламентными заданиями это не так актуально, они обычно проектируются с учётом возможных прерываний и как бы слегка идемпотентны. Но у нас тут не как у шульмана, восстановление рабочей базы - огромная редкость, да и чаще оно плановое.

В контексте 1С (уточню на всякий случай, а то там выше про дизастеры и восстановление бд по 9 часов пишут - кто вообще в 1с ведёт оперативный учёт в БД размером в сотни ГБ?) это не так критично.

«Проводки» которые создают документы, она выполняет в транзакции. Не попадёт в дамп не только документ который пользователь начал создавать в момент запуска утилиты, но и тот который он только нажал сохранить - не беда, это просто нужно учитывать.

А если не в транзакции - вопрос к конфигурастам, которые это наконфигурировали.

В контексте 1С (уточню на всякий случай, а то там выше про дизастеры и восстановление бд по 9 часов пишут - кто вообще в 1с ведёт оперативный учёт в БД размером в сотни ГБ?) это не так критично.

«Проводки» которые создают документы, она выполняет в транзакции. Не попадёт в дамп не только документ который пользователь начал создавать в момент запуска утилиты, но и тот который он только нажал сохранить - не беда, это просто нужно учитывать.

Спасиб, я именно разработкой для 1С и занимаюсь, так что в курсе :)

А если не в транзакции - вопрос к конфигурастам, которые это наконфигурировали.

С таким сталкивался как-то, это было в старой типовой конфигурации. Но я другое имел в виду: когда, например, ведётся работа со связанными документами. Впрочем, в случае серьёзной котострофы (c) пользователь вряд ли огорчится, что ему пришлось снова поправить тот же документ.

Но я другое имел в виду: когда, например, ведётся работа со связанными документами.

О.о пробовал в типовых свежих релизах «сломать» базу тем, что кучу документов\объектов одним вызовом правил - платформа матюгнулась и всю пачку изменений не сохранила. Но я не 1Сник, могу и не знать как сделать правильно, чтобы оно сломалось :)

Я о простой последовательной работе. Типа дозаполнить реквизит или поменять количество в нескольких разных, но связанных документах (подчинённых, если так понятнее). Тут не идёт речи о технических нюансах. То есть условный вася поправил три документа, бэкап был снят между вторым и третьими, а потом сдох диск :)

пробовал в типовых свежих релизах «сломать» базу тем, что кучу документов\объектов одним вызовом правил - платформа матюгнулась и всю пачку изменений не сохранила

Если пользовался встроенной групповой обработкой, то там по умолчанию включено выполнение в транзакции. Если сам что-то писал, то, наверное, не забыл завернуть в транзакцию явным образом.

Если сам что-то писал, то, наверное, не забыл завернуть в транзакцию явным образом.

Запросом взял все элементы справочника (пара десятков тысяч) и

Пока выборка.следующий() цикл
	ЭлементСправочника = Выборка.Ссылка.ПолучитьОбъект();
	ЭлементСправочника.Наименование = Элемент.Наименование + " что-нибудь";
	ЭлементСправочника.Записать();
КонецЦикла

Через какое-то время вываливалось с ошибкой о превышении допустимого объёма памяти на один вызов сервера, наименования у всех оставались нетронуты.

Справочник - номенклатура, конфа ка 2.4 релиз, который был последним на июнь\июль прошлого года.

Странно, конечно. Не могу прокомментировать это поведение, не наблюдал такого. Может, всё-таки там был вызов НачатьТранзакцию()? Я нередко занимаюсь подобными вещами, и обычно сознательно избегаю общей транзакции на больших объёмах данных одного типа (это важно), когда ожидаются ошибки записи (то есть почти всегда), чтобы можно было устранить ошибку и не начинать сначала.

Я её не вызывал. И, емнип, оно в отдельной внешней обработке было сделано, так что и до меня вызвать было некому.

Но за сроком давности и отсутствием знаний в 1С могу и соврать.

Единственное помню, что тогда удивился, мол молодцы 1С, я ничего не делал для этого, а солому уже подстелили.