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

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

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

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

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

#статья #rsync #backup

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

Rsync представляет огромную опасность для прода, сравнимую с опасностью от неосторожного использования rm -rf / (у меня было разок 💀). Я думаю у каждого активного пользователя rsync найдется история факапа, связанного с ним. Думаю вы уже поняли, в чем тут дело.

Чаще всего rsync используется с ключом --delete для того, чтобы удалить все файлы на приемнике, которых уже нет на источнике, с которого мы тянем файлы. Это для того, чтобы получить актуальную копию. И горе вам, если вы перепутаете местами источник с приемником. Если у вас приемник пустой, то одной простой командой с rsync вы и источник обнулите.

Стоит ли говорить, что разок я так ошибся и теперь каждый раз очень внимательно проверяю синтаксис команды, которую собираюсь запустить. Мне повезло, что когда я удалял актуальные файлы сайта с прода, успел вовремя заметить и остановить команду. В итоге удалились старые медиа файлы из архива. У меня была вторая копия данных в другом бэкапе (у вас же тоже более одного бэкапа 😎), из которой я их восстановил. Никто даже не заметил проблем, так как сайт продолжал нормально работать.

Все то же самое относится к команде find, если используете ее для удаления файлов. Я сначала направляю вывод списка найденных файлов в консоль или отдельный файл. Проверяю, что там реально то, что я хочу удалить и только после этого удаляю или ставлю в скрипт с ключом --delete или -exec rm {} \;

Были такие факапы, когда удаляли нужные файлы?

#rsync

​​Если вы любите 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