Локальная резервная копия создаёт ощущение защищённости ровно до первого случая, когда она нужна самой первой. Копия, лежащая на той же площадке, делит с оригиналом все его риски: отказ дискового массива затрагивает оба тома, ошибочная команда с правами администратора задевает обе стороны, а авария в машинном зале не спрашивает, где именно лежат резервные каталоги. Отдельный класс защиты снимает эти сценарии одной мерой: копия хранится вне площадки, и событие, выводящее из строя основную площадку, её не задевает. rsync поверх SSH остаётся самым честным конвейером для такой копии: инкрементальная передача только изменившихся частей, сжатие в канале, никаких агентов и сторонних сервисов на приёмнике, только утилита и открытый SSH. Статья разбирает подготовку соединения, набор ключей, схему ротации, проверку целостности и скелет скрипта, который не врёт о результатах своей работы.
Ценность копии вне стен сервера и отличия off-site от локальной
Классическое правило резервирования звучит как формула: три копии сведений, два разных типа носителей, одна копия вне площадки. Off-site экземпляр закрывает третью часть формулы и снимает целый класс сценариев: общий отказ носителя, повреждение стойки, человеческую ошибку, применённую сразу к оригиналу и локальной копии, а также программы-шифровальщики, которые методично проходят по всем смонтированным томам, до которых дотянутся права.
От локальной копии off-site отличается не только адресом. Канал между площадками ограничивает объём: первая полная копия занимает часы или сутки, ежедневные обновления идут минутами, но только при грамотной настройке. Восстановление через сеть измеряется часами, а не минутами локального диска, поэтому глубина ротации и состав копируемых сведений выбираются из компромисса: что терять больнее, скорость восстановления или стоимость хранения.
Отдельный плюс off-site дисциплины психологический. Копия на другой площадке физически недоступна для будничных экспериментов, и случайное изменение или удаление в ней требует осознанных действий. Локальные же резервные каталоги гибнут от переименований и чисток свободного места чаще, чем от реальных аварий.
Подготовка SSH-соединения с ключом и минимальными правами
Соединение для скрипта строится на отдельной ключевой паре. Ключ без парольной фразы упрощает автоматизацию, но требует защищённого хранения на источнике; там, где безопасность важнее удобства, парольную фразу снимает агент с ограниченным временем жизни, и скрипт вызывает его, а не хранит секрет в чистом виде. На приёмнике заводится отдельная учётная запись без права входа в интерактивную оболочку: её единственная задача, принимать соединение и запускать серверную часть rsync.
Приёмник ограничивается на уровне файла авторизованных ключей. Перед ключом прописываются ограничения: разрешённый адрес источника, принудительная команда (серверная обёртка rsync, ограничивающая доступ корнем копий), запрет проброса агента и портов. Такая запись не даёт скрипту превратиться в лазейку: даже при компрометации ключа злоумышленник упирается в узкий коридор одной команды.
Клиентская сторона тоже дисциплинируется. Параметр соединения с таймаутом не даёт скрипту зависнуть на мёртвом маршруте, пакетный режим запрещает интерактивные вопросы, сжатие в канале экономит трафик на текстовых сведениях, при желании используется нестандартный порт. Первое соединение выполняется вручную, чтобы снять вопрос с отпечатком хоста, дальше скрипт доверяет известному ключу.
Финальная деталь подготовки: проверка достижимости приёмника становится первым шагом самого скрипта, а не надеждой. Мёртвый маршрут должен заканчиваться понятным отказом в логе, а не получасовым молчанием в планировщике.
Набор ключей rsync для полной и честной копии
Базовый архивный флаг собирает всё нужное для файлов: рекурсию по дереву, права, времена, группы и владельцев при запуске от имени суперпользователя. Поверх него добавляются специальные флаги: один сохраняет жёсткие ссылки, второй списки контроля доступа, третий расширенные атрибуты, а числовые идентификаторы владельцев фиксируют честное соответствие без зависимости от имён пользователей на разных машинах. Полный набор для системной копии выглядит так:
rsync -aHAX --numeric-ids --delete --partial --timeout=600 \
-e "ssh -p 2222 -o BatchMode=yes -o ConnectTimeout=10" \
--exclude=/proc --exclude=/sys --exclude=/dev --exclude=/run --exclude=/tmp \
/ user@backup-server:/srv/offsite/current/Исключения псевдофайловых систем обязательны: процессная, системная и диспетчерская виртуальные каталоги не имеют смысла в копии, а их содержимое меняется быстрее, чем читается. Сетевые точки монтирования исключаются отдельно, иначе копия потащит за собой содержимое чужих шар и зациклится на вложенных точках.
Флаг зеркалирования с удалением делает копию точным слепком источника, и это острый инструмент: удалённая на источнике директория исчезает и на приёмнике. Защита от случайностей строится не отказом от зеркала, а ротацией ниже: текущая копия зеркалит честно, а история прошлых дней хранит то, что уже исчезло из настоящего.
Служебные ключи закрывают реальные сцены: возобновление после обрыва канала сохраняет недокачанные файлы в отдельном каталоге, таймаут закрывает зависшие соединения, ограничение полосы не даёт копии задушить рабочий канал в дневное время, а сжатие в канале уменьшает трафик для текстов и баз, не помогая на уже сжатых медиафайлах.
Схема ротации daily weekly monthly через жёсткие ссылки
Ротация превращает последовательность зеркал в историю с глубиной. Классическая схема проста: каталоги копий с номерами сдвигаются переименованием, старший покидает хранилище, а новая копия пишется на освободившееся имя. Сдвиг выполняется командами переименования, атомарными для каждой ступени:
mv current.6 current.7
mv current.5 current.6
mv current.4 current.5
mv current.3 current.4
mv current.2 current.3
mv current.1 current.2
mv current current.1Экономия места рождается жёсткими ссылками. Новая копия строится с ключом link-dest, указывающим на вчерашнюю: файлы, не изменившиеся с прошлой копии, заносятся в новое дерево как жёсткие ссылки на те же блоки, изменившиеся копируются физически. Каждый каталог выглядит полной копией, просматривается любым файловым менеджером и восстанавливается целиком, а места на диске занимает сумма уникальных версий файлов.
Недельные и месячные ветки достраиваются тем же приёмом: отдельная цепочка каталогов, обновляемая реже, фиксирует точки восстановления с большим сроком жизни. Глубина каждой цепочки выбирается из требований: сколько дней назад ещё возникает запрос "вернуть как было" и сколько места готова оплатить команда за спокойствие.
Первый запуск цепочки особый: полной копии ещё нет, link-dest не на что указывать, и вся система уезжает по каналу целиком. Разумная практика провести первую копию в окно минимальной нагрузки или доставить её внешним носителем, оставив скрипту только дельты. Проекты, забывающие про этот момент, получают ночь внеплановой нагрузки и неприятные вопросы от коллег утром.
Ограничения схемы честны: жёсткие ссылки живут в границах одной файловой системы, перенос копий на другой том превращает экономию в физическое дублирование, а приёмная файловая система обязана поддерживать нужные атрибуты и права. Поэтому приёмник настраивается заранее и проверяется до первой полной копии, а не во время аварии.
Проверка целостности от контрольных сумм до пробного восстановления
Первый слой проверки встроен в протокол: rsync сверяет контрольные суммы переданных блоков и перечитывает повреждённые участки. Битая передача не проходит молча, и это снимает половину бытовых страхов о целостности канала.
Второй слой арифметический: после копии сверяются число файлов и суммарный объём между источником и приёмником. Расхождение на единицы объяснимо живой системой, расхождение на гигабайты это сигнал разбираться, а не радоваться законченной копии.
Третий слой работает с хэшами. После каждой копии на приёмнике считается и сохраняется манифест контрольных сумм важных каталогов: контрольный файл лежит рядом с копией и сам попадает в следующую ротацию. Раз в месяц выполняется выборочная сверка случайных файлов с исходными хэшами, полный прогон по всем сведениям остаётся инструментом для спорных случаев, потому что он дорог и по времени, и по износу носителей.
Четвёртый слой единственный окончательный: пробное восстановление. Раз в квартал с копии поднимается выборка файлов или целая тестовая машина, проверяется читаемость и запускаемость приложений, фиксируется время восстановления. Зелёный статус задания в планировщике не равен восстанавливаемости, и только этот ритуал превращает копию из предположения в доказательство.
Скелет скрипта с защитой от параллельного запуска и честным кодом результата
Скрипт вместо голой строки в планировщике даёт четыре вещи: наблюдаемость, защиту от наложений запусков, повторяемость и честный код возврата. Каркас выглядит знакомо: строгий режим оболочки, прерывающий работу при ошибке в любой команде, лок-файл через механизм блокировок, не дающий второй копии скрипта стартовать поверх работающей, ловушка завершения для очистки временных файлов при любом исходе.
Перед передачей скрипт проверяет готовность окружения: достижимость приёмника коротким тестовым соединением, свободное место в каталоге копий через удалённый запрос о состоянии диска, наличие предыдущей копии для link-dest при первом запуске после паузы. Каждая проверка заканчивается либо продолжением, либо внятной записью в лог и кодом возврата, на который реагирует мониторинг.
Результат пишется в лог с временными метками: объём переданного, число файлов, длительность, код завершения. Провал не замалчивается: алерт уходит в систему наблюдения, а повторный запуск планируется с задержкой, чтобы не устроить бесконечный штурм недоступного приёмника. Скучный лог с одинаковыми успешными строками и есть правильный результат этой работы.
Рабочий регламент off-site копирования и наблюдение за результатом
Свод правил, при котором off-site копия существует годами без сюрпризов, выглядит так:
- Расписание с учётом окна нагрузки и честной оценкой времени первой полной копии;
- Запрет параллельных запусков через лок-файл и контроль длительности каждой сессии;
- Проверка достижимости приёмника и свободного места до старта передачи;
- Ротация по дням, неделям и месяцам с жёсткими ссылками и зафиксированной глубиной;
- Манифест контрольных сумм после каждой копии и выборочная сверка ежемесячно;
- Пробное восстановление раз в квартал с протоколом и метрикой времени.
Регламент дополняется наблюдением за деградацией. Рост длительности копий при стабильном объёме говорит о просевшем канале, рост объёма при стабильной длительности о накапливающихся сведениях, а череда частичных возобновлений о качестве связи между площадками. Каждый из этих сигналов дешевле поймать по тренду, чем обнаружить в ночь восстановления.
Итоговое суждение о дисциплине off-site спокойное. Копия вне площадки это страховка от редких и дорогих событий, и её правильное состояние скучное: скрипт отработал, копия сошлась, сверка прошла, квартальный тест поднялся. Резервная копия, которую ни разу не восстанавливали и не проверяли, это не копия, а предположение. Копия с регламентом выше это актив, который однажды оправдает все вложенные в него вечера настройки.
Отдельная строчка регламента про восстановление из off-site копии: порядок действий пишется заранее и хранится вместе с копией, а не сочиняется в момент аварии. Проверенный маршрут восстановления экономит часы, когда каждая минута стоит дороже обычного, и превращает чужую драму в рабочую инструкцию из десяти строк.