RAID, снапшоты и облако не заменяют резервную копию: как построить защиту данных по правилу 3-2-1

Сначала нужно понять, от чего именно мы защищаем данные

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

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

Поэтому резервное копирование нужно оценивать не по числу дисков и не по надписи "Backup" в интерфейсе NAS. Главный вопрос проще: останется ли независимая читаемая версия данных после конкретной аварии.

Почему RAID не является резервной копией

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

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

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

Фото: Lukas Gerhold

Снапшот решает другую задачу

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

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

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

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

Зачем тогда нужны снапшоты

Потому что скорость восстановления тоже имеет значение. Представим NAS объемом 20 ТБ. Пользователь случайно перезаписал один документ. Восстанавливать ради него несколько терабайт из удаленного облака бессмысленно, если нужную версию можно извлечь из локального снапшота за минуту.

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

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

Синхронизация с облаком тоже может не быть бэкапом

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

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

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

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

Что означает правило 3-2-1

Классическая схема предполагает три экземпляра важных данных: рабочий оригинал и две дополнительные копии. Они должны располагаться как минимум на двух типах носителей, а одна копия хранится вне основной площадки. Такое определение приводилось еще в материалах US-CERT и до сих пор используется как удобная базовая модель.

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

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

К примеру, рабочие файлы могут находиться на ПК, локальный backup на NAS, а еще одна копия на отключаемом USB-диске или в удаленном хранилище. Уже такая схема намного устойчивее, чем NAS из четырех дисков без внешнего бэкапа.

Почему два NAS рядом все еще имеют общий риск

Допустим, основной NAS ежедневно копируется на второй NAS в той же комнате. Это лучше одного устройства: отказ блока питания, материнской платы или массива первого хранилища уже не уничтожает вторую копию.

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

Поэтому географическое разделение в правиле 3-2-1 нельзя заменить просто вторым устройством на соседней полке. Удаленной копией является копия, которая переживет потерю основной площадки.

Изолированная копия нужна уже не только крупным компаниям

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

В руководстве CISA по защите от ransomware прямо рекомендуется хранить критичные резервные копии offline и регулярно проверять их доступность и целостность. Причина понятна: вредоносное ПО и атакующие могут специально искать доступные backup-хранилища и уничтожать их перед шифрованием основной инфраструктуры.

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

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

Immutable backup решает похожую задачу по-другому

Неизменяемая копия остается подключенной, но записанные данные нельзя удалить или переписать до истечения заданного срока хранения. Такой механизм встречается в объектных хранилищах с Object Lock, WORM-хранилищах и некоторых современных NAS.

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

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

Откуда появилась схема 3-2-1-1-0

В материалах по резервному копированию все чаще встречается расширенная формула 3-2-1-1-0. К классическим трем копиям, двум типам хранения и одной удаленной копии добавляется еще одна offline или immutable копия. Ноль означает отсутствие ошибок после проверки резервных данных.

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

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

Главная проблема бэкапа обнаруживается при восстановлении

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

Повредиться может сам backup-файл. Можно забыть пароль от зашифрованного архива. У резервной копии виртуальной машины могут отсутствовать необходимые метаданные. База данных может копироваться в неконсистентном состоянии. Удаленная копия может оказаться слишком старой.

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

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

Фото: Armchair

Что такое RPO и почему от него зависит частота копирования

Частоту резервного копирования часто выбирают привычным способом: "раз в неделю должно хватить". Удобнее сначала решить, сколько последних данных допустимо потерять.

Это и есть смысл Recovery Point Objective. Если фотограф обрабатывает съемку весь день и готов в худшем случае потерять не больше часа работы, ежедневный backup не подходит. Для архива фильмов, который меняется раз в месяц, ежечасное резервирование лишено смысла.

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

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

RTO отвечает уже за время восстановления

Другой параметр, Recovery Time Objective, показывает допустимый простой. Два человека могут хранить одинаковые 10 ТБ данных и нуждаться в совершенно разных системах.

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

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

Надежная схема строится одновременно вокруг риска потери и времени, которое пользователь готов ждать.

Как рассчитать, сколько времени займет возврат данных из облака

Допустим, в удаленном хранилище лежит 4 ТБ данных. Даже при стабильной входящей скорости 100 Мбит/с теоретический минимум на передачу составляет около 89 часов. Реальный срок будет больше из-за накладных расходов, колебаний скорости, множества мелких файлов и ограничений сервиса.

