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

Речь пойдёт о Postgresus. Основные возможности:

◽️Веб интерфейс для управления заданиями и отчётами
◽️Расписание бэкапов
◽️Сжатие, автоочистка старых бэкапов
◽️Хранение локально или в S3, Google Drive
◽️Уведомления по Email, Telegram
◽️Запускается в Docker Compose

По сути это замена самописным bash скриптам в кроне. Именно их я и использую для таких задач 🤖 Решил упростить себе задачу. Забегая вперёд, скажу, что эта панель реально заменяет эти скрипты, не более.

Postgresus состоит из двух Docker контейнеров: непосредственно сама панель и локальный экземпляр postgresql сервера для хранения собственных настроек. Запустить можно вручную из предложенного в репозитории файла docker-compose.yml, либо воспользоваться скриптом от разработчика:

# curl -sSL https://raw.githubusercontent.com/RostislavDugin/postgresus/refs/heads/main/install-postgresus.sh | bash

Скрипт ставит докер и стартует с этим же docker-compose.yml. Я вручную запустил. После запуска можно сразу идти в веб интерфейс на порт сервера 4005 и там всё настраивать. Не рекомендую запускать подобные вещи непосредственно на сервере с СУБД. Я сделал отдельную небольшую виртуалку и открыл для неё доступ к базам.

Дальнейшее управление осуществляется через веб интерфейс. Там всё максимально просто и наглядно:
1️⃣ Настраиваем хранилище для бэкапов. Я использовал локальную директорию. После тестов примонтирую туда отдельно большой диск.
2️⃣ Добавляем приёмник для уведомлений. Telegram сразу заработал, нужно указать токен своего бота и ID чата. С почтой не получилось, так как отправка по умолчанию настраивается по TLS, а у меня там локальный сервер стоял без него. Перенастраивать не захотелось. Жаль, что автор не оставил такой возможности.
3️⃣ Добавляем подключение к базе данных и настраиваем параметры её бэкапа.

Бэкап выполняется не особо быстро. Скриптами локально я базу на 5ГБ бэкаплю секунд 30. Из соседней виртуалки с помощью Postgresus бэкапится 12 минут. В целом мне некритично, так как для этого сервера бэкапы выполняются раз в сутки по ночам. Времени достаточно, хотя с такой скоростью это растянется часа на полтора.

Архивы хранятся локально в виде дампов со случайными именами вида a8bc8814-c548-4f9a-ba0c-97d3b1e107fc. Не очень удобно, если захочется куда-то дублировать их. Скачать дамп можно через веб интерфейс и вручную восстановить с помощью pg_restore. Я заглянул внутрь дампа. Он отличается от того, что делаю я с помощью pg_dump. Скорее всего используются какие-то дополнительные ключи. Я обычно делаю чистый дамп только данных.

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

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

⇨ 🌐 Сайт / Исходники

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

#postgresql #backup

Вчера рассмотрел Postgresus - веб панель для бэкапов баз Postgresql. У неё есть очень близкий и более старый аналог – PG Back Web. Панели похожи по функциональности и архитектуре. Автор Postgresus наверняка знаком с ней, потому что многие вещи реализованы схожим образом. Но есть и отличия. Каждый, судя по всему, реализовал настройки и управление так, как ему казалось более удобным. Расскажу по порядку.

1️⃣ Установка выполняется так же, как и у Postgresus – готовый docker-compose.yaml в репозитории для запуска двух контейнеров: сама веб панель и локальная Postgresql для сохранения настроек и состояния. Достаточно запустить docker compose и можно идти на порт 8085 сервера и пользоваться панелью. В консоли больше делать нечего.

2️⃣ В Pgbackweb сущности в виде баз данных и заданий для бэкапа разделены. Отдельно добавляется база, отдельно для неё создаётся задание для бэкапа. Соответственно, для одной и той же базы могут быть созданы разные задачи с бэкапом и параметрами хранения. В Postgresus настройки базы и бэкапа для неё объединены в одну сущность.

3️⃣ Создаваемый в Pgbackweb дамп тут же на лету жмётся в zip. А в самом архиве лежит чистый дамп в текстовом формате, который можно открыть, посмотреть, изменить. Создание дампа в Pgbackweb примерно в 2-2,5 раза дольше, чем у Postgresus. Последний жмёт средствами самого pg_dump, если я правильно понял из исходников, то есть использует ключи -Fc (custom-format) -Z 6 (compression level).

К сожалению, обе панели не дают возможность самому задавать эти параметры. А иногда бывает нужно либо так, либо эдак. Например, если тебе важна скорость, то лучше жать встроенными средствами. Но из такого дампа потом неудобно извлекать отдельную таблицу, если она понадобится. А из текстового дампа это сделать очень просто. Лично я, когда создаю дампы баз данных, выгружаю их в обычном текстовом формате и жму сам с помощью pigz в многопоточном режиме. Получается и быстро, и удобно. Потом распаковал и делай с ним, что хочешь.

4️⃣ Pgbackweb предлагает сохранять бэкапы либо локально, либо в S3. Больше у неё ничего нет для хранения. Формат путей вида /backups/dbase01/2025/07/21. Это удобно, если захочется забирать готовые дампы куда-то ещё и складывать их в архивы по каким-то датам. В Postgresus такой возможности нет. Там ни в пути, ни в имени файла нет никаких временных меток и упоминания имени базы.

