Провёл небольшое исследование на тему того, чем в консоли bash быстрее всего удалить большое количество директорий и файлов. Думаю, не все знают, что очень много файлов могут стать большой проблемой. Пока с этим не столкнёшься, не думаешь об этом. Если у тебя сервер бэкапов на обычных дисках и надо удалить миллионы файлов, это может оказаться непростой задачей.
Основные проблемы будут в том, что либо команда на удаление будет выполняться очень долго, либо она вообще не будет запускаться и писать что-то типа Argument list too long. Даже если команда запустится, то выполняться может часами и вы не будете понимать, что происходит.
Я взял несколько наиболее популярных способов для удаления файлов и каталогов и протестировал скорость их работы. Среди них будут вот такие:
И последняя команда, ради которой всё затевалось:
Мы создаём пустой каталог empty/ и копируем его в целевой каталог test/ с файлами. Пустота затирает эти файлы.
Я провёл два разных теста. В первом в одном каталоге лежат 500 тыс. файлов, во втором создана иерархия каталогов одного уровня, где в каждом лежит немного файлов. Для первого теста написал в лоб такой скрипт:
Создаю 500 000 файлов в цикле по 50 000 с помощью
и т.д.
Я не буду приводить все результаты, скажу только, что вариант с rsync самый быстрый. И чем больше файлов, тем сильнее разница. Вариант с
Для второго теста сделал такой скрипт:
Создаю те же 500 000 файлов, только не в одной директории, а в 50 000, в каждой из которых внутри по 100 файлов. В такой конфигурации все команды отрабатывают примерно одинаково. Если директорий сделать те же 500 000, а суммарное количество файлов увеличить до 5 000 000, то разницы всё равно нет. Не знаю почему. Если будете тестировать, не забудьте увеличить стандартное количество inodes, быстро упрётесь в лимит в ext4.
☝Резюме такое. Если вам нужно удалить очень много файлов в одной директории, то используйте rsync. В остальных случаях не принципиально.
Кстати, насчёт rsync я когда-то давно писал заметку и делал мем. Как раз на тему случайного удаления полезных данных, если перепутать в аргументах источник и приёмник. Если сначала, как в моём примере, указать пустую директорию, то вы очень быстро удалите все свои полезные файлы, которые собирались скопировать.
Сохраните скрипты для тестов, чтобы потом свои не колхозить. Часто бывает нужно, чтобы что-то протестировать. Например, нагрузку на жёсткий диск. Создание и удаление файлов нормально его нагружают.
#linux #bash #script #rsync
Основные проблемы будут в том, что либо команда на удаление будет выполняться очень долго, либо она вообще не будет запускаться и писать что-то типа Argument list too long. Даже если команда запустится, то выполняться может часами и вы не будете понимать, что происходит.
Я взял несколько наиболее популярных способов для удаления файлов и каталогов и протестировал скорость их работы. Среди них будут вот такие:
# rm -r test/# rm -r test/*# find test/ -type f -delete# cd test/ ; ls . | xargs -n 100 rm #только для файлов работаетИ последняя команда, ради которой всё затевалось:
# rsync -a --delete empty/ test/Мы создаём пустой каталог empty/ и копируем его в целевой каталог test/ с файлами. Пустота затирает эти файлы.
Я провёл два разных теста. В первом в одном каталоге лежат 500 тыс. файлов, во втором создана иерархия каталогов одного уровня, где в каждом лежит немного файлов. Для первого теста написал в лоб такой скрипт:
#!/bin/bashmkdir testcount=1while test $count -le 10do touch test/file$count-{000..50000}count=$(( $count + 1 ))donels test | wc -lСоздаю 500 000 файлов в цикле по 50 000 с помощью
touch. Больше за раз не получается создать, touch ругается на слишком большой список аргументов. После этого запускаю приведённые выше команды с подсчётом времени их выполнения с помощью time:# time rm -r test/и т.д.
Я не буду приводить все результаты, скажу только, что вариант с rsync самый быстрый. И чем больше файлов, тем сильнее разница. Вариант с
rm -r test/* в какой-то момент перестанет работать и будет ругаться на большое количество аргументов.Для второго теста сделал такой скрипт:
#!/bin/bashcount=1while test $count -le 10do mkdir -p test/dir$count-{000..500}touch test/dir$count-{000..500}/file-{000..100}count=$(( $count + 1 ))donefind test/ | wc -lСоздаю те же 500 000 файлов, только не в одной директории, а в 50 000, в каждой из которых внутри по 100 файлов. В такой конфигурации все команды отрабатывают примерно одинаково. Если директорий сделать те же 500 000, а суммарное количество файлов увеличить до 5 000 000, то разницы всё равно нет. Не знаю почему. Если будете тестировать, не забудьте увеличить стандартное количество inodes, быстро упрётесь в лимит в ext4.
☝Резюме такое. Если вам нужно удалить очень много файлов в одной директории, то используйте rsync. В остальных случаях не принципиально.
Кстати, насчёт rsync я когда-то давно писал заметку и делал мем. Как раз на тему случайного удаления полезных данных, если перепутать в аргументах источник и приёмник. Если сначала, как в моём примере, указать пустую директорию, то вы очень быстро удалите все свои полезные файлы, которые собирались скопировать.
Сохраните скрипты для тестов, чтобы потом свои не колхозить. Часто бывает нужно, чтобы что-то протестировать. Например, нагрузку на жёсткий диск. Создание и удаление файлов нормально его нагружают.
#linux #bash #script #rsync
Я на днях затрагивал тему, где нужно было держать в идентичном виде несколько веб серверов. Есть много решений, которые позволяют синхронизировать файлы в режиме онлайн или почти онлайн, так как на самом деле не всегда нужно синхронизировать каталоги в тот же момент, как они изменились. Можно это делать и с периодичностью в 1-2 минуты.
Одним из самых простых и эффективных решений по синхронизации файлов практически в режиме реального времени - Lsyncd. Он работает на базе rsync, есть в базовых репозиториях большинства дистрибутивов. Имеет стандартные конфигурационные файлы и небольшой набор базовых настроек. Работает на базе подсистемы ядра inotify (Linux) или fsevents (MacOS).
Сразу сделаю важную ремарку. С помощью Lsyncd и других подобных утилит можно гарантированно настроить только одностороннюю онлайн синхронизацию. Это архитектурное ограничение и в рамках синхронизации сырых файлов не имеет простого решения, если не использовать специализированный софт на обоих устройствах. Допустим, вы синхронизируете большой файл с источника на приёмник. Приёмник не знает ничего об этом файле и как только он появится, будет пытаться его тоже синхронизировать в обратную сторону, если синхронизация двусторонняя. В итоге файл побьётся и будет испорчен с обоих сторон. Я рассмотрю на этой неделе также софт для двусторонней синхронизации. Самое надёжное решение для этого - DRBD, которое я уже описывал и использовал.
Покажу сразу на примере, как Lsyncd настраивается и работает. Синхронизировать каталоги будем между двумя серверами по SSH.
Устанавливаем Lsyncd:
Он автоматически подтянет за собой rsync. На сервере приёмнике нужно будет rsync установить отдельно:
Копировать файлы будем по SSH, так что источник должен ходить на приёмник с настроенной аутентификацией по ключам. Не буду на этом останавливаться, настройка стандартная. Пакет почему-то не создал никаких каталогов и конфигов. Утилита по старинке использует для запуска скрипты инициализации init.d, так что просто заглянул в
Настроил синхронизацию директории
Теперь можете положить файл в директорию
По своей сути Lsyncd это удобная обёртка вокруг rsync, которая позволяет быстро настроить нужную конфигурацию и запустить по ней синхронизацию в режиме службы по событиям от inotify. Это отличное решение для поддержания каталогов с сотнями тысяч и миллионов файлов. Лучше я даже не знаю.
⇨ Сайт / Исходники
#rsync
Одним из самых простых и эффективных решений по синхронизации файлов практически в режиме реального времени - Lsyncd. Он работает на базе rsync, есть в базовых репозиториях большинства дистрибутивов. Имеет стандартные конфигурационные файлы и небольшой набор базовых настроек. Работает на базе подсистемы ядра inotify (Linux) или fsevents (MacOS).
Сразу сделаю важную ремарку. С помощью Lsyncd и других подобных утилит можно гарантированно настроить только одностороннюю онлайн синхронизацию. Это архитектурное ограничение и в рамках синхронизации сырых файлов не имеет простого решения, если не использовать специализированный софт на обоих устройствах. Допустим, вы синхронизируете большой файл с источника на приёмник. Приёмник не знает ничего об этом файле и как только он появится, будет пытаться его тоже синхронизировать в обратную сторону, если синхронизация двусторонняя. В итоге файл побьётся и будет испорчен с обоих сторон. Я рассмотрю на этой неделе также софт для двусторонней синхронизации. Самое надёжное решение для этого - DRBD, которое я уже описывал и использовал.
Покажу сразу на примере, как Lsyncd настраивается и работает. Синхронизировать каталоги будем между двумя серверами по SSH.
Устанавливаем Lsyncd:
# apt install lsyncd Он автоматически подтянет за собой rsync. На сервере приёмнике нужно будет rsync установить отдельно:
# apt install rsyncКопировать файлы будем по SSH, так что источник должен ходить на приёмник с настроенной аутентификацией по ключам. Не буду на этом останавливаться, настройка стандартная. Пакет почему-то не создал никаких каталогов и конфигов. Утилита по старинке использует для запуска скрипты инициализации init.d, так что просто заглянул в
/etc/init.d/lsyncd и увидел, что конфиг должен быть в /etc/lsyncd/lsyncd.conf.lua. Создал каталог и файл конфигурации следующего содержания:settings { logfile = "/var/log/lsyncd.log", statusFile = "/var/log/lsyncd.stat", statusInterval = 5, insist = true, nodaemon = false,}sync { default.rsyncssh, source="/mnt/sync", host = "syncuser@1.2.3.4", targetdir = "/mnt/sync", ssh = { port = 22777 }}Настроил синхронизацию директории
/mnt/sync с локального сервера на удалённый 1.2.3.4. Сразу для примера показал, как указать нестандартный порт SSH. В данном случае 22777. Примерно так же можно передать какие-то ключи rsync:rsync = {compress = true,archive = true,_extra = {"--bwlimit=50000"}}Теперь можете положить файл в директорию
/mnt/sync. Через 2-3 секунды он приедет на приёмник. Информация о всех передачах отражается в log файле. По своей сути Lsyncd это удобная обёртка вокруг rsync, которая позволяет быстро настроить нужную конфигурацию и запустить по ней синхронизацию в режиме службы по событиям от inotify. Это отличное решение для поддержания каталогов с сотнями тысяч и миллионов файлов. Лучше я даже не знаю.
⇨ Сайт / Исходники
#rsync
Продолжу тему синхронизации файлов. На этот раз расскажу про утилиту Unison, которая позволяет выполнять двухстороннюю синхронизацию, в отличие от Lsyncd, которая выполняет только одностороннюю.
Unison я знаю и использую очень давно. Статья про её использование написана в далёком 2015 году. Там ничего интересного нет, так как она планировалась как вводная для дальнейшего развития темы, но почему-то не срослось, хотя я помню, что тогда активно использовал её, поэтому и планировал написать. Это одна из старых статей, которую я написал вскоре после того, как с FreeBSD переехал в Linux.
🟢 Основные возможности Unison:
◽Кроссплатформенная программа. Поддерживает Linux, Windows, MacOS, FreeBSD и прочие *BSD. Соответственно, между ними возможна синхронизация.
◽Честная двухсторонняя синхронизация. Конфликтующие файлы обнаруживаются и отображаются.
◽Синхронизирует на уровне файлов как обычная пользовательская программа, не требует прав суперпользователя.
◽Для передачи больших файлов использует тот же подход, что и rsync, то есть передаёт только изменения, а не весь файл.
◽Работает как поверх SSH, так и напрямую по TCP (без шифрования, так что не рекомендуется использовать).
◽Использует такую же реализацию передачи данных, как и rsync. Насколько я понял, реализация написана самостоятельно, а не через использование готовой библиотеки, как в других похожих программах.
В Debian живёт в базовых репозиториях, поэтому установка очень простая:
Установить нужно на обе машины одну и ту же версию. А также настроить аутентификацию по SSH с помощью ключей в обе стороны.
Далее с любой машины тестируем подключение к другой:
Сразу показал пример с использованием нестандартного порта SSH. В данном случае я проверяю возможность синхронизации локального и удалённого каталога
Если всё ОК, то дальше можно пробовать запускать непосредственно синхронизацию:
При первой синхронизации вам выдадут некоторое предупреждение с информацией о синхронизации. А потом попросят подтвердить синхронизацию каждого файла. Понятное дело, что нам это не подходит.
После синхронизации в директории
Каталоги на обоих сторонах будут приведены к единому содержанию. Запускать Unison достаточно на каком-то одном хосте. По умолчанию для него нет готовой службы, так что настраивать запуск придётся вручную либо с помощью cron, либо с помощью systemd timers. В заметке как раз приведён пример, который хорошо подходит для ситуации с Unison.
Если на обоих хостах появится файл с одним и тем же именем, но разным содержанием, то синхронизирован он не будет. В результатах синхронизации будет отображено, что файл был пропущен.
Хорошее руководство по unison с примерами есть в arch wiki. А вот прямая ссылка на официальную документацию. У программы очень много возможностей. Например, можно указать, куда будут бэкапиться изменённые файлы. Работает примерно так же, как ключ
⇨ Исходники
#rsync
Unison я знаю и использую очень давно. Статья про её использование написана в далёком 2015 году. Там ничего интересного нет, так как она планировалась как вводная для дальнейшего развития темы, но почему-то не срослось, хотя я помню, что тогда активно использовал её, поэтому и планировал написать. Это одна из старых статей, которую я написал вскоре после того, как с FreeBSD переехал в Linux.
🟢 Основные возможности Unison:
◽Кроссплатформенная программа. Поддерживает Linux, Windows, MacOS, FreeBSD и прочие *BSD. Соответственно, между ними возможна синхронизация.
◽Честная двухсторонняя синхронизация. Конфликтующие файлы обнаруживаются и отображаются.
◽Синхронизирует на уровне файлов как обычная пользовательская программа, не требует прав суперпользователя.
◽Для передачи больших файлов использует тот же подход, что и rsync, то есть передаёт только изменения, а не весь файл.
◽Работает как поверх SSH, так и напрямую по TCP (без шифрования, так что не рекомендуется использовать).
◽Использует такую же реализацию передачи данных, как и rsync. Насколько я понял, реализация написана самостоятельно, а не через использование готовой библиотеки, как в других похожих программах.
В Debian живёт в базовых репозиториях, поэтому установка очень простая:
# apt install unisonУстановить нужно на обе машины одну и ту же версию. А также настроить аутентификацию по SSH с помощью ключей в обе стороны.
Далее с любой машины тестируем подключение к другой:
# unison -testServer /mnt/sync ssh://syncuser@1.2.3.4:22777//mnt/sync Unison 2.51.3 (ocaml 4.11.1): Contacting server...Connected [//1.2.3.4:22777//mnt/sync -> //debian11//mnt/sync]Сразу показал пример с использованием нестандартного порта SSH. В данном случае я проверяю возможность синхронизации локального и удалённого каталога
/mnt/sync. Если всё ОК, то дальше можно пробовать запускать непосредственно синхронизацию:
# unison /mnt/sync ssh://syncuser@1.2.3.4:22777//mnt/syncПри первой синхронизации вам выдадут некоторое предупреждение с информацией о синхронизации. А потом попросят подтвердить синхронизацию каждого файла. Понятное дело, что нам это не подходит.
После синхронизации в директории
~/.unison появится файл конфигурации default.prf, в котором можно настроить поведение программы при синхронизации. Чтобы вам не задавали никаких вопросов, достаточно добавить туда:auto=truebatch=trueКаталоги на обоих сторонах будут приведены к единому содержанию. Запускать Unison достаточно на каком-то одном хосте. По умолчанию для него нет готовой службы, так что настраивать запуск придётся вручную либо с помощью cron, либо с помощью systemd timers. В заметке как раз приведён пример, который хорошо подходит для ситуации с Unison.
Если на обоих хостах появится файл с одним и тем же именем, но разным содержанием, то синхронизирован он не будет. В результатах синхронизации будет отображено, что файл был пропущен.
Хорошее руководство по unison с примерами есть в arch wiki. А вот прямая ссылка на официальную документацию. У программы очень много возможностей. Например, можно указать, куда будут бэкапиться изменённые файлы. Работает примерно так же, как ключ
-backup у rsync, только настроек больше. ⇨ Исходники
#rsync
Rsync - мощная консольная утилита и служба для быстрого копирования файлов. Отличает её в первую очередь скорость сравнения директорий с огромным количеством файлов. К примеру, если вам нужно будет сравнить и привести к единому содержимому два разнесённых по сети хранилища с миллионом файлов внутри, то rsync для этого подойдёт лучше, чем что-либо другое.
Расскажу про одну функциональность rsync, про которую, возможно, не все знают. Речь пойдёт про ключ
Суть в том, что rsync после копирования файлов удаляет их на стороне источника. Мне чаще всего это нужно, когда я локально делаю дампы баз данных. Они какое-то время лежат на сервере, где были сделаны, а потом с бэкап сервера запускается rsync, проходит по серверам, забирает с них дампы и удаляет за собой, после того, как скопирует.
Очень удобно. Не нужно на источниках настраивать автоочистку, с которой могут быть нюансы. Например, если бэкап по каким-то причинам не выполнялся, на источниках накапливаются файлы. А когда заработает снова, будут удаляться по мере копирования.
Выглядит итоговая команда для бэкапа примерно так:
Для тех, кто не привык колхозить автоматизацию бэкапов с помощью самодельных скриптов, есть готовые системы на базе Rsync. Я постарался рассмотреть практически все более ли менее известные. Вот они:
▪️ Butterfly Backup - консольная утилита Linux.
▪️ Rsnapshot - консольная утилита Linux.
▪️ ElkarBackup - сервис для бэкапов, написанный на PHP, настройка через браузер.
▪️ BackupPC - сервис для бэкапов, написанный на PERL, настройка через браузер.
▪️ Burp - сервис под Linux, более простой аналог Bacula.
▪️ cwRsyncServer Программа под Windows.
▪️ DeltaCopy Программа под Windows.
Забирайте в закладки. Для сырых данных rsync предоставляет наилучшую производительность и утилизацию канала. Особенно это заметно на большом количестве мелких файлов, или там, где большой файл изменяется незначительно. Алгоритм работы rsync позволяет не выкачивать весь файл заново, а только изменения.
#rsync #backup
Расскажу про одну функциональность rsync, про которую, возможно, не все знают. Речь пойдёт про ключ
--remove-sent-files. С этим ключом есть некоторая неоднозначность. В каких-то манах он представлен в таком виде, а где-то в виде --remove-source-files. Судя по описанию, это одно и то же. Я в своих скриптах использую --remove-sent-files. Суть в том, что rsync после копирования файлов удаляет их на стороне источника. Мне чаще всего это нужно, когда я локально делаю дампы баз данных. Они какое-то время лежат на сервере, где были сделаны, а потом с бэкап сервера запускается rsync, проходит по серверам, забирает с них дампы и удаляет за собой, после того, как скопирует.
Очень удобно. Не нужно на источниках настраивать автоочистку, с которой могут быть нюансы. Например, если бэкап по каким-то причинам не выполнялся, на источниках накапливаются файлы. А когда заработает снова, будут удаляться по мере копирования.
Выглядит итоговая команда для бэкапа примерно так:
/usr/bin/rsync --remove-sent-files --progress -av -e "ssh -p 31003 -i /home/user/.ssh/id_rsa" user@10.20.20.55:/home/bitrix/mysqlbackup/ /mnt/backup/site01/mysql-dump/
Для тех, кто не привык колхозить автоматизацию бэкапов с помощью самодельных скриптов, есть готовые системы на базе Rsync. Я постарался рассмотреть практически все более ли менее известные. Вот они:
▪️ Butterfly Backup - консольная утилита Linux.
▪️ Rsnapshot - консольная утилита Linux.
▪️ ElkarBackup - сервис для бэкапов, написанный на PHP, настройка через браузер.
▪️ BackupPC - сервис для бэкапов, написанный на PERL, настройка через браузер.
▪️ Burp - сервис под Linux, более простой аналог Bacula.
▪️ cwRsyncServer Программа под Windows.
▪️ DeltaCopy Программа под Windows.
Забирайте в закладки. Для сырых данных rsync предоставляет наилучшую производительность и утилизацию канала. Особенно это заметно на большом количестве мелких файлов, или там, где большой файл изменяется незначительно. Алгоритм работы rsync позволяет не выкачивать весь файл заново, а только изменения.
#rsync #backup
Недавно впервые услышал про новую для меня систему резервного копирования 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
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
Расскажу вам про свою серьёзную ошибку, которая только по случайному стечению обстоятельств не привела к проблемам и потере данных.
Я очень часто использую 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 – мощная консольная утилита и служба для быстрого копирования файлов. Отличает её в первую очередь скорость сравнения директорий с огромным количеством файлов. К примеру, если вам нужно будет сравнить и привести к единому содержимому два разнесённых…
Продолжу тему насчёт невнимательности и ошибок. И речь будет опять про 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