ServerAdmin.ru

К заметкам про Restic уже не раз упоминали веб панель к нему Backrest. У меня были большие надежды на эту панель, но они не оправдались. Я почему-то думал, что это будет панель для управления множеством распределённых по хостам экземплярам Restic. Он работает по модели push, то есть сам отправляет данные в репозиторий и поэтому должен быть установлен локально.

С такой архитектурой затруднено централизованное управление. Это должна быть какая-то сторонняя система для установки самого 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

👍51👎5

11.3K views06:11

ServerAdmin.ru

Недавно поднимал тему переезда домена от одного регистратора к другому. Косвенно захватил тему переноса 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. Смотреть можно так:

# 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: 📱 Telegram | 🌐 Сайт | 📲 MAX

#dns #backup

Please open Telegram to view this post