Всем доброго дня. Перетаскиваем торговую базу 1С размером в 200+ ГБ

с мсскуля на линуксовый постгрес (пока всё по теме чатика 😁).

· Средствами мсскуля база бэкапится за 10±3 минут каждые полчаса (требование руководства), ужимаясь раз в 5-6 от исходной.
· Бэкап посредством pg_dump при минимальном сжатии хоть и пакует базу раз в 7-8, но занимает аккурат полчаса, что слишком долго — и это в отсутствие нагрузки на сам сервер. Без сжатия вдвое быстрее, но слишком жирно по месту получается.

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

Подскажите, пожалуйста, кто как с подобной проблемой разбирался?
Обязательно ли необходим спецсофт типа бармена, рубэкапа, pg_probackup и им подобных, или проще наскриптовать архивацию файловой составляющей через rsync, а остальное — вызовами к СУБД?

Поделитесь бэст-практиками, коллеги!

пакуется база чем? проц при этом полностью утилизируется ?

На данный момент в мсскуле? Или ещё не пущенная в бой на постгре? Оба варианта указаны: - на виндосервере — через мсскуль-менеджер, - на линёвом — через pg_dump. Насчёт нагрузки на проц в мс-варианте не скажу: не использую винду никак и нигде. Да и зачем эта инфа, если в итоге всё равно постгрес будет так или иначе? На линёвом пока не засекал нагрузок, но не должно быть уж очень. И он ведь не в работе ещё.

Спец софтины не обязательны. Я по крону дёргаю pg_basebackup,. А в качестве archive_command использую scp. Но все равно все обернуто скриптами для мониторинга и для сжатия архива журналов. Заскриптовать все ручками считаю полезным для понимания как оно работает. Спецсофтины удобны, наверное, когда у Вас с 10+ серверов. И когда нужно отдать админство другому человеку.

Нужно гуглить postgres pitr. Вот, например, https://www.postgresql.org/docs/current/continuous-archiving.html

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

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

Даже в заббикс отправляет, что он выполнился удачно?

Большынство вариантов вы да, ужэ указали. Или логический бэкап через pg_dump (pg_dumpall) -- только данные, прилично жмутся, никаких инкрементов. Или варианты с физическим бэкапом -- тогда записаны и все индэксы, данных заметно большэ. Но есть всякие варианты с инкрементами. >Без сжатия вдвое быстрее, Вполне оптимизируемый момент. Форматы plain и custom можно отправлять в stdout, который сжымать другим процэссом, другими алгоритмами или на другом сервере. Хочу обратить внимание ещё на один вариант -- простой физический бэкап и архив PITR. Через pg_archivecommand. Очень свежая резервная копия, не очень большая загрузка процэссора. >Поисковики по данной теме подсовывают в основном варианты с кластером или с разными серверами — боевым и для бэкапов, Что довольно странно -- инкрементальные бэкапы есть только в разных pg_probackup/wal-g, и от наличия второго сервера они никак не зависят.

И за пивом бегает 😜

Я проходил все по ссылке. Грабель нет. Cвои скрипты писал для мониторинга, сжатия и ротации бекапов.

Почему-то рубануло мой развёрнутый ответ, попробую кусочками.

Большое спасибо за пояснения, но поскольку я только вникаю в механику постгре-резервирования, вопросов ещё куча. :)

Попробуйте pg_probackup . Удовлетворит все ваши потребности. Полную копию базы 600 Гб делал минут за 20. Инкрементальные копии за минуты.

Что до крона, давно пересел на таймеры, о чём можно почитать в статье "Таймеры_systemd_вместо_crond" на вики альтлинукса (вот за что мой пост рубануло — я ссылку на статью вставил). Но то неважно.

А потом скажут, что в России все кроны отменяются.