Хочу сделать небольшое предостережение насчет облачных хранилищ данных. Я давно использую Яндекс.Диск, практически с самого его появления. На днях заметил, что не хватает каких-то файлов.

Причем файлов важных, с ценной информацией. Начал разбираться и заметил, что не работают вообще все ссылки на сайте на Яндекс.Диск, куда я выкладывал некоторые файлы. Пропала в том числе целая директория с расшаренными файлами.

Разумеется, у меня настроен бэкап диска на разные хранилища с разной глубиной. Начал смотреть бэкапы и обнаружил, что файлы пропали еще месяц назад. Повезло, что заметил и глубина хранения архивных копий позволила все восстановить. Правда ссылки пришлось переделывать в статьях, а это было хлопотно. Заново файлы залились уже с другими ссылками.

Пишу это для того, что акцентировать внимание не просто на бэкапах, но и на глубине хранения архивных копий. Если бы у меня просто был полный единичный бэкап данных, он бы мне никак не помог, потому что файлов, удаленных месяц назад, там бы уже не было. Всегда при создании любых резервных копий, планируйте хранение истории изменений файлов, причем чем глубже, тем лучше. Заметить потерю можно не сразу.

Простейший пример создания бэкапов с заданной глубиной хранения у меня описан в статье - https://serveradmin.ru/rsync-nastroyka-bekapa-na-centos-debian-ubuntu/
Можете просто ознакомиться с принципом организации хранения резервных копий с помощью простого и бесплатного инструмента rsync.

#статья #rsync #backup

​​Если вы любите rsync так же, как и я, и при этом хотите с его помощью бэкапить windows машины, то помочь вам в этом может программа DeltaCopy. Эта программа стала для меня настоящим открытием. Раньше я уже писал про rsync под windows. Там я описывал старую программу, о которой практически не осталось упоминаний в интернете. Нет сайта программы, нет обновлений. На текущий момент она брошена.

DeltaCopy вполне себе живая. Есть сайт, где можно скачать последнюю версию дистрибутива, есть исходники. Да и в целом мне эта программа понравилась за свою простоту и функциональность. Она состоит из двух независимых частей - клиента и сервера.

Клиент вам нужен будет, если вы хотите забирать по расписанию данные с другого Rsync сервера. Мне обычно это не нужно. Сервера чаще всего под Linux и именно с них хочется забирать данные Windows машин. Для этого используется серверная часть. У неё минимум настроек и все через интерфейс программы.

Для того, чтобы начать забирать данные с Windows через Rsync надо в серверной части настроить директорию с источником файлов. Если нужна встроенная авторизация, добавить пользователя и пароль. DeltaCopy сформирует простейший конфиг rsync:

use chroot = false
strict modes = false

[Backup]
  path = /cygdrive/c/tmp
  comment = Backup Drive
  read only = true
  auth users = zerox
  secrets file = /cygdrive/c/DeltaCopy/secrets/Backup.secret

Далее запускаем DeltaCopy как службу и не забываем настроить фаерволл. Надо открыть стандартный порт rsync - tcp 873. Перемещаемся на Linux сервер и забираем оттуда данные:

# rsync -avz zerox@10.20.1.57::Backup /mnt/backup

И всё. Работает четко и просто. Я попробовал, буду теперь использовать DeltaCopy для rsync на Windows.

#windows #backup #rsync

​​Я уже делал несколько заметок по использованию Rsync на Windows в качестве источника бэкапа. Сначала я использовал cwrsync, потом перешёл на DeltaCopy. У последнего понравилась максимальная простота и скорость настройки. Ставишь приложение, указываешь папку, к которой нужен доступ, логи, пароль для авторизации и всё.

Есть только один минус, который немного напрягал. Приёмником бэкапов чаще всего является какой-то Linux сервер, который ничего не знает про права доступа и пользователей Windows. В итоге папка с бэкапами приезжает с правами 700 (RWX для владельца) и владельцем root. Сами файлы имеют эти же права.

