Давно не было публикаций на тему инструментов для бэкапа. Одно время я очень много их описал. Практически всё полезное и популярное. Их можно найти по тэгу #backup или почитать подборку на сайте. Правда, там не всё, так как были новые обзоры после выхода статьи.
В поле моего зрения попала полезная консольная утилита restic, решил её посмотреть и поделиться информацией с вами, так как она показалась мне заслуживающей внимание.
В первую очередь это open source проект и весьма популярный:
https://github.com/restic/restic. Для установки достаточно скачать бинарник из репозитория. Он написан на Go. На каких-то системах, например Debian, он есть в базовых репах. Основные возможности:
- все данные шифруются AES256, сам ключ шифруется паролем;
- нет деления на типы бэкапов: полные, инкрементные, дифференциальные, вместо этого используются снепшоты, соответственно работает дедупликация;
- различные хранилища для архивируемых данных: локальная директория, sftp, S3, HTTP REST server, OpenStack Swift, BackBlaze B2, Microsoft Azure Blob Storage, Google Cloud Storage;
- помимо прямого подключения к хранилищам, есть поддержка rclone;
- встроенная проверка целостности данных.
Restic режет данные на блоки настраиваемой длины, блоки собираются в паки. Паки хранят в себе файлы и метаданные, либо ссылки на другие блоки. Всё это выстраивается в деревья. Таким образом работают снепшоты и экономится место под бэкапы.
Покажу пример, как с помощью restic делаются бэкапы. Сначала инициализируется локальный репозиторий:
В этот момент будет сгенерирован ключ для шифрования и создана структура каталогов репозитория. Пример для инициализации репозитория по sftp:
Бэкапим:
Смотрим список снепшотов в репозитории:
Смотрим список файлов в снепшоте:
Восстанавливаем файлы:
Для всех операций поддерживаются списки include или exclude. Есть команды для быстрого сравнения снепшотов.
Думаю, вы получили представление, как всё это работает. Утилита консольная и хорошо подойдёт для скриптов. Авторы говорят, что Restic очень быстро работает. Я тестов не проводил. Из неудобств отметил то, что Restic надо ставить на сам хост, где лежат данные. Из документации я не понял, как с одного сервера с Restic забирать данные по ssh с других серверов.
Мне Restic сильно напомнил Borg. Подозреваю, что проблемы у него будут те же. Например, как будет выглядеть листинг снепшота, где хранится 500 тысяч файлов? Но в целом выглядит интересно. Основная фишка - снепшоты и дедупликация из коробки и бесплатно. Есть хорошая документация с практическими примерами.
Сайт - https://restic.net/
Исходники - https://github.com/restic/restic
Документация - https://restic.readthedocs.io/en/latest/
#backup #restic
В поле моего зрения попала полезная консольная утилита restic, решил её посмотреть и поделиться информацией с вами, так как она показалась мне заслуживающей внимание.
В первую очередь это open source проект и весьма популярный:
https://github.com/restic/restic. Для установки достаточно скачать бинарник из репозитория. Он написан на Go. На каких-то системах, например Debian, он есть в базовых репах. Основные возможности:
- все данные шифруются AES256, сам ключ шифруется паролем;
- нет деления на типы бэкапов: полные, инкрементные, дифференциальные, вместо этого используются снепшоты, соответственно работает дедупликация;
- различные хранилища для архивируемых данных: локальная директория, sftp, S3, HTTP REST server, OpenStack Swift, BackBlaze B2, Microsoft Azure Blob Storage, Google Cloud Storage;
- помимо прямого подключения к хранилищам, есть поддержка rclone;
- встроенная проверка целостности данных.
Restic режет данные на блоки настраиваемой длины, блоки собираются в паки. Паки хранят в себе файлы и метаданные, либо ссылки на другие блоки. Всё это выстраивается в деревья. Таким образом работают снепшоты и экономится место под бэкапы.
Покажу пример, как с помощью restic делаются бэкапы. Сначала инициализируется локальный репозиторий:
restic init -r /mnt/backupВ этот момент будет сгенерирован ключ для шифрования и создана структура каталогов репозитория. Пример для инициализации репозитория по sftp:
restic init -r sftp:user@host:/mnt/backupБэкапим:
restic -r sftp:user@host:/mnt/backup backup /dataСмотрим список снепшотов в репозитории:
restic -r sftp:user@host:/mnt/backup snaphotsСмотрим список файлов в снепшоте:
restic -r sftp:user@host:/mnt/backup ls -l latestВосстанавливаем файлы:
restic -r sftp:user@host:/mnt/backup restore latest \--target=/restore/Для всех операций поддерживаются списки include или exclude. Есть команды для быстрого сравнения снепшотов.
Думаю, вы получили представление, как всё это работает. Утилита консольная и хорошо подойдёт для скриптов. Авторы говорят, что Restic очень быстро работает. Я тестов не проводил. Из неудобств отметил то, что Restic надо ставить на сам хост, где лежат данные. Из документации я не понял, как с одного сервера с Restic забирать данные по ssh с других серверов.
Мне Restic сильно напомнил Borg. Подозреваю, что проблемы у него будут те же. Например, как будет выглядеть листинг снепшота, где хранится 500 тысяч файлов? Но в целом выглядит интересно. Основная фишка - снепшоты и дедупликация из коробки и бесплатно. Есть хорошая документация с практическими примерами.
Сайт - https://restic.net/
Исходники - https://github.com/restic/restic
Документация - https://restic.readthedocs.io/en/latest/
#backup #restic
👍26👎4
Напоминаю про очень функциональное и удобное решение для бэкапов — Restic. Часто вижу его упоминание в различных выступлениях и интервью. Я уже делал про него заметку, хочу дополнить информацию. Кратко перечислю плюсы ➕ :
🔹простая установка, так как это всего лишь один бинарник, написанный на GO, есть в репозитории Debian
🔹очень хорошая производительность
🔹поддержка дедупликации, снепшотов на уровне данных
🔹разные бэкенды для хранения: локальная директория, sftp, S3, rclone и т.д.
🔹проверка целостности, шифрование
Утилита подойдёт как для разовых бэкапов небольшой инфраструктуры, так и для централизованного хранения архивных копий за счёт того, что легко интегрируется, распространяется и мониторится. Про мониторинг как раз хотел дополнить.
Для Prometheus есть готовый экспортёр метрик — restic-exporter. Указываете репозиторий, пароль к нему и получаете на выходе полезные метрики: статус проверок, количество снэпшотов, время последнего бэкапа, кол-во файлов в бэкапе, их размер и т.д. А бонусом идёт дашборд для Grafana.
Zabbix тоже имеет готовый шаблон для мониторинга за бэкапами, сделанными Restic. Его написали не разработчики, так как он в отдельном репозитории community-templates, но, тем не менее, они за ним следят и актуализируют к свежим версиям. Мониторинг работает через прокладку resticprofile, которая формирует конфигурационные файлы для бэкапов и умеет сохранять результаты работы в json файл.
Есть ещё один вариант для Zabbix — шаблон, который анализирует стандартный вывод от команды на бэкап или проверку архива. Для этого вывод нужно сохранять в лог файл, а потом скриптом его анализировать и отправлять результат через zabbix_sender. В указанном репозитории есть все примеры — шаблон и скрипты.
Вообще, решение с Prometheus выглядит более целостным, простым и удобным. Если бы мне сейчас нужно было мониторить бэкапы Restic, я бы взял именно его. А если всё же нужен Zabbix, то распарсил бы промовский экспортер. Там буквально, запускаем контейнер с restic-exporter и смотрим метрики:
Очень просто и удобно.
#backup #restic
🔹простая установка, так как это всего лишь один бинарник, написанный на GO, есть в репозитории Debian
🔹очень хорошая производительность
🔹поддержка дедупликации, снепшотов на уровне данных
🔹разные бэкенды для хранения: локальная директория, sftp, S3, rclone и т.д.
🔹проверка целостности, шифрование
Утилита подойдёт как для разовых бэкапов небольшой инфраструктуры, так и для централизованного хранения архивных копий за счёт того, что легко интегрируется, распространяется и мониторится. Про мониторинг как раз хотел дополнить.
Для Prometheus есть готовый экспортёр метрик — restic-exporter. Указываете репозиторий, пароль к нему и получаете на выходе полезные метрики: статус проверок, количество снэпшотов, время последнего бэкапа, кол-во файлов в бэкапе, их размер и т.д. А бонусом идёт дашборд для Grafana.
Zabbix тоже имеет готовый шаблон для мониторинга за бэкапами, сделанными Restic. Его написали не разработчики, так как он в отдельном репозитории community-templates, но, тем не менее, они за ним следят и актуализируют к свежим версиям. Мониторинг работает через прокладку resticprofile, которая формирует конфигурационные файлы для бэкапов и умеет сохранять результаты работы в json файл.
Есть ещё один вариант для Zabbix — шаблон, который анализирует стандартный вывод от команды на бэкап или проверку архива. Для этого вывод нужно сохранять в лог файл, а потом скриптом его анализировать и отправлять результат через zabbix_sender. В указанном репозитории есть все примеры — шаблон и скрипты.
Вообще, решение с Prometheus выглядит более целостным, простым и удобным. Если бы мне сейчас нужно было мониторить бэкапы Restic, я бы взял именно его. А если всё же нужен Zabbix, то распарсил бы промовский экспортер. Там буквально, запускаем контейнер с restic-exporter и смотрим метрики:
# docker run -d \ --name=restic-exporter \ -v /mnt/backup:/data -e TZ=Europe/Moscow \ -e RESTIC_REPO_URL=/data \ -e RESTIC_REPO_PASSWORD=123 \ -e REFRESH_INTERVAL=60 \ -p 8001:8001 \ --restart unless-stopped \ ngosang/restic-exporter# curl http://localhost:8001Очень просто и удобно.
#backup #restic
👍57👎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
👍127👎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👍111👎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