LINUX.ORG.RU
ФорумAdmin

1С + postgres бэкап

 , ,


2

2

Добрый день. Достался от коллеги сервер с 1с и postgres. Но вся проблема в том, что на нем вертиться около 12-ти баз, которые бывают убиваются или появляются новые. Поэтому бэкапить просто привычным мне pg_dump не получится. Решил попробовать pg_dumpall, дамп всех баз создался, решил развернуть на другом сервере. Но 1С подключиться ни к одной не может. Если делаю бэкап одной базы, то всё работает нормально. Возможно у dumpall есть какие-то особенности восстановления? Восстанавливал на пустом postgre без создания баз. Пока сделал репликацию баз, но бэкап всё-таки родней.

Привет

Есть решение

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

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

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

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

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

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

Shulman ()
Ответ на: комментарий от Shulman

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

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

Shulman ()
Ответ на: комментарий от Shulman

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

el_vago ()
Ответ на: комментарий от el_vago

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

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

Shulman ()
Ответ на: комментарий от Shulman

Есть решение

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

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

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

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

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

anonymous ()
Ответ на: удаленный комментарий

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

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

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

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

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

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

anonymous ()
Ответ на: комментарий от GAMer

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

anonymous ()
Ответ на: комментарий от anonymous

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

GAMer ★★★★★ ()
Ответ на: комментарий от anonymous

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

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

Shulman ()
Ответ на: комментарий от anonymous

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

anonymous ()
Ответ на: комментарий от anonymous

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

Shulman ()
Ответ на: комментарий от anonymous

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

anonymous ()
Ответ на: комментарий от anonymous

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

Shulman ()
Ответ на: комментарий от anonymous

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

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

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

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

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

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

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

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

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

anonymous ()
Ответ на: комментарий от anonymous

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

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

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

Shulman ()
Ответ на: комментарий от GAMer

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

anonymous ()
Ответ на: комментарий от anonymous

RTO

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

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

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

anonymous ()
Ответ на: комментарий от GAMer

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

DALDON ★★★★★ ()
Ответ на: комментарий от DALDON

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

GAMer ★★★★★ ()
Ответ на: комментарий от anonymous

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

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

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

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

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

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

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

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

anonymous ()
Ответ на: комментарий от anonymous

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

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

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

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

disaster

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

Shulman ()
Ответ на: комментарий от anonymous

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

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

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

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

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

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

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

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

anonymous ()
Ответ на: комментарий от Shulman

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

не так ли?

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

anonymous ()
Ответ на: комментарий от anonymous

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

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

меня привлекает только нормальное 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.

anonymous ()
Ответ на: комментарий от anonymous

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

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

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

Nao ★★★★★ ()
Ответ на: комментарий от anonymous

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

Shulman ()
Ответ на: комментарий от GAMer

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

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

mogwai ★★★★ ()
Ответ на: комментарий от anonymous

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

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

mogwai ★★★★ ()
Ответ на: комментарий от mogwai

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

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

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

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

anonymous ()
Ответ на: комментарий от anonymous

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

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

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

mogwai ★★★★ ()
Ответ на: комментарий от mogwai

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

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

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

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

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

anonymous ()
Ответ на: комментарий от anonymous

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

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

mogwai ★★★★ ()
Ответ на: комментарий от mogwai

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

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

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

anonymous ()
Ответ на: комментарий от anonymous

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

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

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

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

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

mogwai ★★★★ ()
Последнее исправление: mogwai (всего исправлений: 1 )
Ответ на: комментарий от mogwai

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

anonymous ()
Ответ на: комментарий от anonymous

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

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

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

mogwai ★★★★ ()
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.