Всем привет! Возник вопрос по поводу бэкапа Postrgres, установленного в

докере.

У меня подключен volume к контейнеру Postrgres, где хранятся данные. Сам volume - это папка в приаттаченном к VPS хранилище.
Из-за этого бэкапы VPS не бэкапят данные базы. В этом хранилище могут быть данные от разных контейнеров Postrgres, а также от баз других типов, развернутых в докере.

В связи с этим вопрос - достаточно ли надежно для бэкапа просто архивировать содержимое хранилища? Я готов смириться с ситуацией, когда данные, записываемые в базу в момент бэкапа могут потеряться. Мне важное понять, смогу ли я потом этот архив, допустим, развернуть в другом хранилище, приаттаченном к другому VPS, так чтобы постгрес из докер volumes смог подцепить данные.

P.S.
Я понимаю, что у постгреса есть встроенный механизм дампа и все такое. Но как я уже выше написал, в хранилище могут сваливаться данные от разных постгесов и вообще от других сервисов: какой-нибудь MariaDB, Mongo, Redis - что угодно.

Нет.

А есть возможность как-то развернуть ответ?

Только snapshot (одномоментно, всей/всех FS, где есть файлы данного кластера БД PostgreSQL) backups дают такую гарантию.

если бэкап хранилища совмещает flush + snapshot - тогда можно

Flush (если "хранилище" корректно обрабатывает fsync()) не нужен. А так — да.

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

тут пишут и про монги и вообще любые базы

Лично я не уверен, про что Вы конкретно делаете / как там это работает — подождите, может подскажут.

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

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

> Допустим, я делаю это по ночам, когда с базой никто не работает (autovacuum, отрываясь от обработки очередной таблицы): Да неужели?! ;)

вопрос в том кто этот снапшот будет делать.. если можно выключить базу - можно делать lvm/btrfs снапшоты, тут же запускать базу, и делать бэкап снапашота

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

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

да, всё так

да, там в песочнице куча всего валятся, на несколько минут останавливать проблем не будет. Т.е. если у меня будет скрипт в CRON, который делает: docker compose stop <потом идет магия создания снэпшота> docker compose up -d <потом архивирование / бэкапирование снэпшота> То все должно надежно работать в самых разных сценариях в самых разных базах?

если объем не большой и время остановки не сильно важно можно и без снапшота просто копированием/сжатием в архив

а, ок, т.е. на остановленном докере и gzip какой-нибудь сработает

а почему бы вам не бэкапировать именно постгрес через тот же дамп ? там ведь буквально одну строку в крон поставить. И контейнер не надо останавливать. А прочие данные на вашей шаре уже по ситуации, монго-дамп тот же самый. Вроде в вашем сетапе проще настроить энное количество индивидуальных бэкапов, чем рисковать

Основная причина - нужно будет разбираться во всем этом зоопарке. (а поскольку я не сисадмин и не DevOps, то сколько времени на это уйдет?) У меня песочница где я тестирую десятки self-hosted сервисов, там обычно от двух и более контейнеров - сервис + база. Какие-то сервисы приживаются и существуют долго, а с какими-то поигрался, написал статью и в архив. Хочется какое-то более-менее надежное решение для бэкапа на стороне хост-системы. И отвечая на незаданный вопрос - почему бы не бэкапить силами VPS-провайдера: дело в том, что VPS-ки обычно машстабируются только в сторону увеличения. Hetzner предлагает дисковое пространство для VPS и еще отдельно Volume (это не docker volume, это так у провайдера называется услуга), которые можно примонтировать к серваку. Вот я тестирую что-то тяжелое в этом месяце - примонтировал VPS-ку потолще. А потом понадобится что-то более легкое - убил одну VPS, создал другую дешевле и к тому же хранилищу приаттачил. Я совершенно не ожидал, что просто копировать папку в случае "живой" бд - ненадежный способ бэкапирования.

Это, кстати, ненадёжный способ в случае чего угодно (просто сисадминам как-то...). Мне вспоминается (кто-то рассказывал), как они настроили backups FS прямо посреди дня — а потом какому-то пользователю понадобилась (предыдущая) копия Excel-файла, с которым он работал несколько дней подряд... и тут выяснилось, что копии за четыре предыдущих дня "запороты" — видимо, он записывал файл именно тогда, когда backup его копировал — в результате получалась "каша" (редкая "удача", да).

да не, просто иксель зло) вижу причину в этом)

У пользователя актуальный файл (на той же FS) был не "битый", ясное дело. Но четыре дня подряд записывать его точно в тот же момент — это талант, не иначе (я поэтому и запомнил эту историю). ;)

Монга-ACID. Правда, расшифровывается термин у них сильно прогрессивно :)

Да я-то не спорю (и я имел в виду "новый" NoSQL в общем) — я написал, что не очень удивился бы, всего лишь (учитывая их прошлые достижения, и некоторую незрелость и направленность на BASE вместо ACID). ;)