При 500 Мбит/с теоретическое время снижается примерно до 18 часов. Но если интернет нужен параллельно для работы, использовать канал целиком не получится.

Поэтому облако отлично подходит как удаленная страховка, но не всегда как единственный источник восстановления большого массива. Локальный backup на HDD или втором NAS часто существует именно ради RTO, а не ради дополнительной модной технологии.

Почему один внешний диск лучше ничего, но у него есть слабое место

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

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

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

Недостаток такого подхода тот же: ручная дисциплина. Если последний backup делался три месяца назад, наличие двух дисков мало помогает.

NAS удобен тем, что автоматизирует локальный уровень

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

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

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

Фото: Korrupt

Какая схема подходит обычному домашнему компьютеру

Для компьютера с документами, фотографиями и обычными личными файлами разумный минимум можно собрать без NAS. Основные данные остаются на внутреннем SSD. Автоматическая локальная копия создается на внешнем HDD. Вторая копия самых важных папок хранится удаленно или на другом отключаемом диске вне комнаты с компьютером.

Здесь уже разделены несколько рисков. Поломка SSD закрывается локальным диском. Ошибка пользователя может быть исправлена, если backup хранит версии. Катастрофа в квартире не уничтожает удаленную копию.

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

Схема для дома с NAS

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

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

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

Какая схема разумна для малого офиса

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

Рабочие данные могут находиться на сервере или NAS с RAID. Снапшоты дают быстрый откат после ошибки сотрудника. Второй NAS или backup-сервер принимает отдельную копию. Критичные данные дополнительно уходят на удаленную площадку или в объектное хранилище с версионностью и защитой от удаления.

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

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

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

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

Поэтому серверные СУБД используют собственные механизмы backup, журналы транзакций, дампы или согласованные снапшоты. Копирование каталога работающей базы на USB-диск не гарантирует, что она потом запустится.

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

Это одна из причин, почему проверка восстановления ценнее самого отчета об успешном копировании.

Инкрементальный backup экономит место, но создает зависимость от цепочки

Полный backup содержит весь выбранный набор данных. Его проще понимать и восстанавливать, но регулярное хранение нескольких полных копий требует много места.

Инкрементальная схема после первой полной копии сохраняет только изменения. Если за сутки в массиве 5 ТБ изменилось 20 ГБ, передавать повторно весь массив нет необходимости. Это особенно заметно при удаленном резервировании.

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

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

ZFS replication показывает разницу между snapshot и отдельной копией

У ZFS снапшот остается локальной точкой состояния файловой системы. Но ZFS также умеет сериализовать его в поток и передавать на другое хранилище через zfs send и zfs receive. Документация OpenZFS описывает как полную, так и инкрементальную передачу между снапшотами.

Именно физическое перемещение данных на другой пул меняет модель защиты. Локальный snapshot на том же массиве остается зависимым от исходного оборудования. Реплика на другом сервере уже переживет отказ исходного массива, хотя все еще может зависеть от общей сети или учетных данных.

Тот же принцип применим и к другим NAS. Название технологии вторично. Нужно смотреть, где физически находятся блоки второй версии и кто способен их удалить.

Нужно ли шифровать резервные копии

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

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

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

Ключ или recovery-код нужно хранить отдельно и так, чтобы его можно было найти после аварии. Если доступ к облачному backup зависит от телефона с приложением двухфакторной аутентификации, полезно заранее продумать восстановление учетной записи после потери самого телефона.

Почему срок хранения версий нельзя выбирать случайно

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

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

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

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

Как понять, что схема действительно 3-2-1

Проще всего мысленно уничтожать элементы системы по одному. Умер SSD компьютера. Данные остаются? Сгорел NAS. Остаются? Удалена папка и удаление синхронизировалось. Можно вернуть старую версию? Шифровальщик получил доступ к общей папке. Есть копия, которую он не может переписать? Пропало все оборудование в помещении. Осталась удаленная версия?

Если на любой из этих вопросов ответ "нет", становится понятно, какой риск не закрыт. Необязательно покупать новое оборудование наугад. Иногда достаточно изменить расположение уже существующего диска, включить историю версий или перестать держать backup постоянно подключенным.

Такой анализ полезнее подсчета дисков. Шесть HDD внутри одного RAID-массива не дают шесть копий. Десять снапшотов на том же пуле не создают десять независимых хранилищ.

Что проверять раз в несколько месяцев

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

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

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

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