Самый просто способ исправить это - поставить костыль и в скрипте использовать chown, chmod и назначать нужного владельца и права доступа. Когда в очередной раз я стал это делать, решил разобраться и обойтись без костылей. Оказалось, что у rsync есть ключи для управления этими параметрами.

Лично мне чаще всего нужны права 755 на директорию и 644 на файлы. Это требуется для того, что мониторинг мог спокойно ходить в бэкапы и собирать нужные данные. Реализуется это с помощью ключа rsync:

--chmod=Du=rwx,Dgo=rx,Fu=rw,Fog=r

В данном случае D - права на директорию, F - на файлы. То же самое можно написать и вот так:

--chmod=D2775,F664

Rsynс поддерживает разные форматы chmod. Чтобы не тащить владельца файла с windows сервера, я еще добавляю ключи:

--no-owner --no-group

Последние можно не добавлять, если не использовать ключ -a, который включает в себя целую кучу ключей, где в том числе есть передача пользователя и группы. Чтобы продолжать использовать общий ключ -a, можно отдельно отменить копирование владельца и группы дополнительными ключами.

Вот пример полной строки запуска Rsynс на Linux для сбора файлов с Windows:

/usr/bin/rsync --progress --delete -avz \
--no-owner --no-group --chmod=Du=rwx,Dgo=rx,Fu=rw,Fog=r \
--password-file=/root/bin/rsyncd.scrt \
rsyncuser@77.88.111.22::backup /mnt/backup/mssql --backup \
--backup-dir=/mnt/backup/mssql_increment/`date +%Y-%m-%d`/

Скрипт синхронизирует директорию с бэкапами mssql. Изменившиеся файлы не удаляет, а кладёт в директорию mssql_increment с именем директории в виде даты на момент запуска скрипта. Таким образом можно организовать нужную глубину хранения бэкапов, удаляя старые директории.

#rsync #windows #backup

​​Потестировал очень любопытную программу для бэкапов - ElkarBackup. Посоветовали в комментариях к недавней статье. Программа понравилась, я её погонял немного, сейчас расскажу, как она работает.

Под капотом там RSnapshot, Rsync, Symfony на PHP. То есть это Web приложение на базе Симфонии и Rsync. По сути это просто веб интерфейс к rsync, которым удобно пользоваться. С его помощью можно добавлять хосты, создавать для них задания, планировать их выполнение, смотреть логи.

Я запустил всё это дело в докере. На хабе представлен готовый docker-compose.yml, но у меня с ним не завелось. Немного подредактировал. Вот рабочий вариант:

version: '3.9'

services:
 elkarbackup:
  image: elkarbackup/elkarbackup:latest
  volumes:
   - backups:/app/backups
   - uploads:/app/uploads
   - sshkeys:/app/.ssh
  environment:
   SYMFONY__DATABASE__PASSWORD: "your-password-here"
   EB_CRON: "enabled"
  ports:
   - 8000:80

 db:
  image: mysql:5.7.22
  volumes:
   - db:/var/lib/mysql
  environment:
   MYSQL_ROOT_PASSWORD: "your-password-here"

volumes:
  db:
  backups:
  uploads:
  sshkeys:

Volumes не вынесены из контейнеров, так что это установка чисто для теста. В прод я бы ставил из пакетов, благо они есть под все популярные системы и настраивается всё очень просто по документации. Контейнеры тут только для теста нужны.

После запуска можно идти в веб интерфейс http://192.168.13.123:8000/ и добавлять нового клиента. В качестве URL укажите подключение по SSH, типа такого: root@192.168.13.177

Для клиента создаёте задание, указывая директорию, которую будете бэкапить. Тут же можно расписание настроить, уведомления включить и т.д. После этого надо забрать с сервера публичный ключ для подключения по ssh. Проще всего его скопировать по ссылке: http://192.168.13.123:8000/config/publickey/get