5️⃣ Сохранённый дамп можно самому скачать и восстановить вручную, либо воспользоваться веб интерфейсом. Базу можно восстановить как в исходную, так и в другую, в том числе на другом сервере. Здесь возможности обеих панелей совпадают.

6️⃣ В качестве уведомлений Pgbackweb предлагает только вебхуки, что слабовато по сравнению с готовой интеграцией с Telegram, Email, Slack, Discord в Postgresus.

В общем и целом панели сильно похожи и выполняют одни и те же задачи. Разница в некоторых мелочах, которые кому-то могут быть критичны, кому-то нет. Мне лично больше понравилась Postgresus за её внешний вид и внутреннюю логику. Сжатые дампы делает намного быстрее, что уже на базах в 5-10 ГБ становится критично. Так как, к примеру, 15 минут против 35 для 10 ГБ – это существенная разница.

⇨ 🌐 Исходники / ▶️ Видеобзор

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

#postgresql #backup

В последних публикациях на тему бэкапа баз в Postgresql не раз всплывал вопрос: "А есть ли веб панели для управления бэкапами баз MySQL?". Я сам никогда их не использовал и не встречал. Знаю, что инструменты для подобного бэкапа есть в панелях по управлению веб серверами, типа Hestiacp, aaPanel и им подобным. Очевидно, если у вас не веб сервер, то такую панель ставить не имеет смысла. А специализированных панелей только для бэкапов не существует.

Решение, как оказалось, есть на поверхности. Существует известная веб панель для управления сервером - Webmin. Странно, что я по ней ни одной заметки ещё не написал. Хоть сам и не ставлю на свои сервера, но приходилось работать. Там есть интересные возможности, ради которых её можно использовать.

В Webmin есть модуль для управления MySQL. Я его попробовал. Настроек немного, но сделано вполне функционально. Я там немного покумекал, как сделать наиболее удобно и получилось неплохо. Расскажу по шагам, как я всё настроил.

1️⃣ Установка. Панель собрана в пакеты под популярные дистрибутивы. Подключить репозиторий можно автоматически через скрипт:

# curl -o webmin-setup-repo.sh https://raw.githubusercontent.com/webmin/webmin/master/webmin-setup-repo.sh
# sh webmin-setup-repo.sh

Либо вручную, добавив репозиторий и ключ от него. Для Debian это:

deb https://download.webmin.com/download/newkey/repository stable contrib

# apt-get install webmin --install-recommends

После установки можно идти по IP адресу сервера на порт 10000 и заходить под учёткой root. После этого в разделе Webmin ⇨ Webmin Configuration ⇨ IP Access Control ограничьте доступ к панели по IP адресам. Её нельзя выставлять в публичный доступ. В панели периодически находят уязвимости, а у неё полный доступ к серверу.

2️⃣ Если MySQL сервер устанавливался после установки Webmin, то модуль управления будет в списке Un-used Modules, если после, то в Servers. Чтобы модуль переехал из Un-used, нажмите на Refresh Modules.

3️⃣ В модуле есть возможность настроить подключение к MySQL серверу в разделе Configuration ⇨ Server Connections. По умолчанию используется localhost, но вы можете подключиться к любому другому серверу, в том числе в контейнере. Главное, чтобы к нему был доступ извне.

4️⃣ Можно настроить бэкап как конкретной базы, так и всех разом. При бэкапе всех баз, каждая из них сохраняется в отдельный файл и может при желании сразу сжиматься. Бэкап выполняется через стандартный mysqldump. Ключи запуска могут добавлять при необходимости.

5️⃣ Для бэкапов есть планировщик. Работает в формате заданий cron. Да и сами задания добавляются в системный файл /var/spool/cron/crontabs/root.

6️⃣ Основное неудобство – задание бэкапа каждый раз перезаписывает файлы. Нет возможности хранить несколько копий и автоматически удалять старые. Я решил этот вопрос максимально просто в лоб.

Можно указать команды, которые будут выполняться до запуска бэкапа и после. Настроил бэкап в директорию /root/sql_backup а после бэкапа добавил команду:

mkdir /mnt/backup/`date +"%Y-%m-%d_%H-%M"` && cp -R /root/sql_backup/* /mnt/backup/`date +"%Y-%m-%d_%H-%M"`/

Она создаёт директорию вида 2025-07-23_16-27 и копирует туда созданные файлы. При следующем запуске имя директории будет другое.

Для того, чтобы очищать старые бэкапы, добавил команду перед запуском:

find /mnt/backup -type d -printf '%T@ "%p"\n' | sort -n | head -n -30 | awk '{print $2}' | xargs -I {} rm -r {}

Она оставляет 30 новых директорий, а более старые удаляет. Вопрос с ротацией бэкапов решён. Работает просто и наглядно. При желании можно добавить ещё одну команду, которая будет куда-нибудь во вне копировать эти файлы.

7️⃣ Для восстановления бэкапов достаточно создать новую базу или выбрать существующую, зайти в неё, выбрать раздел Execute SQL ⇨ Run SQL from file ⇨ From local file и выбрать один из дампов. При желании можно подключиться к другому серверу и восстановить бэкап туда.

Получилось простое в настройке и вполне функциональное решение.

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

#backup #mysql