Недавно впервые услышал про новую для меня систему резервного копирования Minarca Backup. Беглый осмотр показал, что это что-то интересное, поэтому решил попробовать. Кратко скажу, что это open source клиент-серверная система с веб интерфейсом управления и локальными клиентами, которые нужно устанавливать на целевые машины, с которых снимается бэкап.
📌 Сделаю краткий акцент на основных моментах системы:
▪️сервер и клиенты можно установить на Liniux, Windows, MacOS;
▪️можно развернуть на своём железе;
▪️управление через cli или веб интерфейс;
▪️репозитории для хранения подключаются как локальные папки сервера;
▪️управлять доступом к бэкапам можно на уровне пользователей, поддерживается LDAP каталог для них, дисковые квоты;
▪️есть 2FA с отправкой кодов подтверждения на email;
▪️для установки сервера есть репозиторий с пакетами;
▪️данные от клиента на сервер передаются по протоколу HTTP с аутентификацией;
▪️бэкап выполняется на уровне файлов, нет возможности забэкапить всю систему разом или сделать образ диска;
▪️инициирует передачу данных на сервер сам клиент;
▪️клиент может самостоятельно инициировать восстановление своих файлов.
Установка сервера очень простая и типичная для готовых пакетов Debian:
Судя по зависимостям серверной части, Minarca Backup построена на базе rdiff-backup. Который, в свою очередь, является python обёрткой вокруг rsync (используется библиотека librsync). Она наследует всю скорость и быстроту синхронизации сотен тысяч файлов, которую обеспечивает rsync. Это чтобы вы понимали, что там под капотом и чего стоит ждать от этой системы. Как по мне, так это плюс, что там rsync используется. Для бэкапа сырых файлов без дедупликации это хорошее, а может и лучшее решение.
Теперь идём по IP адресу на порт 8080 и используем учётную запись: admin / admin123. По умолчанию веб интерфейс открылся на русском языке.
После этого сходил на страницу загрузки, скачал и установил для теста клиентов на Linux и Windows. Можно всех клиентов подключать под одной учёткой, либо для каждого сделать свою. Это зависит от вашей схемы инфраструктуры. Если бэкапите пользователей, логично каждому из них сделать свою учётную запись, чтобы он имел доступ только к своим бэкапам.
Windows клиента настроил через GUI, а для Linux сервера использовал команду для подключения к серверу:
Далее указал интервал для бэкапа и что бэкапим:
Последняя команда создала запись в crontab для пользователя, под которым её запустил. Теперь можно выполнить принудительный бэкап:
На сервере через веб интерфейс можно посмотреть забэкапленные файлы с обоих устройств.
Система относительно простая. Я практически сходу всё настроил и попробовал. Важно понимать, что она бэкапит только файлы, не системы целиком. Через клиент с GUI можно открыть календарь бэкапов, выбрать нужную дату, когда делался бэкап и восстановить файл.
Minarca Backup похожа частично на Kopia, но ещё больше на UrBackup, BackupPC и ElkarBackup. Причём я затрудняюсь сказать, какая из них лучше. На первый взгляд кажется, что они все примерно одного уровня, где-то одна лучше, где-то другая. Ну и нужно понимать, что сравнивать их с профессиональными платными системами от Veeam, Symantec и т.д. нет никакого смысла. Это разного уровня софт.
⇨ 🌐 Сайт / Исходники / Обзор
#backup #rsync
📌 Сделаю краткий акцент на основных моментах системы:
▪️сервер и клиенты можно установить на Liniux, Windows, MacOS;
▪️можно развернуть на своём железе;
▪️управление через cli или веб интерфейс;
▪️репозитории для хранения подключаются как локальные папки сервера;
▪️управлять доступом к бэкапам можно на уровне пользователей, поддерживается LDAP каталог для них, дисковые квоты;
▪️есть 2FA с отправкой кодов подтверждения на email;
▪️для установки сервера есть репозиторий с пакетами;
▪️данные от клиента на сервер передаются по протоколу HTTP с аутентификацией;
▪️бэкап выполняется на уровне файлов, нет возможности забэкапить всю систему разом или сделать образ диска;
▪️инициирует передачу данных на сервер сам клиент;
▪️клиент может самостоятельно инициировать восстановление своих файлов.
Установка сервера очень простая и типичная для готовых пакетов Debian:
# curl -L https://www.ikus-soft.com/archive/minarca/public.key | gpg --dearmor > /usr/share/keyrings/minarca-keyring.gpg# echo "deb [arch=amd64 signed-by=/usr/share/keyrings/minarca-keyring.gpg] https://nexus.ikus-soft.com/repository/apt-release-$(lsb_release -sc)/ $(lsb_release -sc) main" > /etc/apt/sources.list.d/minarca.list# apt update# apt install minarca-serverСудя по зависимостям серверной части, Minarca Backup построена на базе rdiff-backup. Который, в свою очередь, является python обёрткой вокруг rsync (используется библиотека librsync). Она наследует всю скорость и быстроту синхронизации сотен тысяч файлов, которую обеспечивает rsync. Это чтобы вы понимали, что там под капотом и чего стоит ждать от этой системы. Как по мне, так это плюс, что там rsync используется. Для бэкапа сырых файлов без дедупликации это хорошее, а может и лучшее решение.
Теперь идём по IP адресу на порт 8080 и используем учётную запись: admin / admin123. По умолчанию веб интерфейс открылся на русском языке.
После этого сходил на страницу загрузки, скачал и установил для теста клиентов на Linux и Windows. Можно всех клиентов подключать под одной учёткой, либо для каждого сделать свою. Это зависит от вашей схемы инфраструктуры. Если бэкапите пользователей, логично каждому из них сделать свою учётную запись, чтобы он имел доступ только к своим бэкапам.
Windows клиента настроил через GUI, а для Linux сервера использовал команду для подключения к серверу:
# minarca configure -r http://10.20.1.36:8080/ -u admin -p admin123 -n debian-serverДалее указал интервал для бэкапа и что бэкапим:
# minarca include /etc# minarca schedule --dailyПоследняя команда создала запись в crontab для пользователя, под которым её запустил. Теперь можно выполнить принудительный бэкап:
# minarca backup --forceНа сервере через веб интерфейс можно посмотреть забэкапленные файлы с обоих устройств.
Система относительно простая. Я практически сходу всё настроил и попробовал. Важно понимать, что она бэкапит только файлы, не системы целиком. Через клиент с GUI можно открыть календарь бэкапов, выбрать нужную дату, когда делался бэкап и восстановить файл.
Minarca Backup похожа частично на Kopia, но ещё больше на UrBackup, BackupPC и ElkarBackup. Причём я затрудняюсь сказать, какая из них лучше. На первый взгляд кажется, что они все примерно одного уровня, где-то одна лучше, где-то другая. Ну и нужно понимать, что сравнивать их с профессиональными платными системами от Veeam, Symantec и т.д. нет никакого смысла. Это разного уровня софт.
⇨ 🌐 Сайт / Исходники / Обзор
#backup #rsync
2👍128👎5
Rsync – мощная консольная утилита и служба для быстрого копирования файлов. Отличает её в первую очередь скорость сравнения директорий с огромным количеством файлов. К примеру, если вам нужно будет сравнить и привести к единому содержимому два разнесённых по сети хранилища с миллионом файлов внутри, то rsync для этого подойдёт лучше, чем что-либо другое. У него только один существенный минус – однопоточность.
Я лично чаще всего для бэкапов использую преимущественно голый rsync, но не всегда и не везде. Если нужно обязательно копировать файлы как есть, без упаковки, сжатия, дедупликации, то в этом случае выберу его. По rsync существует много руководств и примеров, но я хочу обратить внимание на некоторые его ключи, которые возможно не все знают и используют.
🔴 --backup и --backup-dir
При сравнении источника и приёмника мы можем привести приёмник к тому же виду, что и источник. Но чаще всего нам хочется, особенно когда делаем бэкап, как-то зафиксировать изменения и сохранить изменившиеся файлы. Я делаю это так:
Все свежие дампы базы из папки
Я добавил ключ
Будут перечислены все скопированные и удалённые (т.е. перемещённые в backup-dir папку) дампы.
С помощью такого подхода очень удобно отслеживать изменения в хранилищах. Например, взломали у вас в какой-то день сайт и заменили несколько файлов. Все эти файлы будут аккуратно сложены в отдельную папочку во время очередного бэкапа после взлома.
🟡 --ignore-existing
Ключ полезен, когда вам надо из бэкапа накатить в источник файлы, не трогая там те, что уже есть, даже если изменились. Накатываем только то, чего не хватает, без какой-либо перезаписи. То есть кто-то случайно или специально накосячил и удалил несколько нужных файлов, которые нам надо вернуть, не трогая всё остальное.
🟢 --update
Используется для того, чтобы обновлять только те файлы в целевой папке, которые старше соответствующих файлов в источнике.
Если в целевой папке файлов из источника вообще нет, то они тоже будут скопированы, как и с ключом
⚫️ --dry-run
Привычное название ключа, который позволяет выполнить команду и посмотреть результат без реального выполнения. То есть выполняется тестовый прогон. Рекомендую использовать, когда отлаживаете команду. Спасёт, если с ключом
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#rsync
Я лично чаще всего для бэкапов использую преимущественно голый rsync, но не всегда и не везде. Если нужно обязательно копировать файлы как есть, без упаковки, сжатия, дедупликации, то в этом случае выберу его. По rsync существует много руководств и примеров, но я хочу обратить внимание на некоторые его ключи, которые возможно не все знают и используют.
🔴 --backup и --backup-dir
При сравнении источника и приёмника мы можем привести приёмник к тому же виду, что и источник. Но чаще всего нам хочется, особенно когда делаем бэкап, как-то зафиксировать изменения и сохранить изменившиеся файлы. Я делаю это так:
# /usr/bin/rsync -av --progress --delete back_user@10.20.5.22:/var/lib/pgpro/backup/ /mnt/data/backup/bases --backup --backup-dir=/mnt/data/backup/bases_increment/`date +%Y-%m-%d`/ >> /var/log/rsync/1Csrv-`date +%Y-%m-%d`.logВсе свежие дампы базы из папки
/var/lib/pgpro/backup/ сервера 10.20.5.22 будут скопированы в папку с бэкапами /mnt/data/backup/bases, при этом старые дампы, которые были скопированы вчера, переместятся в папку /mnt/data/backup/bases_increment/2025-02-13/ и будут там лежать, пока мы их не удалим, к примеру, через find. Глубину хранения сами выбираете, когда настраиваете очистку.Я добавил ключ
--progress, чтобы вывод, сохранённый в файл, содержал в том числе информацию о средней скорости и времени копирования каждого файла. Если у вас много мелких файлов, лучше этот ключ убрать. В логе /var/log/rsync/1Csrv-2025-02-13.log я увижу следующее:2025-02-13_05-29 Start backup 1Csrvreceiving incremental file listdeleting 2025-02-10_05-01-zup.sql.gzdeleting 2025-02-10_05-01-buh.sql.gz2025-02-13_05-01-buh.sql.gz 1,380,560,010 100% 1.03MB/s 0:21:22 (xfr#1, to-chk=20/62)2025-02-13_05-01-zup.sql.gz 444,272,983 100% 1.63MB/s 0:04:19 (xfr#2, to-chk=19/62)Будут перечислены все скопированные и удалённые (т.е. перемещённые в backup-dir папку) дампы.
С помощью такого подхода очень удобно отслеживать изменения в хранилищах. Например, взломали у вас в какой-то день сайт и заменили несколько файлов. Все эти файлы будут аккуратно сложены в отдельную папочку во время очередного бэкапа после взлома.
🟡 --ignore-existing
Ключ полезен, когда вам надо из бэкапа накатить в источник файлы, не трогая там те, что уже есть, даже если изменились. Накатываем только то, чего не хватает, без какой-либо перезаписи. То есть кто-то случайно или специально накосячил и удалил несколько нужных файлов, которые нам надо вернуть, не трогая всё остальное.
# /usr/bin/rsync -av --ignore-existing back_user@10.30.7.5:/mnt/backup/www/ /var/www/🟢 --update
Используется для того, чтобы обновлять только те файлы в целевой папке, которые старше соответствующих файлов в источнике.
# /usr/bin/rsync -av --update back_user@10.30.7.5:/mnt/backup/www/ /var/www/Если в целевой папке файлов из источника вообще нет, то они тоже будут скопированы, как и с ключом
--ignore-existing. Ключ удобен, когда ты из разных источников склеиваешь данные и хочешь получить в итоге самые свежие версии одних и тех же файлов.⚫️ --dry-run
Привычное название ключа, который позволяет выполнить команду и посмотреть результат без реального выполнения. То есть выполняется тестовый прогон. Рекомендую использовать, когда отлаживаете команду. Спасёт, если с ключом
--delete перепутаете источник и приёмник. Мигом удалите все файлы в источнике, если приёмник пустой.❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#rsync
3👍240👎3
Расскажу вам про свою серьёзную ошибку, которая только по случайному стечению обстоятельств не привела к проблемам и потере данных.
Я очень часто использую rsync для бэкапа. В том числе с ключами
Сам бэкап делаю так:
Иногда я эти директории автоматически сжимаю для экономии места. И тогда они превращаются в файлы. Файлы удобно чистить примерно так:
Просто удаляем всё, что старше 100 дней. Я клонировал один проект и настраивал там бэкапы. Изменения сжимать не стал, оставил их в виде директорий. А команду на очистку оставил такой же, с
На днях на источнике проводил чистку, какие-то некритичные данные удалял, какие-то сжимал, переносил. Держал в голове, что все изменения за день приедут в отдельную папку и я их сохраню на всякий случай. На источнике не стал окончательно удалять, а только переместил в другое место. Это в итоге спасло данные.
На следующий день захожу на сервер с бэкапами и понимаю, что файлов нет. Чистил старые файлы, они все были старше 100 дней. Судя по всему сначала они были сложены все в одну директорию в соответствии с ключами
Я сначала не мог понять, в чём тут дело. Вся иерархия папок сохранилась, но файлов нет. Точнее некоторые файлы были, как я уже потом понял, которые моложе 100 дней, но большей части нет. Не мог долго понять, почему так получилось. Начал грешить на сам rsync и подумывал заменять его на restic или borg. Но смысл в том, что rsync в данном случае мне удобнее и привычнее.
В итоге просто чуйка помогла. Ещё раз всё внимательно посмотрел и понял, что команда на чистку не та. Это не rsync сглючил, а я ошибочно удалил файлы уже после его работы. Если используются директории, то чистить надо так:
❗️На самом деле уже не первый раз натыкаюсь на то, что ошибка с find приводит к неожиданным проблемам. С ним, да и любым подобным софтом для очистки данных, нужно очень аккуратно обращаться, всё проверяя по 10 раз. Одна ошибка и данные можно безвозвратно потерять.
#rsync
Я очень часто использую rsync для бэкапа. В том числе с ключами
--backup и --backup-dir, о которых отдельно рассказывал не так давно в заметке. Эти ключи позволяют хранить изменения за день, если бэкап выполняется раз в сутки. У меня они лежат в таких директориях:/mnt/backup/increment/2025-03-15/mnt/backup/increment/2025-03-16/mnt/backup/increment/2025-03-17Сам бэкап делаю так:
# /usr/bin/rsync -av --delete back_user@10.20.5.5:/data/mail/virtual/ /mnt/backup/mailsrv --backup --backup-dir=/mnt/backup/increment/`date +%Y-%m-%d`/ >> /var/log/rsync/mailsrv-`date +%Y-%m-%d`.logИногда я эти директории автоматически сжимаю для экономии места. И тогда они превращаются в файлы. Файлы удобно чистить примерно так:
# /usr/bin/find /mnt/backup/increment/ -type f -mtime +100 -exec rm -rf {} \;Просто удаляем всё, что старше 100 дней. Я клонировал один проект и настраивал там бэкапы. Изменения сжимать не стал, оставил их в виде директорий. А команду на очистку оставил такой же, с
-type f. На днях на источнике проводил чистку, какие-то некритичные данные удалял, какие-то сжимал, переносил. Держал в голове, что все изменения за день приедут в отдельную папку и я их сохраню на всякий случай. На источнике не стал окончательно удалять, а только переместил в другое место. Это в итоге спасло данные.
На следующий день захожу на сервер с бэкапами и понимаю, что файлов нет. Чистил старые файлы, они все были старше 100 дней. Судя по всему сначала они были сложены все в одну директорию в соответствии с ключами
--backup и --backup-dir, а потом команда find их все удалила. При этом сами директории, в том числе вложенные, но уже без файлов остались.Я сначала не мог понять, в чём тут дело. Вся иерархия папок сохранилась, но файлов нет. Точнее некоторые файлы были, как я уже потом понял, которые моложе 100 дней, но большей части нет. Не мог долго понять, почему так получилось. Начал грешить на сам rsync и подумывал заменять его на restic или borg. Но смысл в том, что rsync в данном случае мне удобнее и привычнее.
В итоге просто чуйка помогла. Ещё раз всё внимательно посмотрел и понял, что команда на чистку не та. Это не rsync сглючил, а я ошибочно удалил файлы уже после его работы. Если используются директории, то чистить надо так:
# /usr/bin/find /mnt/backup/increment/ -maxdepth 1 -type d -mtime +100 -exec rm -rf {} \;❗️На самом деле уже не первый раз натыкаюсь на то, что ошибка с find приводит к неожиданным проблемам. С ним, да и любым подобным софтом для очистки данных, нужно очень аккуратно обращаться, всё проверяя по 10 раз. Одна ошибка и данные можно безвозвратно потерять.
#rsync
Telegram
ServerAdmin.ru
Rsync – мощная консольная утилита и служба для быстрого копирования файлов. Отличает её в первую очередь скорость сравнения директорий с огромным количеством файлов. К примеру, если вам нужно будет сравнить и привести к единому содержимому два разнесённых…
3👍144👎2
Продолжу тему насчёт невнимательности и ошибок. И речь будет опять про rsync. Один раз он меня очень жёстко наказал за ошибку. С тех пор я внимательно проверяю и перепроверяю все его параметры.
Чаще всего rsync используется с ключом
Одной командой с rsync вы обнулите источник на 10.20.1.5, если директория
Я в голове всегда произношу мантры, когда настраиваю rsync: "Откуда копирую и куда". У него сначала идёт источник, а потом приёмник. Казалось бы, это очевидное поведение, но на самом нет. Сбивает с толку другой софт. Например, в tar сначала указываешь куда сжимать, а потом уже что сжимать:
Есть и другие примеры, но сейчас сходу не вспомню. Припоминаю, что при копировании разметки с дисков в какой-то программе тоже было неочевидное поведение, когда приёмник был первый, а источник вторым. Я всегда боялся затереть разметку с рабочего диска при копировании на новый. Перепроверял по 10 раз.
Если кто-то сталкивался с подобными засадами из-за невнимательности, то поделитесь историями. Будет интересно и полезно. Лидером тут наверное будет rm, когда перепутали путь или воткнули лишний пробел.
#rsync
Чаще всего rsync используется с ключом
--delete для того, чтобы получить актуальную копию источника. Если на приёмнике какие-то файлы устарели, или на источнике уже удалены, на приёмнике они тоже удалятся. И горе вам, если вы перепутаете местами источник с приемником, особенно при первой синхронизации, когда у вас приёмник пустой. Речь вот о чём:# rsync -av --delete /mnt/backup/data/ root@10.20.1.5:/data/Одной командой с rsync вы обнулите источник на 10.20.1.5, если директория
/mnt/backup/data/ пустая. Причём удаляет rsync очень быстро. Я как-то проводил тестирование и делал заметку по этому поводу. Rsync с пустым приёмником чуть ли не быстрее всех удаляет большое файловое хранилище. Времени опомниться и остановить процедуру у вас практически не будет, особенно если это будет выполняться локально. По SSH ещё есть шансы, если сразу остановите.Я в голове всегда произношу мантры, когда настраиваю rsync: "Откуда копирую и куда". У него сначала идёт источник, а потом приёмник. Казалось бы, это очевидное поведение, но на самом нет. Сбивает с толку другой софт. Например, в tar сначала указываешь куда сжимать, а потом уже что сжимать:
# tar -czvf files.tar.gz /data/filesЕсть и другие примеры, но сейчас сходу не вспомню. Припоминаю, что при копировании разметки с дисков в какой-то программе тоже было неочевидное поведение, когда приёмник был первый, а источник вторым. Я всегда боялся затереть разметку с рабочего диска при копировании на новый. Перепроверял по 10 раз.
Если кто-то сталкивался с подобными засадами из-за невнимательности, то поделитесь историями. Будет интересно и полезно. Лидером тут наверное будет rm, когда перепутали путь или воткнули лишний пробел.
#rsync
👍131👎3