Публичный ключ надо добавить на целевой сервер, которого добавили как клиента. После этого можно запускать задание с бэкапом. Посмотреть результат работы можно в логах. Если всё в порядке, то файлы приедут на сервер в директорию контейнера /app/backups. Доступ к ним можно получить через веб интерфейс.

Работает всё просто и удобно. Мне понравилось. Рекомендую попробовать, если ищите что-то похожее. Интерфейс простой и лакончиный, работает быстро. Не заметил каких-то проблем или глюков. Насчёт того, как эта штуковина переваривает десятки и сотни тысяч файлов, не знаю. Подозреваю, что могут быть проблемы. Но в такие архивы лазить через веб интерфейс не стоит, достаточно заданиями управлять.

Сайт - https://www.elkarbackup.org/
Исходники - https://github.com/elkarbackup/elkarbackup
Docker Hub - https://hub.docker.com/r/elkarbackup/elkarbackup/

#backup #rsync

Технический пост, который уже давно нужно было сделать, но всё руки не доходили. На канале много содержательных заметок по различным темам. Иногда сам через поиск ищу то, о чём писал. Ниже набор наиболее популярных тэгов по которым можно найти что-то полезное (и не очень).

#remote - все, что касается удалённого управления компьютерами
#helpdesk - обзор helpdesk систем
#backup - софт для бэкапа и некоторые мои заметки по теме
#zabbix - всё, что касается системы мониторинга Zabbix
#мониторинг - в этот тэг иногда попадает Zabbix, но помимо него перечислено много различных систем мониторинга
#управление #ITSM - инструменты для управления инфраструктурой
#devops - в основном софт, который так или иначе связан с методологией devops
#kuber - небольшой цикл постов про работу с kubernetes
#chat - мои обзоры на популярные чат платформы, которые можно развернуть у себя
#бесплатно - в основном подборка всяких бесплатностей, немного бесплатных курсов
#сервис - сервисы, которые мне показались интересными и полезными
#security - заметки, так или иначе связанные с безопасностью
#webserver - всё, что касается веб серверов
#gateway - заметки на тему шлюзов
#mailserver - всё, что касается почтовых серверов
#elk - заметки по ELK Stack
#mikrotik - очень много заметок про Mikrotik
#proxmox - заметки о популярном гипервизоре Proxmox
#terminal - всё, что связано с работой в терминале
#bash - заметки с примерами полезных и не очень bash скриптов или каких-то команд. По просмотрам, комментариям, сохранениям самая популярная тематика канала.
#windows - всё, что касается системы Windows
#хостинг - немного информации и хостерах, в том числе о тех, кого использую сам
#vpn - заметки на тему VPN
#perfomance - анализ производительности сервера и профилирование нагрузки
#курсы - под этим тэгом заметки на тему курсов, которые я сам проходил, которые могу порекомендовать, а также некоторые бесплатные курсы
#игра - игры исключительно IT тематики, за редким исключением
#совет - мои советы на различные темы, в основном IT
#подборка - посты с компиляцией нескольких продуктов, объединённых одной тематикой
#отечественное - обзор софта из реестра отечественного ПО
#юмор - большое количество каких-то смешных вещей на тему IT, которые я скрупулезно выбирал, чтобы показать вам самое интересное. В самом начале есть шутки, которые придумывал сам, проводил конкурсы.
#мысли - мои рассуждения на различные темы, не только IT
#разное - этим тэгом маркирую то, что не подошло ни под какие другие, но при этом не хочется, чтобы материал терялся, так как я посчитал его полезным
#дети - информация на тему обучения и вовлечения в IT детей
#развитие_канала - серия постов на тему развития данного telegram канала

Остальные тэги публикую общим списком без комментариев, так как они про конкретный софт, понятный из названия тэга:
#docker #nginx #mysql #postgresql #gitlab #asterisk #openvpn #lxc #postfix #bitrix #икс #debian #hyperv #rsync #wordpress #zfs #grafana #iptables #prometheus #1с #waf #logs #netflow

