Как хранить резервную копию вне офиса при медленном канале?

Резервная копия вне офиса работает и на медленном канале, если не пытаться протолкнуть через него весь исходный объем. Полную копию один раз вывозят на зашифрованном носителе, а затем канал передает только новые блоки. Это не временная уступка плохой связи, а нормальная схема для филиалов, производственных площадок и небольших городов.

Слабое место такой схемы редко находится в скорости ночного задания. Команды радуются зеленому статусу передачи, но не знают, совпадает ли удаленная копия с источником, переживет ли она ошибочное удаление и сколько займет возврат нескольких терабайт. Поэтому проектировать надо от восстановления: сколько данных потребуется вернуть, откуда их заберут и каким способом доставят, если основной канал занят или лежит.

Сначала зафиксируйте RPO и RTO в измеримых величинах

Медленный канал годится для резервного копирования, когда суточный объем изменений помещается в доступное окно, а способ возврата данных укладывается в допустимое время простоя. Общий размер файлов сам по себе почти ничего не говорит. Хранилище на 20 ТБ, которое меняется на 40 ГБ в сутки, проще защитить через канал 20 Мбит/с, чем базу на 2 ТБ с ежедневной перезаписью большей части блоков.

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

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

Быстрая проверка пропускной способности выглядит так:

полезные_ГБ_за_окно = Мбит_с × 3600 × часы × коэффициент_канала / 8000

Коэффициент канала учитывает протокол, повторные передачи и колебания. Для предварительного расчета я беру 0,7, а потом заменяю его результатом контрольной передачи. При 10 Мбит/с и восьмичасовом окне получится около 25,2 ГБ: 10 × 3600 × 8 × 0,7 / 8000. Если площадка меняет 35 ГБ за ночь, очередь будет расти примерно на 10 ГБ ежедневно. Сжатие не исправит это стабильно, если данные уже сжаты или зашифрованы.

Не путайте частоту снимков с RPO удаленной копии. Локальный снимок каждые 15 минут ничего не дает при пожаре в офисе, если последнее подтвержденное состояние за его пределами датировано вчерашним вечером. Отдельно измеряйте возраст последнего локального снимка и последней проверенной удаленной точки.

Первичную копию вывозят как контролируемую поставку

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

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

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

Я использую короткий акт передачи, даже если диск везет собственный сотрудник:

1. Идентификатор носителя и серийный номер записывают без секретного ключа.
2. В акте указывают снимок, время его создания, объем и контрольный идентификатор репозитория.
3. Отправитель и получатель отмечают время передачи и целостность пломбы.
4. После импорта получатель запускает полную проверку данных и пробное восстановление.
5. Носитель очищают по принятой процедуре или включают в ротацию только после подтверждения импорта.

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

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

Передавайте изменившиеся блоки, а не только изменившиеся файлы

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

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

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

Если rsync входит в вашу схему, используйте его как транспорт к версионируемому приемнику, а не как единственную резервную копию. Предварительный прогон помогает увидеть состав изменений:

rsync -a --dry-run --itemize-changes /data/ backup-host:/incoming/

Строка вида >f.st...... reports/month.csv означает передачу обычного файла с измененным временем. Но совпадение размера и времени по умолчанию еще не доказывает совпадение содержимого. Параметр --checksum меняет предварительное сравнение, зато заставляет обе стороны прочитать файлы и может сильно нагрузить диски. Выбирайте его для периодической сверки или подозрительных наборов, а не включайте повсюду без замеров.

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

Ограничьте поток так, чтобы очередь всегда сокращалась

Резервное копирование должно уступать рабочему трафику, но жесткий слишком низкий лимит способен сделать отставание постоянным. Сначала резервируйте полосу для критичных услуг, затем дайте заданию использовать остаток с расписанием или приоритетом качества обслуживания. Ночной лимит можно поднять, дневной снизить, а не останавливать передачу полностью: частые обрывы добавляют повторные проверки и удлиняют хвост задания.

Смотрите не только на скорость текущего запуска, но и на очередь неподтвержденных изменений. Полезный ежедневный отчет содержит пять полей: время последней успешной удаленной точки, созданные байты, переданные байты, оставшиеся байты и ожидаемое время очистки очереди. Если объем входящих изменений три дня подряд превышает исходящий, тревога должна сработать до заполнения диска и нарушения RPO.

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

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

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

Целостность проверяют на трех разных уровнях

Успешная передача доказывает только то, что программа завершила операцию без известной ошибки. Для пригодной копии нужны три проверки: транспорт не исказил принятые объекты, структура репозитория связна, а приложение открывает восстановленные данные. Одна зеленая галочка не заменяет остальные.

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

На уровне репозитория проверяйте индексы, снимки, ссылки на блоки и сами блоки данных. Документация restic делает полезное различие: обычный restic check проверяет структуру, а чтение всех данных требует отдельного параметра. Рабочая последовательность может выглядеть так:

restic check
restic check --read-data-subset=1/7

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

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

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

Удаленная копия должна пережить учетную запись администратора

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

Разделите роли записи, хранения и удаления. Агент площадки должен добавлять данные, но не менять старые объекты и не сокращать срок хранения. Удаление разрешайте отдельной учетной записи, процедуре с подтверждением или политике неизменяемого хранения на стороне приемника. Администратор исходного домена не должен автоматически владеть удаленным хранилищем.

Версионирование и неизменяемость решают разные задачи. Версионирование сохраняет предыдущие варианты объекта после перезаписи или удаления. Неизменяемый срок запрещает удалить версию до заданной даты даже полномочной учетной записи в рамках выбранного режима. Проверьте, распространяется ли защита на служебные индексы и метаданные репозитория: сохраненные блоки бесполезны, если каталог точек можно уничтожить и команда не умеет его восстановить.

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

Шифрование удаленной копии обязательно, но оно добавляет зависимость от ключа. Проведите отдельное упражнение: чистая машина, задокументированный адрес репозитория, аварийный доступ к секрету и сотрудник, который не настраивал систему. Если он не может разблокировать копию без звонка ушедшему администратору, копии фактически нет.

Время восстановления считают по самому узкому этапу

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

Для передачи используйте формулу:

время_скачивания_час = объем_ГБ × 8000 / (Мбит_с × коэффициент_канала × 3600)

Восстановление 4 ТБ через полезные 20 Мбит/с при коэффициенте 0,7 занимает около 635 часов, то есть больше 26 суток. Даже канал 100 Мбит/с сократит чистую передачу лишь примерно до 127 часов. Эти цифры сразу показывают, почему «данные где-то далеко лежат» не выполняет RTO в восемь часов.

Добавьте фиксированные задержки. Холодному уровню может понадобиться время на подготовку объектов. Поставщик или удаленный офис может выдавать носитель только в рабочие часы. Курьер зависит от расстояния и погоды. На площадке нужен сервер с достаточным объемом и скоростью записи. После доставки 4 ТБ на диске локальное чтение со скоростью 150 МБ/с теоретически займет около 7,4 часа, но множество файлов, проверка и медленный массив увеличат срок.

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

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

Тест восстановления должен ломать удобные предположения

Пробное восстановление нужно проводить с удаленной копии и теми доступами, которые останутся после потери офиса. В NIST SP 800-34 проверка плана включает восстановление выбранных функций из образца резервной информации. Мне нравится эта формулировка за слово «восстановление»: проверка списка файлов или отчет об успешном задании не демонстрируют возврат услуги.

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

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

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

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

Отдельно тестируйте восстановление при занятом канале. В обычный день резервный трафик использует остаток полосы, а во время аварии пользователи могут одновременно подключаться к запасной площадке, обмениваться файлами и звонить через ту же сеть. Контрольное скачивание ночью покажет красивую скорость, которой не будет в рабочие часы. Проведите замер с согласованной нагрузкой и зафиксируйте минимальную скорость, при которой услуги остаются пригодными.

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

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

Инструкция должна перечислять точки принятия решения. Кто объявляет аварию, кто разрешает получить ключ, кто выбирает снимок, кто заказывает носитель и кто подтверждает целостность приложения? Запишите контакты по ролям и запасной канал связи. Имена сотрудников быстро устаревают; роль без назначенного дежурного тоже бесполезна. Во время упражнения засеките ожидание каждого согласования, потому что организационная задержка часто дольше самой технической операции.

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

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

Рабочая схема помещается на одной странице

Эксплуатационная схема должна быть настолько ясной, чтобы дежурный понял состояние без автора проекта. На одной странице укажите источники, локальную промежуточную точку, удаленный репозиторий, расписание, лимиты канала, хранение, владельцев ключей, проверки и оба пути восстановления. Рядом храните измерения, на которых основаны RPO и RTO.

Минимальная политика может выглядеть так:

source_snapshot: every_4_hours
offsite_transfer: continuous_with_night_boost
bandwidth_limit_day_mbps: 4
bandwidth_limit_night_mbps: 18
max_offsite_age_hours: 8
integrity_structure_check: daily
integrity_data_fraction: 1/7_daily
restore_test: quarterly
bulk_restore_path: encrypted_courier_media

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

Для площадок в Казахстане физическая доставка особенно полезна там, где расстояние, стоимость гарантированной полосы или нестабильный канал делают полную сетевую загрузку непрактичной. GSE может спроектировать серверную и инфраструктуру центра обработки данных, подобрать локальные серверы и организовать интеграцию без привязки к одному поставщику. Но заказчик все равно должен назвать допустимую потерю данных и время простоя: интегратор не может вывести эти числа из объема дисков.

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