Резервные копии по правилу 3-2-1: домашняя и рабочая версия

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

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

Сначала составьте карту данных

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

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

Что на самом деле означает 3-2-1

Классическая формула: три экземпляра важных данных, включая рабочий; два разных типа или контура хранения; одна копия вне основной площадки. Смысл «двух» — не спор о том, считать ли облако отдельным носителем, а разные failure domains. Два внешних диска, постоянно подключённые к одному заражённому компьютеру, могут пострадать вместе. Две папки в одном облачном аккаунте разделяют удаление и захват учётной записи.

NCSC отдельно отмечает, что простая формула 3-2-1 не требует offline-копии. Для риска ransomware или захвата администратора нужна дополнительная логическая изоляция: отключаемый носитель, immutable или object-lock механизм с отдельно контролируемыми правами, либо другой контур, который обычный рабочий аккаунт не может переписать. Конкретный выбор зависит от угрозы; ни offline, ни immutable не дают абсолютной гарантии.

• Сбой одного устройства: локальная копия на другом носителе может дать быстрый возврат.

• Кража, пожар или затопление площадки: off-site экземпляр не должен находиться рядом с рабочим.

• Ошибочное удаление: versioning и retention должны сохранять состояние до ошибки.

• Захват аккаунта или ransomware: recovery data не должна полностью управляться теми же credentials.

• Потеря ключа шифрования: независимый recovery path для ключа обязателен, иначе защищённая копия недоступна.

Калькулятор объёма и расписание копирования

Не используйте универсальное правило «возьмите диск в два раза больше», кроме product-specific рекомендации, явно относящейся к конкретному инструменту. Калькулятор Jurno строится по измерениям. Для каждой категории задайте V — текущий объём, g — наблюдаемый прирост за выбранный период, W — горизонт планирования, R — объём версий, который реально удерживает выбранная retention policy, и O — измеренные накладные расходы инструмента. Плановая ёмкость равна сумме V, ожидаемого прироста g × W, рассчитанного объёма версий R и технического запаса, подтверждённого пробным запуском.

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

Пример без вымышленных чисел: у домашнего архива есть измеренный V и прирост после каждой съёмки. Горизонт — до ежегодной ревизии, retention — все оригиналы и ограниченная история изменённых каталогов. У рабочей базы измеряется размер полного снимка и журналов, а retention выбирается от требований возврата. Подставьте свои значения; статья намеренно не назначает типовой терабайт и не обещает, что один коэффициент подходит фотографиям, базам и виртуальным машинам.

Домашнее расписание

Для дома создайте три маршрута. Первый — частая автоматическая копия активных каталогов на отдельный носитель или сервис. Второй — версия на физически отдельном носителе, который отключается после задания. Третий — off-site контур: контролируемое облако с проверенным versioning или носитель в другом безопасном месте. Один и тот же файл может проходить эти маршруты с разной частотой.

• Ежедневно или после значимой работы: активные документы и текущие проекты, если такой RPO действительно нужен.

• После импорта: оригиналы новых фото и видео, затем контроль выборки.

• После изменения: конфигурации, recovery-инструкции и список критичных приложений.

• По принятому циклу: отключаемая или off-site копия и проверка доступности ключа.

• После обновления системы: контрольный restore нескольких файлов, а не полное доверие к уведомлению.

Time Machine и Windows Backup можно использовать как части схемы, но не смешивайте их условия. Apple описывает собственное автоматическое расписание и управление заполнением диска; Microsoft — consumer-сценарий с Microsoft account и OneDrive. Ни один продукт сам по себе не доказывает независимость всех трёх экземпляров. Проверьте, какие папки включены, где хранятся версии и что произойдёт при удалении или блокировке аккаунта.

Рабочее расписание

В команде рядом с категорией данных укажите бизнес-владельца и технического исполнителя. Владелец определяет приоритет и принимает результат восстановления; исполнитель настраивает и проверяет механизм. Для каждой системы запишите источник, назначение, RPO, RTO, retention, recovery location, ключи, порядок эскалации и дату последнего теста. Инструкция должна быть доступна, если основной облачный аккаунт недоступен.

Частота строится от изменений. Если данные поступают непрерывно, ежедневная копия может быть недостаточна; если архив не меняется, ежедневное полное копирование создаёт расходы без пользы. База данных требует согласованного snapshot или официального export flow, а не простого копирования открытого файла. SaaS-сервис требует понять экспорт, API, retention и восстановление после удаления. Используйте документацию конкретной системы и не называйте синхронизацию backup автоматически.

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

Restore test: единственное доказательство

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

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

Практический следующий шаг

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

Не закупайте ёмкость до пилотного измерения прироста и версий. Не удаляйте старую рабочую копию, пока новый маршрут не прошёл restore test. Домашняя схема считается запущенной после успешной выборки и доступного recovery key; рабочая — после принятия результата владельцем, записи RPO/RTO и назначения следующей проверки. Это меньше похоже на красивую диаграмму, зато действительно показывает, можно ли вернуть данные.

Что читать дальше

• сначала определить структуру и владельца файлов

• включить резервирование в базовую защиту команды

• восстановление после компрометации аккаунта