​​Rsync - мощная консольная утилита и служба для быстрого копирования файлов. Отличает её в первую очередь скорость сравнения директорий с огромным количеством файлов. К примеру, если вам нужно будет сравнить и привести к единому содержимому два разнесённых по сети хранилища с миллионом файлов внутри, то rsync для этого подойдёт лучше, чем что-либо другое.

Я сам лично до сих пор для бэкапов использую преимущественно голый rsync, но не всегда и не везде. Если нужно обязательно копировать файлы как есть, без упаковки, сжатия, дедупликации, то как раз в этом случае выберу его. Пример подхода с использованием rsync давно описал в статье, которая нисколько не устарела, так как сам rsync, его возможности и параметры не изменились вообще.

Для тех, кто не хочет колхозить автоматизацию бэкапов с помощью самодельных скриптов, есть готовые системы на базе Rsync. Я постарался рассмотреть практически все более ли менее известные. Вот они:

▪ Butterfly Backup - консольная утилита Linux.
▪ Rsnapshot - консольная утилита Linux.
▪ ElkarBackup - сервис для бэкапов, написанный на PHP, настройка через браузер.
▪ BackupPC - сервис для бэкапов, написанный на PERL, настройка через браузер.
▪ Burp - сервис под Linux, более простой аналог Bacula.
▪ cwRsyncServer Программа под Windows.
▪ DeltaCopy Программа под Windows.

Забирайте в закладки. Rsnapshot, DeltaCopy постоянно использую сам.

#rsync #backup

Провёл небольшое исследование на тему того, чем в консоли bash быстрее всего удалить большое количество директорий и файлов. Думаю, не все знают, что очень много файлов могут стать большой проблемой. Пока с этим не столкнёшься, не думаешь об этом. Если у тебя сервер бэкапов на обычных дисках и надо удалить миллионы файлов, это может оказаться непростой задачей.

Основные проблемы будут в том, что либо команда на удаление будет выполняться очень долго, либо она вообще не будет запускаться и писать что-то типа 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/bash

mkdir test
count=1
while test $count -le 10
do touch test/file$count-{000..50000}
count=$(( $count + 1 ))
done
ls test | wc -l

Создаю 500 000 файлов в цикле по 50 000 с помощью touch. Больше за раз не получается создать, touch ругается на слишком большой список аргументов. После этого запускаю приведённые выше команды с подсчётом времени их выполнения с помощью time:
# time rm -r test/
и т.д.

Я не буду приводить все результаты, скажу только, что вариант с rsync самый быстрый. И чем больше файлов, тем сильнее разница. Вариант с rm -r test/* в какой-то момент перестанет работать и будет ругаться на большое количество аргументов.

Для второго теста сделал такой скрипт:

#!/bin/bash

count=1
while test $count -le 10
do mkdir -p test/dir$count-{000..500}
touch test/dir$count-{000..500}/file-{000..100}
count=$(( $count + 1 ))
done
find 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:

# 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 живёт в базовых репозиториях, поэтому установка очень простая:
# 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=true
batch=true

Каталоги на обоих сторонах будут приведены к единому содержанию. Запускать Unison достаточно на каком-то одном хосте. По умолчанию для него нет готовой службы, так что настраивать запуск придётся вручную либо с помощью cron, либо с помощью systemd timers. В заметке как раз приведён пример, который хорошо подходит для ситуации с Unison.

Если на обоих хостах появится файл с одним и тем же именем, но разным содержанием, то синхронизирован он не будет. В результатах синхронизации будет отображено, что файл был пропущен.

Хорошее руководство по unison с примерами есть в arch wiki. А вот прямая ссылка на официальную документацию. У программы очень много возможностей. Например, можно указать, куда будут бэкапиться изменённые файлы. Работает примерно так же, как ключ -backup у rsync, только настроек больше.

⇨ Исходники

#rsync