Раз уж я рассмотрел панели для управления бэкапами (Postgresus и Pgbackweb) в виде дампов в Postgresql, было бы логично рассмотреть и вариант со своими велосипедами на bash. Поделюсь тем, что использую я.
Сначала полный текст скрипта для бэкапа:
Рассказываю, что тут происходит:
1️⃣ Завожу в переменную BASES список баз, которые мы будем бэкапить. Их можно указывать вручную, примерно так:
Можно использовать обратный подход. Бэкапить все базы, но вручную или по маске задавать исключения. Примерно так:
2️⃣ База дампится с помощью
3️⃣ В дампе проверяем наличие строки
Соответственно, если строки присутствуют, пишем в лог файл, что Backup is OK, если есть проблемы, то Backup is corrupted. Дальше этот файл забирает либо мониторинг, либо хранилка логов. И если они видят фразу corrupted, то срабатывает триггер.
4️⃣ Если с дампом всё в порядке, то он жмётся архиватором
Получается автоматическая максимально простая и эффективная схема работы. Я вчера добавлял базы в веб панель. Честно говоря, меня это утомило. Если баз 1-2, то не проблема. А 15 штук добавлять уже надоедает. Бывает и больше. Плюс, надо вручную следить за ними, добавлять, отключать ненужные и т.д. Так что панель вроде и выглядит удобно, но если баз много, то удобства уже сомнительные.
Дальше у меня работает ещё один простой скрипт, который забирает эти дампы на тестовый сервер, распаковывает и заливает в СУБД. Расскажу о нём в следующей заметке.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#postgresql #backup #script
Сначала полный текст скрипта для бэкапа:
#!/bin/bash
BASES=`/opt/pgpro/1c-16/bin/psql -U postgres -l | grep "_buh\|_zup" | awk '{print $1}'`
DATA=`date +"%Y-%m-%d_%H-%M"`
LOGDIR=/var/lib/pgpro/service_logs
BACKUPDIR=/var/lib/pgpro/backup
for i in ${BASES};
do
echo "`date +"%Y-%m-%d_%H-%M-%S"` Start backup $i" >> $LOGDIR/backup.log
/opt/pgpro/1c-16/bin/pg_dump -U postgres $i > $BACKUPDIR/$DATA-$i.sql 2>> $LOGDIR/dump.log
BEGIN=`head -n 2 $BACKUPDIR/$DATA-$i.sql | grep ^'-- PostgreSQL database dump' | wc -l`
END=`tail -n 3 $BACKUPDIR/$DATA-$i.sql | grep ^'-- PostgreSQL database dump complete' | wc -l`
if [ "$BEGIN" == "1" ];then
if [ "$END" == "1" ];then
echo "Backup ${i} is OK" >> $LOGDIR/backup.log
/usr/bin/pigz -c $BACKUPDIR/$DATA-$i.sql > $BACKUPDIR/$DATA-$i.sql.gz
/usr/bin/rm $BACKUPDIR/$DATA-$i.sql
else
echo "Backup ${i} is corrupted" >> $LOGDIR/backup.log
fi
else
echo "Backup ${i} is corrupted" >> $LOGDIR/backup.log
fi
echo "`date +"%Y-%m-%d_%H-%M-%S"` End backup $i" >> $LOGDIR/backup.log
echo "=========================================" >> $LOGDIR/backup.log
done
Рассказываю, что тут происходит:
BASES=("db01_zup" "db02_buh"). Можно брать список всех баз. В данном случае на сервере я маркирую базы метками _buh и _zup в названиях баз, чтобы по ним делать выборку. Если базу не нужно бэкапить, то эта метка не ставится. Можно придумать любую свою метку, например _back. Это позволяет автоматически бэкапить все нужные базы, не следя за их составом. Очень актуально, если создаёте и удаляете базы не вы, но вам нужны все бэкапы баз. Можно использовать обратный подход. Бэкапить все базы, но вручную или по маске задавать исключения. Примерно так:
/opt/pgpro/1c-15/bin/psql -U postgres -l | grep -wv 'template0\|template1\|test-base\|_test' | sed -e '1,3d' | head -n -2 | awk '{print $1}'`pg_dump без каких-либо дополнительных параметров. На выходе имеем обычный несжатый текстовый дамп.-- PostgreSQL database dump в начале дампа и -- PostgreSQL database dump complete в конце. Поэтому нам важно иметь дамп в текстовом формате. Если процесс снятия дампа прошёл без ошибок и в дампе присутствуют эти строки, то с большой долей вероятности с ним всё в порядке. Я ни разу не сталкивался с обратной ситуацией.Соответственно, если строки присутствуют, пишем в лог файл, что Backup is OK, если есть проблемы, то Backup is corrupted. Дальше этот файл забирает либо мониторинг, либо хранилка логов. И если они видят фразу corrupted, то срабатывает триггер.
pigz. Он работает многопоточно всеми доступными ядрами процессора. Если не хотите нагружать так плотно сервер, то количество потоков можно ограничить ключами. Я обычно снимаю дампы ночью и жму на всю катушку, чтобы побыстрее завершилось. Дампы потом ещё передавать надо. Это уже отдельная процедура и запускается с сервера бэкапов. С самого сервера СУБД к бэкапам доступа нет. Получается автоматическая максимально простая и эффективная схема работы. Я вчера добавлял базы в веб панель. Честно говоря, меня это утомило. Если баз 1-2, то не проблема. А 15 штук добавлять уже надоедает. Бывает и больше. Плюс, надо вручную следить за ними, добавлять, отключать ненужные и т.д. Так что панель вроде и выглядит удобно, но если баз много, то удобства уже сомнительные.
Дальше у меня работает ещё один простой скрипт, который забирает эти дампы на тестовый сервер, распаковывает и заливает в СУБД. Расскажу о нём в следующей заметке.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#postgresql #backup #script
Please open Telegram to view this post
VIEW IN TELEGRAM
4👍161👎3
Утром рассказал, как делаю бэкапы баз Postgresql с помощью скриптов и
Первым делом надо забрать дампы с исходного сервера. Для этого беру простой скрипт, который забирает по SSH только свежие файлы за прошлый день. Если забрать сразу только нужные файлы, то потом не придётся делать в них выборку:
Использую rsync, а список файлов для копирования формирую сразу в выражении ключа, подключившись к нужному хосту по SSH и отсортировав файлы по дате, взяв не старше суток. В данном случае файл timestamp через
Ну а дальше дело техники. По очереди выполняю набор команд для удаления старой базы, создания новой, распаковки и заливки дампа. Перед первым запуском этого скрипта вручную создаю все восстанавливаемые базы и выборочно проверяю восстановление. Потом формирую итоговый список команд:
Сразу говорю, что я тут ничего не оптимизировал, никаких проверок не делал. Если просто взять и запустить, то скорее всего у вас вывалятся какие-то ошибки или что-то пойдёт не так. Я просто показываю идею. У меня уже давно и структура каталогов одна и та же, и подход к именованию баз, бэкапов и т.д. Это всё сделано под меня и работает так уже много лет. Меня устраивает.
В данном скрипте нет никаких проверок успешной работы и оповещений, потому что это не последний этап проверок. Далее в зависимости от того, где эта база используется, запускаются свои проверки. Для баз 1С выполняется автоматическая выгрузка в dt с помощью отдельного скрипта. Если она проходит успешно, то считается, что дамп базы живой и нормально восстановился.
Если же это база от веб проекта, то параллельно из другого бэкапа восстанавливаются исходники в тестовый веб сервер, подключается восстановленная база и работает стандартная веб проверка в Zabbix Server, которая ищет какие-то данные на странице, которые без работающей базы не будут показаны. Если веб проверки проходят успешно, то считается, что база восстановилась, да и в целом бэкап живой.
Более сложные проверки в восстановленных базах я не делаю. Мой опыт в обслуживаемых инфраструктурах показывает, что этого достаточно. Ни разу не сталкивался, что всё прошло успешно, а с базой проблемы. Обычно проблемы возникают сразу в снятии дампа. Если он корректно выполнен, то дальше уже все отрабатывает нормально.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#backup #postgresql #script
pg_dump. Сейчас покажу, как я их проверяю. Для этого обычно держу небольшой тестовый сервер с той же версией Postgresql. В идеале это должна быть копия прода, но не всегда это возможно. На нём же зачастую проверяю обновления.Первым делом надо забрать дампы с исходного сервера. Для этого беру простой скрипт, который забирает по SSH только свежие файлы за прошлый день. Если забрать сразу только нужные файлы, то потом не придётся делать в них выборку:
#!/bin/bash
/usr/bin/rsync -av --progress --files-from=<(ssh root@10.20.5.10 '/usr/bin/find /var/lib/pgpro/backup -type f -mtime -1 -exec basename {} \; | egrep -v timestamp') root@10.20.5.10:/var/lib/pgpro/backup/ /data/backup/
Использую rsync, а список файлов для копирования формирую сразу в выражении ключа, подключившись к нужному хосту по SSH и отсортировав файлы по дате, взяв не старше суток. В данном случае файл timestamp через
egrep -v добавлен в исключения. У меня там метка времени последнего бэкапа хранится для нужд мониторинга.Ну а дальше дело техники. По очереди выполняю набор команд для удаления старой базы, создания новой, распаковки и заливки дампа. Перед первым запуском этого скрипта вручную создаю все восстанавливаемые базы и выборочно проверяю восстановление. Потом формирую итоговый список команд:
#!/bin/bash
BASES=`/opt/pgpro/1c-16/bin/psql -U postgres -l | grep "_buh\|_zup" | awk '{print $1}'`
BACKUP_DIR="/data/backup"
for i in ${BASES};
do
echo "`date +"%Y-%m-%d_%H-%M-%S"` Drop database ${i}"
/opt/pgpro/1c-16/bin/dropdb -U postgres ${i}
echo "`date +"%Y-%m-%d_%H-%M-%S"` Create database ${i}"
/opt/pgpro/1c-16/bin/createdb -U postgres -T template0 ${i}
echo "`date +"%Y-%m-%d_%H-%M-%S"` Start extract $i"
/usr/bin/find /data/backup -type f -name *${i}* -exec /usr/bin/unpigz '{}' \;
echo "`date +"%Y-%m-%d_%H-%M-%S"` End extract $i"
echo "`date +"%Y-%m-%d_%H-%M-%S"` Start restore $i"
/opt/pgpro/1c-16/bin/psql -U postgres ${i} < ${BACKUP_DIR}/`ls ${BACKUP_DIR} | grep ${i}` 1>/dev/null
echo "`date +"%Y-%m-%d_%H-%M-%S"` End restore $i"
echo "`date +"%Y-%m-%d_%H-%M-%S"` rm dump ${i}"
/usr/bin/rm ${BACKUP_DIR}/`ls ${BACKUP_DIR} | grep ${i}`
done
Сразу говорю, что я тут ничего не оптимизировал, никаких проверок не делал. Если просто взять и запустить, то скорее всего у вас вывалятся какие-то ошибки или что-то пойдёт не так. Я просто показываю идею. У меня уже давно и структура каталогов одна и та же, и подход к именованию баз, бэкапов и т.д. Это всё сделано под меня и работает так уже много лет. Меня устраивает.
В данном скрипте нет никаких проверок успешной работы и оповещений, потому что это не последний этап проверок. Далее в зависимости от того, где эта база используется, запускаются свои проверки. Для баз 1С выполняется автоматическая выгрузка в dt с помощью отдельного скрипта. Если она проходит успешно, то считается, что дамп базы живой и нормально восстановился.
Если же это база от веб проекта, то параллельно из другого бэкапа восстанавливаются исходники в тестовый веб сервер, подключается восстановленная база и работает стандартная веб проверка в Zabbix Server, которая ищет какие-то данные на странице, которые без работающей базы не будут показаны. Если веб проверки проходят успешно, то считается, что база восстановилась, да и в целом бэкап живой.
Более сложные проверки в восстановленных базах я не делаю. Мой опыт в обслуживаемых инфраструктурах показывает, что этого достаточно. Ни разу не сталкивался, что всё прошло успешно, а с базой проблемы. Обычно проблемы возникают сразу в снятии дампа. Если он корректно выполнен, то дальше уже все отрабатывает нормально.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#backup #postgresql #script
Telegram
ServerAdmin.ru
Раз уж я рассмотрел панели для управления бэкапами (Postgresus и Pgbackweb) в виде дампов в Postgresql, было бы логично рассмотреть и вариант со своими велосипедами на bash. Поделюсь тем, что использую я.
Сначала полный текст скрипта для бэкапа:
#!/bin/bash…
Сначала полный текст скрипта для бэкапа:
#!/bin/bash…
👍108👎4
В последних публикациях на тему бэкапа баз в Postgresql не раз всплывал вопрос: "А есть ли веб панели для управления бэкапами баз MySQL?". Я сам никогда их не использовал и не встречал. Знаю, что инструменты для подобного бэкапа есть в панелях по управлению веб серверами, типа Hestiacp, aaPanel и им подобным. Очевидно, если у вас не веб сервер, то такую панель ставить не имеет смысла. А специализированных панелей только для бэкапов не существует.
Решение, как оказалось, есть на поверхности. Существует известная веб панель для управления сервером - Webmin. Странно, что я по ней ни одной заметки ещё не написал. Хоть сам и не ставлю на свои сервера, но приходилось работать. Там есть интересные возможности, ради которых её можно использовать.
В Webmin есть модуль для управления MySQL. Я его попробовал. Настроек немного, но сделано вполне функционально. Я там немного покумекал, как сделать наиболее удобно и получилось неплохо. Расскажу по шагам, как я всё настроил.
1️⃣ Установка. Панель собрана в пакеты под популярные дистрибутивы. Подключить репозиторий можно автоматически через скрипт:
Либо вручную, добавив репозиторий и ключ от него. Для Debian это:
После установки можно идти по 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️⃣ Можно настроить бэкап как конкретной базы, так и всех разом. При бэкапе всех баз, каждая из них сохраняется в отдельный файл и может при желании сразу сжиматься. Бэкап выполняется через стандартный
5️⃣ Для бэкапов есть планировщик. Работает в формате заданий cron. Да и сами задания добавляются в системный файл
6️⃣ Основное неудобство – задание бэкапа каждый раз перезаписывает файлы. Нет возможности хранить несколько копий и автоматически удалять старые. Я решил этот вопрос максимально просто в лоб.
Можно указать команды, которые будут выполняться до запуска бэкапа и после. Настроил бэкап в директорию
Она создаёт директорию вида
Для того, чтобы очищать старые бэкапы, добавил команду перед запуском:
Она оставляет 30 новых директорий, а более старые удаляет. Вопрос с ротацией бэкапов решён. Работает просто и наглядно. При желании можно добавить ещё одну команду, которая будет куда-нибудь во вне копировать эти файлы.
7️⃣ Для восстановления бэкапов достаточно создать новую базу или выбрать существующую, зайти в неё, выбрать раздел Execute SQL ⇨ Run SQL from file ⇨ From local file и выбрать один из дампов. При желании можно подключиться к другому серверу и восстановить бэкап туда.
Получилось простое в настройке и вполне функциональное решение.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#backup #mysql
Решение, как оказалось, есть на поверхности. Существует известная веб панель для управления сервером - Webmin. Странно, что я по ней ни одной заметки ещё не написал. Хоть сам и не ставлю на свои сервера, но приходилось работать. Там есть интересные возможности, ради которых её можно использовать.
В Webmin есть модуль для управления MySQL. Я его попробовал. Настроек немного, но сделано вполне функционально. Я там немного покумекал, как сделать наиболее удобно и получилось неплохо. Расскажу по шагам, как я всё настроил.
# 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 адресам. Её нельзя выставлять в публичный доступ. В панели периодически находят уязвимости, а у неё полный доступ к серверу.
mysqldump. Ключи запуска могут добавлять при необходимости. /var/spool/cron/crontabs/root.Можно указать команды, которые будут выполняться до запуска бэкапа и после. Настроил бэкап в директорию
/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 новых директорий, а более старые удаляет. Вопрос с ротацией бэкапов решён. Работает просто и наглядно. При желании можно добавить ещё одну команду, которая будет куда-нибудь во вне копировать эти файлы.
Получилось простое в настройке и вполне функциональное решение.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#backup #mysql
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
1👍75👎5
На днях в очередной раз настраивал Proxmox Backup Server (PBS) в режиме синхронизации бэкапов между двумя разнесёнными хранилищами. Там есть некоторые нюансы с правами пользователей, которые приходится уточнять в документации, так что решил написать пошаговую инструкцию. Плюс, поделиться информацией для тех, кто ещё не настраивал подобное, либо вообще не знает о такой возможности.
PBS умеет бэкапить как виртуальные машины с уровня гипервизора, так и файлы внутри виртуальных машин с помощью Proxmox Backup Client. Сервер бэкапов делится на Datastores со своими бэкапами и настройками доступа. Каждый Datastore штатно может быть синхронизован с другим удалённым Datastore на другом PBS. Это позволяет строить распределённые системы хранения данных, где бэкапы синхронизируются автоматически и хранятся в соответствии с заданными локальными политиками хранения. Получается удобная и функциональная распределённая система бэкапов. И при этом полностью бесплатная.
Имеем 2 разных PBS: pbs-local и pbs-remote. На первый бэкапятся виртуальные машины и затем бэкапы синхронизируются в режиме Push на второй сервер. Рассказываю, как это настроить.
1️⃣ На pbs-remote идём в Configuration -> Access Control и создаём пользователя, под которым будет подключаться pbs-local. Велик соблазн везде использовать root и полные права, но не рекомендую так делать. Тут же в разделе Permissions добавляем новому пользователю следующие права:
{store} - название Datastore, куда будут синхронизироваться бэкапы. Можно создавать для каждого Datastore своего пользователя, можно использовать одного для всех. Тут уже решайте сами, как будете дробить доступ.
2️⃣ На pbs-local идём в Configuration -> Remotes и добавляем pbs-remote, используя созданную выше учётную запись.
3️⃣ На pbs-local в разделе Configuration -> Access Control -> Permissions для пользователей локальных Datastore, которые будут синхронизироваться, добавьте права:
4️⃣ На pbs-local идём в Datastore, выбираем тот, что хотим синхронизировать. Переходим в раздел Sync Jobs и добавляем задачу Add Push Sync Job. Выбираем добавленный на шаге 2 remote и выбираем остальные параметры, в том числе расписание синхронизации.
На этом всё. Теперь можно либо дождаться времени выполнения, либо запустить синхронизацию принудительно. По завершении на pbs-remote будет копия всех бэкапов. То есть на обоих серверах раздел Content будет идентичным. Можно подключить pbs-remote к какому-то гипервизору и там проверять восстановление и запуск виртуальных машин. Это удобно делать, расположив PVE и PBS на одном железном сервере. Получается универсальный инструмент и для дополнительной копии бэкапов, и для их проверки.
Отдельно отмечу, что синхронизация хорошо переносит нестабильные соединения. Процесс не прерывается при разрывах связи и её отсутствии в течении нескольких минут. При возобновлении связи синхронизация продолжается.
Ту же самую процедуру синхронизации можно проводить в обратном направлении, то есть по модели Pull, когда удалённый сервер сам подключается к локальному и забирает данные. Можно всё это комбинировать. Например, VM бэкапятся в локальный Datastore, куда и них есть доступ. Потом на этом же PBS эти бэкапы по модели Pull копируются в рамках этого же сервера, но в другой Datastore, куда доступ ограничен. А с этого Datastore бэкапы по Pull или Push копируются на удалённый сервер.
Настройки очень гибкие и зависят от вашей инфраструктуры, режима параноидальности и доступного места для хранения. Напомню, что в каждом Datastore могут быть свои политики хранения бэкапов. Где-то храним 5 последних копий, а где-то 7 дневных копий, 4 недельных и 6 месячных. А куда-то складываем месячные и вообще не удаляем.
В 4-й версии PBS будет ещё пачка приятных нововведений. Например, хранение бэкапов в S3. И всё это бесплатно.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#proxmox #backup
PBS умеет бэкапить как виртуальные машины с уровня гипервизора, так и файлы внутри виртуальных машин с помощью Proxmox Backup Client. Сервер бэкапов делится на Datastores со своими бэкапами и настройками доступа. Каждый Datastore штатно может быть синхронизован с другим удалённым Datastore на другом PBS. Это позволяет строить распределённые системы хранения данных, где бэкапы синхронизируются автоматически и хранятся в соответствии с заданными локальными политиками хранения. Получается удобная и функциональная распределённая система бэкапов. И при этом полностью бесплатная.
Имеем 2 разных PBS: pbs-local и pbs-remote. На первый бэкапятся виртуальные машины и затем бэкапы синхронизируются в режиме Push на второй сервер. Рассказываю, как это настроить.
Path: /datastore/{store}Role: DatastoreBackup{store} - название Datastore, куда будут синхронизироваться бэкапы. Можно создавать для каждого Datastore своего пользователя, можно использовать одного для всех. Тут уже решайте сами, как будете дробить доступ.
Path: /remoteRole: RemoteSyncPushOperatorНа этом всё. Теперь можно либо дождаться времени выполнения, либо запустить синхронизацию принудительно. По завершении на pbs-remote будет копия всех бэкапов. То есть на обоих серверах раздел Content будет идентичным. Можно подключить pbs-remote к какому-то гипервизору и там проверять восстановление и запуск виртуальных машин. Это удобно делать, расположив PVE и PBS на одном железном сервере. Получается универсальный инструмент и для дополнительной копии бэкапов, и для их проверки.
Отдельно отмечу, что синхронизация хорошо переносит нестабильные соединения. Процесс не прерывается при разрывах связи и её отсутствии в течении нескольких минут. При возобновлении связи синхронизация продолжается.
Ту же самую процедуру синхронизации можно проводить в обратном направлении, то есть по модели Pull, когда удалённый сервер сам подключается к локальному и забирает данные. Можно всё это комбинировать. Например, VM бэкапятся в локальный Datastore, куда и них есть доступ. Потом на этом же PBS эти бэкапы по модели Pull копируются в рамках этого же сервера, но в другой Datastore, куда доступ ограничен. А с этого Datastore бэкапы по Pull или Push копируются на удалённый сервер.
Настройки очень гибкие и зависят от вашей инфраструктуры, режима параноидальности и доступного места для хранения. Напомню, что в каждом Datastore могут быть свои политики хранения бэкапов. Где-то храним 5 последних копий, а где-то 7 дневных копий, 4 недельных и 6 месячных. А куда-то складываем месячные и вообще не удаляем.
В 4-й версии PBS будет ещё пачка приятных нововведений. Например, хранение бэкапов в S3. И всё это бесплатно.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#proxmox #backup
Please open Telegram to view this post
VIEW IN TELEGRAM
13👍232👎2
Я уже ранее делал заметки на тему того, что не стоит рабочую нагрузку и бэкапы хранить только у одного хостера. Даже если он вполне стабилен и надёжен. Могут быть какие-то юридические, бухгалтерские проблемы или просто ошибки, которые приведут к тому, что вам случайно удалят или отключат учётную запись.
Ранее я видел только чужие истории на эту тему, а некоторое время назад столкнулся лично. В очередную пятницу закончил дела чуть раньше и пошёл отдыхать. А вечером от хостера приходит письмо на почту одного из клиентов, что его учётная запись удалена.
Я вечером субботы в районе 22-х часов зашёл проверить почту и не поверил своим глазам, когда увидел это письмо. По спине пробежал холодок. Внимательно проверил почту и номер клиента. Всё верно, это активная учётка с арендованными дедиками и рабочей нагрузкой.
Сразу же начал звонить на горячую линию, но там только автоответчик. Подождал минут 20, но оператора так и не дождался. Сделал заявку от другой учётной записи на тему этого инцидента. Техподдержка ответила достаточно быстро. Причину удаления назвать не смогли, но пообещали, что все сервера и услуги останутся активны как минимум до понедельника, когда вернётся профильный отдел и далее, если разбирательство продолжится.
Как вы уже поняли, сами серверы с гипервизорами и бэкапы VM были на этой учётной записи. Во вне уходили только бэкапы в виде файлов и дампов баз данных. Там объём большой и хранить на постоянной основе ещё и вторую копию виртуалок накладно. Но я на всякий случай скопировал и их.
В итоге всё обошлось. Услуги не отключились. В понедельник пришла профильная техподдержка и разобралась в ситуации. Как мне сказали, это была техническая ошибка. Личный кабинет восстановили. В итоге всё обошлось нормально, но я немного понервничал.
Очень важно читать почту от подобных услуг: домены, хостинги, может что-то ещё. У меня была история, когда заказчик пропустил письмо на тему удаления сервера и потерял его. За почтой никто не следил, но деньги исправно платили. Из-за каких-то технических нюансов в ЛК автопродление сервера слетело. И работающий сервер был успешно удалён. Причём без возможности восстановления.
Проблему сразу заметили, поддержка пообещала сервер вернуть, а потом написала, что он уже очищен. Это был полный абзац. Я тогда писал об этом заметку, но уже не помню когда точно. История несколько лет назад была.
Ну и по этой же теме вспоминаются истории, когда целые датацентры уходили в офлайн. Виной тому могут быть разные причины: технические в виде отключения света, связи, пожары (ovh), борьба собственников (ihor, masterhost), санкции и блокировки (hetzner, aws и т.д.). Бэкапы обязательно надо дублировать куда-то во вне. За всё время моей трудовой деятельности у двух моих заказчиков были пожары. У одного серверная не пострадала, а у другого сгорела полностью. Бэкапы были. В ihor я тоже в своё время потерял дедики. Оперативно переехал.
#хостинг #backup
Ранее я видел только чужие истории на эту тему, а некоторое время назад столкнулся лично. В очередную пятницу закончил дела чуть раньше и пошёл отдыхать. А вечером от хостера приходит письмо на почту одного из клиентов, что его учётная запись удалена.
Я вечером субботы в районе 22-х часов зашёл проверить почту и не поверил своим глазам, когда увидел это письмо. По спине пробежал холодок. Внимательно проверил почту и номер клиента. Всё верно, это активная учётка с арендованными дедиками и рабочей нагрузкой.
Сразу же начал звонить на горячую линию, но там только автоответчик. Подождал минут 20, но оператора так и не дождался. Сделал заявку от другой учётной записи на тему этого инцидента. Техподдержка ответила достаточно быстро. Причину удаления назвать не смогли, но пообещали, что все сервера и услуги останутся активны как минимум до понедельника, когда вернётся профильный отдел и далее, если разбирательство продолжится.
Как вы уже поняли, сами серверы с гипервизорами и бэкапы VM были на этой учётной записи. Во вне уходили только бэкапы в виде файлов и дампов баз данных. Там объём большой и хранить на постоянной основе ещё и вторую копию виртуалок накладно. Но я на всякий случай скопировал и их.
В итоге всё обошлось. Услуги не отключились. В понедельник пришла профильная техподдержка и разобралась в ситуации. Как мне сказали, это была техническая ошибка. Личный кабинет восстановили. В итоге всё обошлось нормально, но я немного понервничал.
Очень важно читать почту от подобных услуг: домены, хостинги, может что-то ещё. У меня была история, когда заказчик пропустил письмо на тему удаления сервера и потерял его. За почтой никто не следил, но деньги исправно платили. Из-за каких-то технических нюансов в ЛК автопродление сервера слетело. И работающий сервер был успешно удалён. Причём без возможности восстановления.
Проблему сразу заметили, поддержка пообещала сервер вернуть, а потом написала, что он уже очищен. Это был полный абзац. Я тогда писал об этом заметку, но уже не помню когда точно. История несколько лет назад была.
Ну и по этой же теме вспоминаются истории, когда целые датацентры уходили в офлайн. Виной тому могут быть разные причины: технические в виде отключения света, связи, пожары (ovh), борьба собственников (ihor, masterhost), санкции и блокировки (hetzner, aws и т.д.). Бэкапы обязательно надо дублировать куда-то во вне. За всё время моей трудовой деятельности у двух моих заказчиков были пожары. У одного серверная не пострадала, а у другого сгорела полностью. Бэкапы были. В ihor я тоже в своё время потерял дедики. Оперативно переехал.
#хостинг #backup
2👍101👎2
На канале в разное время было много упоминаний про консольную утилиту для бэкапа restic. Она популярна в последнее время, много статей и роликов видел с её участием. Не буду много про неё рассказывать, перечислю только основные плюсы. А далее покажу один практический пример.
▪️Есть под все популярные системы, состоит из одного бинарника на go, есть в базовых репозиториях.
▪️Все данные по умолчанию шифруются.
▪️Формат хранения данных в виде снепшотов с дедупликацией.
▪️Поддерживает хранилища: локальная директория, SFTP, S3, свой сервер rest с доступом по HTTP и некоторые другие.
▪️Встроенная проверка целостности данных.
▪️Все параметры можно передавать ключами и переменными.
Я покажу далее, как забэкапить данные с помощью restic в S3 бакет на примере хостера Selectel. Настройка будет плюс-минус идентичной для любого облачного провайдера. У меня S3 бэкапы лежат там, поэтому показываю на данном примере. У хостеров может быть немного запутанной схема предоставления доступа к бакетам, так что иногда приходится повозиться немного, если делаешь впервые.
1️⃣ Создаю бакет у провайдера. В данном случае иду в раздел Инфраструктура ⇨ S3 ⇨ Бакеты. Создаю новый:
◽️Тип бакета: Приватный
◽️Класс хранения: Холодное хранение
◽️Версионирование: отключено (restic сам будет заниматься версионированием)
◽️Тип адресации: vHosted
Далее в разделе Аккаунт ⇨ Сервисные пользователи добавляю нового пользователя, роль - Пользователь S3, Проект - выбранный проект, где создан бакет. Тут же перехожу во вкладку Доступ и создаю S3-ключи. Нужно записать Access key и Secret key. Они нам понадобятся при настройке Restic.
Возвращаюсь в настройки бакета, перехожу на вкладку Политика доступа, создаю политику, где выбираю полный доступ для только что созданного пользователя.
Бакет сделали, доступ настроили. Я получил следующие данные:
S3_HOST=https://s3.ru-1.storage.selcloud.ru
S3_BUCKET=restic55
ACCESS_KEY_ID=XXXXXXXXXX
SECRET_ACCESS_KEY=YYYYYYYYYY
2️⃣ Идём на сервер и устанавливаем Restic:
Параметры доступа к S3 и сам пароль от бэкапов задаются переменными окружения. Введём их, а перед этим отключим сохранение history, чтобы они там не осели:
Пароль
Теперь туда можно бэкапить:
Проверяем список бэкапов. В терминологии restic это snapshots:
У нас только один snapshot. Восстановим его:
В директории
Restic может автоматически ротировать снепшоты. Для этого у него есть набор ключей с гибкими настройками. Например:
🔹
🔹
🔹
И так далее для разных временных отрезков. Наглядный типовой пример политики хранения:
Храним 7 дневных бэкапов, 4 недельных, 12 месячных.
Вы можете написать свои bash костыли для Restic, а можете взять что-то готовое. Например, вот репозиторий, где есть скрипт для бэкапа в S3 с логированием, с некоторыми проверками, с хранением параметров и пароля доступа в отдельных файлах.
⇨ 🌐 Сайт / Исходники / Документация
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#backup #restic #s3
▪️Есть под все популярные системы, состоит из одного бинарника на go, есть в базовых репозиториях.
▪️Все данные по умолчанию шифруются.
▪️Формат хранения данных в виде снепшотов с дедупликацией.
▪️Поддерживает хранилища: локальная директория, SFTP, S3, свой сервер rest с доступом по HTTP и некоторые другие.
▪️Встроенная проверка целостности данных.
▪️Все параметры можно передавать ключами и переменными.
Я покажу далее, как забэкапить данные с помощью restic в S3 бакет на примере хостера Selectel. Настройка будет плюс-минус идентичной для любого облачного провайдера. У меня S3 бэкапы лежат там, поэтому показываю на данном примере. У хостеров может быть немного запутанной схема предоставления доступа к бакетам, так что иногда приходится повозиться немного, если делаешь впервые.
◽️Тип бакета: Приватный
◽️Класс хранения: Холодное хранение
◽️Версионирование: отключено (restic сам будет заниматься версионированием)
◽️Тип адресации: vHosted
Далее в разделе Аккаунт ⇨ Сервисные пользователи добавляю нового пользователя, роль - Пользователь S3, Проект - выбранный проект, где создан бакет. Тут же перехожу во вкладку Доступ и создаю S3-ключи. Нужно записать Access key и Secret key. Они нам понадобятся при настройке Restic.
Возвращаюсь в настройки бакета, перехожу на вкладку Политика доступа, создаю политику, где выбираю полный доступ для только что созданного пользователя.
Бакет сделали, доступ настроили. Я получил следующие данные:
S3_HOST=https://s3.ru-1.storage.selcloud.ru
S3_BUCKET=restic55
ACCESS_KEY_ID=XXXXXXXXXX
SECRET_ACCESS_KEY=YYYYYYYYYY
# apt install resticПараметры доступа к S3 и сам пароль от бэкапов задаются переменными окружения. Введём их, а перед этим отключим сохранение history, чтобы они там не осели:
# unset HISTFILE# export AWS_ACCESS_KEY_ID=XXXXXXXXXX# export AWS_SECRET_ACCESS_KEY=YYYYYYYYYY# export RESTIC_PASSWORD="ZZZZZZZZZZ"Пароль
RESTIC_PASSWORD нужно обязательно сохранить. Без него бэкапы не расшифровать, доступа к ним не будет. Инициализируем репозиторий:# restic init -r s3:https://s3.ru-1.storage.selcloud.ru/restic55Теперь туда можно бэкапить:
# restic backup -r s3:https://s3.ru-1.storage.selcloud.ru/restic55 /var/wwwПроверяем список бэкапов. В терминологии restic это snapshots:
# restic snapshots -r s3:https://s3.ru-1.storage.selcloud.ru/restic55....18eba378 2025-09-01 18:59:24 debian12-vm /var/www....У нас только один snapshot. Восстановим его:
# mkdir /tmp/restore# restic restore 18eba378 -r s3:https://s3.ru-1.storage.selcloud.ru/restic55 --target /tmp/restoreВ директории
/tmp/restore будут файлы этого снепшота. Restic может автоматически ротировать снепшоты. Для этого у него есть набор ключей с гибкими настройками. Например:
🔹
--keep-last N – последние N бэкапов🔹
--keep-daily N – для последних N дней, в которых есть один или несколько снимков, сохранять только самый последний снимок за каждый день🔹
--keep-within-daily duration – сохранять по одному последнему снимку, сделанному в течение указанного duration.И так далее для разных временных отрезков. Наглядный типовой пример политики хранения:
--keep-within-daily 7d --keep-within-weekly 1m --keep-within-monthly 1yХраним 7 дневных бэкапов, 4 недельных, 12 месячных.
Вы можете написать свои bash костыли для Restic, а можете взять что-то готовое. Например, вот репозиторий, где есть скрипт для бэкапа в S3 с логированием, с некоторыми проверками, с хранением параметров и пароля доступа в отдельных файлах.
⇨ 🌐 Сайт / Исходники / Документация
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#backup #restic #s3
Please open Telegram to view this post
VIEW IN TELEGRAM
👍126👎4
backup-postgresql-restic.sh
2.1 KB
🔥 Бэкап баз postgresql с помощью restic!
Вновь возвращаюсь к очень удобному инструменту для бэкапов restic. Последнее время часто стал его использовать. Дальше вы поймёте, почему. На создание бэкапов баз данных с его помощью меня навела вот эта статья:
⇨ Restic: эффективное резервное копирование из Stdin
Автор с помощью restic дампит базы данных в Kubernetes. Я немного переделал его решение для своих локальных бэкапов. Основная проблема, которая там решена - корректная отработка ошибок снятия дампа. Я до этого сам не догадался, правда не сильно и пытался, поэтому дампил по старинке сначала в файл, проверял, а потом уже куда-то на хранение отправлял.
Но можно всё это сделать на лету и с проверкой ошибок. То есть делается дамп и тут же через pipe отправляется в restic. Этот способ удобен по нескольким причинам:
1️⃣ Самое основное - сырые дампы в restic очень хорошо дедуплицируются и экономят место. Если между дампами небольшие изменения, то даже хранение большого количества файлов за разные дни не съедает место на хранилище в отличие от обычного хранения в исходном виде на файловой системе.
2️⃣ Прямая отправка данных с pg_dump в restic исключает промежуточное сохранение, что существенно экономит ресурс SSD дисков, если у вас много баз приличного размера. Да и банально быстрее получается.
3️⃣ Если во время снятия дампа будет ошибка, то такой бэкап помечается отдельным тэгом и по этому тэгу вы сможете понять, что у вас какая-то проблема. Я специально проверил этот момент. Отрабатывает корректно. Если дамп прерывается по какой-то причине и не завершается без ошибок, то этот бэкап помечается отдельным тэгом.
В статье у автора подробно всё рассказано, не буду на этом останавливаться. Покажу свой итоговый скрипт, который бэкапит дампы условно локально, а не в S3. Если надо в S3 или куда-то ещё, то просто измените переменную
Надо убрать ключ
Это, как я понял, связано с тем, что ключ
И ещё важный момент. Не забудьте сохранить пароль от репозитория, который тоже задаётся в скрипте. Так как пароль передаётся в виде переменной окружения, его можно хранить где-то отдельно и подгружать перед запуском основного скрипта. Я в предыдущей заметке про restic упоминал об этом и показывал пример в конце.
Сам скрипт прикрепил к сообщению. Также продублировал его в публичный репозиторий. Не забудьте поменять переменные под свои нужды и окружение.
Полезные материалы по теме:
▪️Описание Restic с примерами
▪️Мониторинг Restic с помощью Zabbix и Prometheus
▪️Бэкап с помощью Restic в S3 на примере Selectel
Restic очень удобный инструмент для бэкапов. Рекомендую присмотреться.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#backup #postgresql #restic
Вновь возвращаюсь к очень удобному инструменту для бэкапов restic. Последнее время часто стал его использовать. Дальше вы поймёте, почему. На создание бэкапов баз данных с его помощью меня навела вот эта статья:
⇨ Restic: эффективное резервное копирование из Stdin
Автор с помощью restic дампит базы данных в Kubernetes. Я немного переделал его решение для своих локальных бэкапов. Основная проблема, которая там решена - корректная отработка ошибок снятия дампа. Я до этого сам не догадался, правда не сильно и пытался, поэтому дампил по старинке сначала в файл, проверял, а потом уже куда-то на хранение отправлял.
Но можно всё это сделать на лету и с проверкой ошибок. То есть делается дамп и тут же через pipe отправляется в restic. Этот способ удобен по нескольким причинам:
В статье у автора подробно всё рассказано, не буду на этом останавливаться. Покажу свой итоговый скрипт, который бэкапит дампы условно локально, а не в S3. Если надо в S3 или куда-то ещё, то просто измените переменную
REPO_PREFIX в скрипте и добавьте переменных для доступа к бакетам. Плюс, я поменял формат хранения данных. Вместо tar выгружаю в текстовый sql файл. Мне так удобнее. Ещё исправил там небольшую ошибку, которую выявил во время тестов. В строке:restic forget -r "${REPO_PREFIX}/$db" --group-by=tags --keep-tag "completed"Надо убрать ключ
--group-by=tags, иначе команда на очистку будет возвращать ошибку:refusing to delete last snapshot of snapshot group "tags [job-8dd4f544]"Это, как я понял, связано с тем, что ключ
--keep-tag не позволяет удалить при группировке по тэгам полную группу тэгов, если в ней не останется хотя бы одного снепшота. А так как у нас все тэги с job уникальны, все проблемные снепшоты будут с уникальными тэгами и по сути одни в группе. Поэтому группировку --group-by=tags надо убрать. По крайней мере у меня, когда я убрал, ошибка ушла и очистка стала нормально отрабатывать. В доках это так объясняется: "The forget command will exit with an error if all snapshots in a snapshot group would be removed as none of them have the specified tags."И ещё важный момент. Не забудьте сохранить пароль от репозитория, который тоже задаётся в скрипте. Так как пароль передаётся в виде переменной окружения, его можно хранить где-то отдельно и подгружать перед запуском основного скрипта. Я в предыдущей заметке про restic упоминал об этом и показывал пример в конце.
Сам скрипт прикрепил к сообщению. Также продублировал его в публичный репозиторий. Не забудьте поменять переменные под свои нужды и окружение.
Полезные материалы по теме:
▪️Описание Restic с примерами
▪️Мониторинг Restic с помощью Zabbix и Prometheus
▪️Бэкап с помощью Restic в S3 на примере Selectel
Restic очень удобный инструмент для бэкапов. Рекомендую присмотреться.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#backup #postgresql #restic
Please open Telegram to view this post
VIEW IN TELEGRAM
2👍110👎1
К заметкам про Restic уже не раз упоминали веб панель к нему Backrest. У меня были большие надежды на эту панель, но они не оправдались. Я почему-то думал, что это будет панель для управления множеством распределённых по хостам экземплярам Restic. Он работает по модели push, то есть сам отправляет данные в репозиторий и поэтому должен быть установлен локально.
С такой архитектурой затруднено централизованное управление. Это должна быть какая-то сторонняя система для установки самого restic, раскатки конфигураций на него и отслеживания выполнений заданий бэкапа. Для этого, к примеру, подойдёт Ansible Semaphore.
Я рассчитывал увидеть подобную панель, но с акцентом именно на возможности restic. Но увы. Backrest не про это. С её помощью можно настраивать только локальный бэкап на конкретном одиночном хосте. Для меня вообще неактуальна подобная функциональность, потому что я предпочитаю такие вещи настраивать в консоли на скриптах.
Тем не менее, я развернул Backrest и попробовал. Она вполне удобна для тех, кому нужен веб интерфейс для настройки. Одним из явных удобств этой панели будет возможность просматривать и скачивать файлы из снепшотов в репозиотрии. Да и просто просмотр выполненных заданий и содержимое репозитория в браузере выглядит наглядно и удобно.
Запустить Backrest можно как локально, установив вручную из бинарника и создав службу, так и автоматически в Doсker Compose. Я выбрал второе. Немного доработал пример из репозитория. Получилось вот так:
Обращаю внимание на подключаемую директорию
◽️id_ed25519 - приватный ключ для доступа к серверу, делаем так:
id_ed25519.pub добавляем на удалённом сервере в
◽️known_hosts - файл с открытым ключом удалённого сервера. Подключитесь к нему с какого-нибудь сервера, а потом скопируйте сохранённую строку из
После запуска контейнера можно идти на порт 9898 и настраивать бэкап через браузер. Первым делом надо добавить Repo. Для SFTP строка Repository URI будет примерно такая:
После этого можно создавать задание для бэкапа. Я в своём примере бэкаплю директорию
Примеры настроек Repo и задания для бэкапа показал внизу на картинках.
Теперь можно либо вручную сделать бэкап здесь же, либо дождаться планировщика. Перейдя в репозиторий, можно посмотреть Snapshots уже сделанных бэкапов, увидеть список файлов в них и по желанию что-то восстановить. Для восстановления удобно использовать директорию tmp, которую добавили в compose.
В целом нормальная, удобная панель, если для вас актуальна такая функциональность. Будет хорошим решением локальных бэкапов для тех, у кого рабочая машина на Linux. Для бэкапа и восстановления файлов с серверов, я думаю, можно обойтись и без веб интерфейса.
⇨ 🌐 Сайт / Исходники
#backup #restic
С такой архитектурой затруднено централизованное управление. Это должна быть какая-то сторонняя система для установки самого restic, раскатки конфигураций на него и отслеживания выполнений заданий бэкапа. Для этого, к примеру, подойдёт Ansible Semaphore.
Я рассчитывал увидеть подобную панель, но с акцентом именно на возможности restic. Но увы. Backrest не про это. С её помощью можно настраивать только локальный бэкап на конкретном одиночном хосте. Для меня вообще неактуальна подобная функциональность, потому что я предпочитаю такие вещи настраивать в консоли на скриптах.
Тем не менее, я развернул Backrest и попробовал. Она вполне удобна для тех, кому нужен веб интерфейс для настройки. Одним из явных удобств этой панели будет возможность просматривать и скачивать файлы из снепшотов в репозиотрии. Да и просто просмотр выполненных заданий и содержимое репозитория в браузере выглядит наглядно и удобно.
Запустить Backrest можно как локально, установив вручную из бинарника и создав службу, так и автоматически в Doсker Compose. Я выбрал второе. Немного доработал пример из репозитория. Получилось вот так:
services:
backrest:
image: garethgeorge/backrest:latest
container_name: backrest
hostname: backrest
volumes:
- ./backrest/data:/data
- ./backrest/config:/config
- ./backrest/cache:/cache
- ./backrest/tmp:/tmp # для восстановления бэкапов
- ./.ssh:/root/.ssh # для доступа к repo по sftp
- /path/to/local/repos:/userdata # локальная директория, которая бэкапится
- /path/to/local/repos:/repos # для использования в качестве local repo
environment:
- BACKREST_DATA=/data
- BACKREST_CONFIG=/config/config.json
- XDG_CACHE_HOME=/cache
- TMPDIR=/tmp
- TZ=Europe/Moscow
ports:
- "9898:9898"
restart: unless-stopped
Обращаю внимание на подключаемую директорию
.ssh. Она нужна для подключения репозитория по SFTP. По мне, так это самый простой и удобный способ подключиться к удалённому хосту для хранения бэкапов на нём. В этой директории должны быть 2 файла: ◽️id_ed25519 - приватный ключ для доступа к серверу, делаем так:
# ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519 -C "$(whoami)@$(hostname)_$(date -I)"id_ed25519.pub добавляем на удалённом сервере в
authorized_keys.◽️known_hosts - файл с открытым ключом удалённого сервера. Подключитесь к нему с какого-нибудь сервера, а потом скопируйте сохранённую строку из
known_hosts в этот файл. После запуска контейнера можно идти на порт 9898 и настраивать бэкап через браузер. Первым делом надо добавить Repo. Для SFTP строка Repository URI будет примерно такая:
sftp:user@10.20.1.24:/mnt/backup. Остальные параметры указывайте по потребностям.После этого можно создавать задание для бэкапа. Я в своём примере бэкаплю директорию
/var/log, которую примапил в композ файле к /userdata.Примеры настроек Repo и задания для бэкапа показал внизу на картинках.
Теперь можно либо вручную сделать бэкап здесь же, либо дождаться планировщика. Перейдя в репозиторий, можно посмотреть Snapshots уже сделанных бэкапов, увидеть список файлов в них и по желанию что-то восстановить. Для восстановления удобно использовать директорию tmp, которую добавили в compose.
В целом нормальная, удобная панель, если для вас актуальна такая функциональность. Будет хорошим решением локальных бэкапов для тех, у кого рабочая машина на Linux. Для бэкапа и восстановления файлов с серверов, я думаю, можно обойтись и без веб интерфейса.
⇨ 🌐 Сайт / Исходники
#backup #restic
👍50👎5
Недавно поднимал тему переезда домена от одного регистратора к другому. Косвенно захватил тему переноса DNS записей. У меня уже ранее была один раз ситуация, когда я по какой-то причине потерял DNS записи, которые пришлось восстанавливать. Уже не помню подробностей истории. Ещё тогда я подумал, что неплохо бы было их забэкапить в любом виде, просто чтобы было.
В то время вопрос не проработал и ничего не сделал. Это не такая уж критическая информация, если у вас не десятки поддоменов и каких-то специфических сервисов со своими TXT записями. Можно всё восстановить вручную, но придётся вспоминать и открывать разные источники. На это уйдёт время. Проще будет, если хоть в каком-то виде вся эта информация будет храниться с обновлением хотя бы раз в месяц.
Решил посмотреть, есть ли какие готовые решения на этот счёт. Вот что нашёл.
◽️octoDNS - утилита, которая хранит настройки DNS записей в формате yaml и имеет интеграцию с публичными провайдерами или локальными DNS серверами. Поддерживает многих популярных западный провайдеров, типа Amazon Route 53, Azure DNS, Cloudflare DNS и т.д. и ни одного российского. По факту это не только бэкап конфигурации, но и управление. То есть типичный подход инфраструктуры как код с хранением DNS зон в GIT. С помощью octoDNS записи можно переносить от одного провайдера к другому.
◽️DNSControl - примерно то же самое, что и octoDNS, но зоны хранятся в формате языка программирования JavaScript. Не кажется это удобным. Не знаю, почему так сделано. По возможностям и интеграциям не увидел принципиальной разницы с octoDNS.
Для российских хостеров эти утилиты не подходят. Надо либо модуль интеграции самим писать, либо использовать что-то другое. Можно пойти более простым путём.
◽️Бэкап записей через API. Почти у всех крупных провайдеров есть API для управления зонами. ИИ без проблем напишет интеграцию. Достаточно скормить ему документацию и сказать, что тебе нужно. Я проверил на примере Selectel.
Но тут возникает другой вопрос. Для доступа к зонам нужен токен. Если зоны на разных учётках или у разных хостеров, то муторно настраивать везде доступы. Если задача не добавлять или менять записи, а только смотреть, доступ через API не особо нужен. Это публичные данные, которые можно прочитать напрямую.
◽️Бэкап записей через dig. Можно взять любую утилиту для просмотра DNS записей и сохранить её вывод. В Linux для этого обычно используют dig. Смотреть можно так:
Достаточно сохранить вывод для всех зон, вот тебе и бэкап. По типам записей и доменам можно пройтись в цикле:
Получается аккуратный список DNS записей доменов. У этого способа есть один существенный минус - все поддомены надо добавлять вручную. Нет возможности получить точный публичный список поддоменов. Его придётся вести вручную. Напрямую все поддомены забрать можно только у DNS хостера через его API. Так что выбирайте сами, какой способ вам больше подойдёт.
Я остановился на подобном скрипте. Мне его хватает. Буду запускать раз в неделю на бэкап сервере с консолью Linux.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
———
ServerAdmin:📱 Telegram | 🌐 Сайт | 📲 MAX
#dns #backup
В то время вопрос не проработал и ничего не сделал. Это не такая уж критическая информация, если у вас не десятки поддоменов и каких-то специфических сервисов со своими TXT записями. Можно всё восстановить вручную, но придётся вспоминать и открывать разные источники. На это уйдёт время. Проще будет, если хоть в каком-то виде вся эта информация будет храниться с обновлением хотя бы раз в месяц.
Решил посмотреть, есть ли какие готовые решения на этот счёт. Вот что нашёл.
◽️octoDNS - утилита, которая хранит настройки DNS записей в формате yaml и имеет интеграцию с публичными провайдерами или локальными DNS серверами. Поддерживает многих популярных западный провайдеров, типа Amazon Route 53, Azure DNS, Cloudflare DNS и т.д. и ни одного российского. По факту это не только бэкап конфигурации, но и управление. То есть типичный подход инфраструктуры как код с хранением DNS зон в GIT. С помощью octoDNS записи можно переносить от одного провайдера к другому.
◽️DNSControl - примерно то же самое, что и octoDNS, но зоны хранятся в формате языка программирования JavaScript. Не кажется это удобным. Не знаю, почему так сделано. По возможностям и интеграциям не увидел принципиальной разницы с octoDNS.
Для российских хостеров эти утилиты не подходят. Надо либо модуль интеграции самим писать, либо использовать что-то другое. Можно пойти более простым путём.
◽️Бэкап записей через API. Почти у всех крупных провайдеров есть API для управления зонами. ИИ без проблем напишет интеграцию. Достаточно скормить ему документацию и сказать, что тебе нужно. Я проверил на примере Selectel.
Но тут возникает другой вопрос. Для доступа к зонам нужен токен. Если зоны на разных учётках или у разных хостеров, то муторно настраивать везде доступы. Если задача не добавлять или менять записи, а только смотреть, доступ через API не особо нужен. Это публичные данные, которые можно прочитать напрямую.
◽️Бэкап записей через dig. Можно взять любую утилиту для просмотра DNS записей и сохранить её вывод. В Linux для этого обычно используют dig. Смотреть можно так:
# dig ya.ru A +noall +answer# dig ya.ru MX +noall +answer# dig ya.ru TXT +noall +answerДостаточно сохранить вывод для всех зон, вот тебе и бэкап. По типам записей и доменам можно пройтись в цикле:
#!/usr/bin/env bash
DOMAINS_LIST="domains.txt"
BACKUP_DIR="./dns_backups"
mkdir -p "$BACKUP_DIR"
DATE=$(date +%F_%H%M%S)
for DOMAIN in $(cat "$DOMAINS_LIST"); do
OUTFILE="${BACKUP_DIR}/${DOMAIN}_${DATE}.zone"
echo "### $DOMAIN ###" > "$OUTFILE"
for TYPE in NS A AAAA CNAME MX TXT SRV; do
echo "" >> "$OUTFILE"
echo "### $TYPE ###" >> "$OUTFILE"
dig "$DOMAIN" "$TYPE" +noall +answer >> "$OUTFILE"
done
echo "saved: $OUTFILE"
done
Получается аккуратный список DNS записей доменов. У этого способа есть один существенный минус - все поддомены надо добавлять вручную. Нет возможности получить точный публичный список поддоменов. Его придётся вести вручную. Напрямую все поддомены забрать можно только у DNS хостера через его API. Так что выбирайте сами, какой способ вам больше подойдёт.
Я остановился на подобном скрипте. Мне его хватает. Буду запускать раз в неделю на бэкап сервере с консолью Linux.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
———
ServerAdmin:
#dns #backup
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
1👍92👎4
Недавно по лентам каналов проскочил анонс бесплатной программы для бэкапа и переноса почты из почтовых ящиков - Mail-Archiver. Тема интересная и актуальная, потому что такого рода программ практически нет. Я обычно новый софт смотрю, прикидываю, будет ли он мне полезен и откладываю на полгода-год, чтобы настоялся. Если получает развитие, то пробую, если разработка не продолжается, то забываю.
Про Mail-Archiver впервые услышал в видеообзоре, который был в недавней подборке. Когда мне нужно забэкапить или перенести почтовый ящик с почтового сервера, который я не обслуживаю, и, соответственно, не имею напрямую доступ к исходникам писем, то беру imapsync. Это простой и надёжный инструмент, который позволяет по imap забирать почту с одного почтового сервера и складывать на другой. Для бэкапа достаточно поднять свой вспомогательный imap сервер, который примет почту. В своё время делал большие миграции с бесплатной почты для домена от Яндекс на другие сервера, когда первый убрал бесплатные тарифы.
Возвращаюсь к Mail-Archiver. Это веб интерфейс к сборщику почты из ящиков по протоколу imap. Я его попробовал. Поставить очень просто. В репозитории есть готовый
Внешне веб интерфейс собран на базе какого-то типового фреймворка для админок. Выглядит для своих задач нормально. Настойка максимально простая:
1️⃣ Добавляете новый почтовый ящик, указав имя сервера, логин, пароль, imap порт.
2️⃣ Запускаете вручную синхронизацию.
3️⃣ Смотрите почту через веб интерфейс панели. Можете сразу по всем добавленным ящикам в едином списке. В некоторых случаях это может оказаться полезным. Либо же выбираете отдельно ящики или конкретные папки в них.
4️⃣ При желании архив можно выгрузить в формате EML или MBox, предварительно сжав в ZIP. С большими ящиками скорее всего будут проблемы.
5️⃣ Все письма из одного ящика можно скопировать в другой. В том числе в отдельную папку. То есть можно на каком-то почтовом сервере для бэкапов сделать общий ящик и складывать туда в каждую папку письма какого-то отдельного ящика.
В целом панелька удобная. Я без проблем всё настроил. Но есть несколько важных нюансов:
1️⃣ Синхронизация писем идёт медленно. В среднем из ящика забирает 1-2 письма в секунду. Большие ящики будут очень долго синхронизироваться.
2️⃣ Вся почта хранится в SQL базе, конкретно в PostgreSQL. В целом это неплохо с точки зрения быстрого поиска по большому архиву. Но накладывает соответствующие требования к процессору и дискам, чтобы переваривать большие объёмы почты. Вообще не понятно, как эта панель будет работать, если туда загрузить несколько ящиков гигабайт по 50. У меня, к примеру, в обслуживании, таких полно.
3️⃣ Нет настраиваемых задач для регулярного бэкапа. Он запускается только вручную или по какому-то своему расписанию раз в 15 минут. Я вроде всё проверил, и панель, и документацию. Не нашёл, как этим управлять. Странно, что не сделали настраиваемый планировщик. Он тут напрашивается.
Mail-Archiver неплохо решает заданную задачу. Для личного использования или набора ящиков небольших объёмов будет удобен. Для больших почтовых ящиков и серверов, скорее всего не подойдёт. Но там странно было бы надеяться на бэкап через imap. Большие ящики надо бэкапить с уровня хранилища почты.
Отдельно отмечу возможность создавать учётные записи пользователей самой панели, к которым можно добавлять разные почтовые ящики с общим поиском по ним. Для каких-то задач это может быть простым и удобным решением.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
———
ServerAdmin:📱 Telegram | 🌐 Сайт | 📲 MAX
#mailserver #backup
Про Mail-Archiver впервые услышал в видеообзоре, который был в недавней подборке. Когда мне нужно забэкапить или перенести почтовый ящик с почтового сервера, который я не обслуживаю, и, соответственно, не имею напрямую доступ к исходникам писем, то беру imapsync. Это простой и надёжный инструмент, который позволяет по imap забирать почту с одного почтового сервера и складывать на другой. Для бэкапа достаточно поднять свой вспомогательный imap сервер, который примет почту. В своё время делал большие миграции с бесплатной почты для домена от Яндекс на другие сервера, когда первый убрал бесплатные тарифы.
Возвращаюсь к Mail-Archiver. Это веб интерфейс к сборщику почты из ящиков по протоколу imap. Я его попробовал. Поставить очень просто. В репозитории есть готовый
docker-compose.yml. Если не хотите менять стандартные учётки, то можно вообще ничего не менять в файле. Я только свой часовой пояс указал.Внешне веб интерфейс собран на базе какого-то типового фреймворка для админок. Выглядит для своих задач нормально. Настойка максимально простая:
В целом панелька удобная. Я без проблем всё настроил. Но есть несколько важных нюансов:
Mail-Archiver неплохо решает заданную задачу. Для личного использования или набора ящиков небольших объёмов будет удобен. Для больших почтовых ящиков и серверов, скорее всего не подойдёт. Но там странно было бы надеяться на бэкап через imap. Большие ящики надо бэкапить с уровня хранилища почты.
Отдельно отмечу возможность создавать учётные записи пользователей самой панели, к которым можно добавлять разные почтовые ящики с общим поиском по ним. Для каких-то задач это может быть простым и удобным решением.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
———
ServerAdmin:
#mailserver #backup
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
👍95👎2