К заметкам про 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