Почему RAID в домашнем NAS не является резервной копией и что действительно спасает данные

Что RAID на самом деле делает с данными

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

У RAID 1 одинаковые данные записываются на два или более диска. Если один HDD выходит из строя, второй содержит ту же информацию, и NAS продолжает обслуживать файлы. RAID 5 распределяет данные и четность по нескольким дискам и обычно способен пережить отказ одного накопителя. RAID 6 использует двойную четность и рассчитан на отказ двух накопителей. У фирменных схем вроде Synology Hybrid RAID логика размещения может отличаться, но назначение остается близким: сохранить доступность массива при выходе из строя допустимого числа дисков.

В актуальной документации Synology прямо указано, что классический RAID и SHR не являются резервным копированием. Это принципиальная граница, которую интерфейсы домашних NAS иногда визуально размывают: статус массива может показывать "Healthy", хотя независимой копии данных вообще не существует. Описание SHR и его отказоустойчивости у Synology содержит это предупреждение отдельно.

RAID отвечает на вопрос: продолжит ли хранилище работать после отказа определенного количества дисков? Резервное копирование отвечает на другой вопрос: откуда взять прежние данные, если основной экземпляр уже утрачен или испорчен?

Эти задачи пересекаются только частично.

Фото: Kent Madsen

Почему два одинаковых диска в RAID 1 не дают две резервные копии

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

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

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

То же относится к RAID 5, RAID 6, SHR и другим избыточным схемам. Дополнительные диски дают информацию, необходимую для восстановления массива при определенных аппаратных отказах. Истории изменения пользовательских данных из этого автоматически не возникает.

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

От каких проблем RAID действительно защищает

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

Это особенно заметно на больших хранилищах. Восстановление нескольких терабайт через интернет или с внешнего USB-диска занимает часы или дни. RAID позволяет заменить отказавший накопитель и выполнить rebuild, сохраняя систему доступной.

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

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

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

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

После замены отказавшего диска NAS начинает реконструировать недостающие данные. У RAID 1 блоки читаются с исправного зеркала. В RAID 5 или RAID 6 недостающая информация вычисляется из оставшихся данных и четности.

Этот процесс называется rebuild. Его легко перепутать с восстановлением резервной копии, хотя по смыслу происходит другое.

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

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

У современных NAS эту задачу частично дополняют проверка массива, мониторинг SMART и data scrubbing. Но и они не являются резервным копированием.

Что делает scrubbing и почему он не возвращает удаленные файлы

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

Например, Synology разделяет RAID scrubbing и проверку файловой системы Btrfs. Для совместимых Btrfs-томов система проверяет контрольные суммы данных, а при наличии корректной избыточной копии может попытаться исправить несовпадение. RAID scrubbing проверяет согласованность массивов SHR, RAID F1, RAID 5 и RAID 6. Производитель рекомендует выполнять такую проверку регулярно.

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

По той же причине scrubbing не заменяет снапшоты. Это обслуживание целостности хранилища, а не хранение истории.

Снапшот решает другую проблему

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

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

TrueNAS описывает ZFS snapshot как read-only point-in-time copy. Сам снапшот сначала почти не требует дополнительного пространства: место начинает использоваться по мере изменения данных, на которые он ссылается. Администраторы используют такие снимки для истории файлов и отката к предыдущему состоянию. Документация TrueNAS по ZFS snapshots описывает и локальные снимки, и их последующее копирование на другую систему.

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

Но локальный снапшот все еще находится внутри того же хранилища.

Почему снапшот на том же NAS тоже не является полноценной резервной копией

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

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

Исходные данные и снапшот на одном томе имеют общие диски.

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

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

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

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

Неизменяемые снапшоты закрывают еще одну дыру

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

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

В DSM 7.2 и более новых поддерживаемых системах Synology неизменяемый снапшот нельзя удалить до окончания заданного периода защиты. Производитель рекомендует типовой период 7-14 дней, хотя реальное значение нужно выбирать под режим работы и доступное место. Документация Synology по immutable snapshots описывает эту функцию как механизм на основе WORM.

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

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

Синхронизация файлов тоже легко маскируется под backup

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

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

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

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

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

Почему внешний HDD помогает только тогда, когда его отключают

Один из самых дешевых способов создать независимую копию домашнего NAS - периодически сохранять данные на внешний USB-диск.

Пока диск отключен и лежит отдельно, NAS, компьютер и вредоносная программа не могут переписать содержимое через сеть. Это физически простой вариант offline backup.

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

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

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

Фото: Steve Bowbrick

Что означает правило 3-2-1 без рекламных упрощений

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

Формулировки правила немного различаются. В рекомендациях CISA по противодействию ransomware приводится схема: рабочие данные плюс две резервные копии, размещенные на двух носителях, причем одна копия находится вне основной площадки. CISA также отдельно рекомендует offline и immutable backups.

Для домашнего пользователя не обязательно буквально покупать ленточную библиотеку ради "второго типа носителя". Ценность правила заключается прежде всего в независимости копий.

Практическая схема может выглядеть так:

• рабочие файлы находятся на компьютере или основном NAS;

• вторая версия регулярно сохраняется на NAS со снапшотами;

• еще одна копия уходит на отключаемый USB-HDD или удаленное хранилище.

Если главным местом хранения уже является NAS, схема меняется: NAS становится первым экземпляром, внешний диск - вторым, а удаленная копия - третьим.

Физическое устройство здесь менее важно, чем отсутствие общей точки отказа.

Почему второй NAS рядом с первым лучше RAID, но хуже удаленной копии

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

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

TrueNAS поддерживает удаленную ZFS-репликацию, при которой снапшоты передаются на другую систему. Первый снимок содержит полное состояние выбранного dataset, последующие могут передаваться инкрементально. Документация TrueNAS по удаленной репликации прямо рассматривает второй удаленный сервер как место для резервных снапшотов.

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

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

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

Облако не становится backup автоматически

Облачное хранилище удобно тем, что физически находится далеко от домашнего NAS. Но слово "облако" ничего не говорит о политике хранения.

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

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

У облака есть еще один практический предел - скорость восстановления. Загрузить туда несколько терабайт можно постепенно месяцами, но после отказа NAS вернуть тот же объем через домашний интернет может оказаться значительно медленнее, чем скопировать данные с локального USB-HDD.

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

RPO важнее количества дисков

При проектировании резервного копирования полезно ответить на вопрос: сколько последних данных допустимо потерять?

Этот интервал называют Recovery Point Objective, RPO. Если фотографии с камеры загружаются на NAS раз в день, а резервное копирование выполняется раз в неделю, после аварии можно потерять до нескольких дней новых файлов, даже если backup полностью исправен.

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

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

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

Главное, чтобы частота соответствовала цене потерянной работы.

RTO отвечает на другой вопрос

Recovery Time Objective описывает допустимое время восстановления.

Можно иметь великолепную облачную копию 20 ТБ, которая защищает от пожара, но при канале 100 Мбит/с возвращение всего объема потребует очень много времени. Для медиатеки это может быть приемлемо. Для рабочей станции, которая должна заработать сегодня, уже нет.

RAID как раз хорошо сокращает RTO при одиночном отказе накопителя: данные остаются доступны вообще без полного восстановления backup.

Локальные снапшоты дают очень короткое время возврата случайно удаленных файлов.

USB-диск позволяет быстрее восстановить большой объем после полной потери массива.

Удаленная копия закрывает самый тяжелый сценарий, когда локальные устройства недоступны целиком.

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

Почему резервная копия без проверки может оказаться фикцией

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

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

CISA рекомендует регулярно проверять доступность и целостность резервных данных именно в сценарии восстановления. NIST также рассматривает создание, обслуживание и тестирование backup как единый процесс защиты от ransomware и других событий потери данных.

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

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

Шифрование backup создает дополнительную обязанность

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

Но зашифрованный backup бесполезен без ключа.

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

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

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

Минимально необходимые права и неизменяемые версии здесь дают реальную пользу.

Нужны ли отдельные резервные копии для каждого каталога

Не все данные стоят одинаково.

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

Полезнее сначала разделить данные.

Первая группа - невосполнимые: личные фотографии, видео, документы, собственные проекты, ключи, конфигурации. Для них оправдана полноценная независимая копия вне NAS.

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

Третья - легко заменяемые. Их иногда дешевле восстановить из интернета, чем годами оплачивать дополнительное облачное место.

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

Можно ли считать компьютеры резервной копией NAS

Если исходные фотографии остаются на компьютере, а NAS содержит их второй экземпляр, некоторое время это действительно две независимые копии.

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

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

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

Если файл существует только в одной системе, backup у него нет.

Когда RAID 1 лучше двух отдельных копий, а когда хуже

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

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

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

Сначала RAID уменьшает вероятность простоя при обычном отказе накопителя. Затем снапшоты дают историю. Независимый backup защищает от потери самого массива.

Что делать с четырехдисковым домашним NAS

Для типичного устройства на четыре диска разумная схема зависит от объема и ценности данных.

Если приоритетом является полезная емкость и допустим отказ одного HDD, часто используется RAID 5 или однодисковая схема SHR. Если данные критичны и восстановление большого массива займет много времени, RAID 6 или SHR-2 уменьшают риск потери массива при втором отказе, но съедают емкость двух дисков.

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

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

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

Конкретные интервалы зависят от того, сколько изменений допустимо потерять.

Почему хранить все backup на том же RAID малоэффективно

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

Но от большинства аппаратных рисков она не отделена.

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

Даже второй storage pool внутри одного корпуса закрывает лишь часть проблемы. Он может иметь отдельные HDD, но использует то же питание, контроллер, помещение и административную систему.

Локальную копию лучше рассматривать как быстрый слой восстановления, а не финальную страховку.

Почему резервирование дисков не защищает от ransomware

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

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

Резервная копия, постоянно смонтированная с теми же правами, тоже может оказаться доступна атакующему.

Поэтому рекомендации CISA строятся вокруг offline, encrypted и immutable backups. В руководстве #StopRansomware отдельно сказано, что многие варианты ransomware пытаются найти доступные резервные копии и удалить или зашифровать их. ([CISA][8])

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

Что не нужно делать после отказа одного диска RAID

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

Вторая - начинать эксперименты с файловой системой до проверки резервной копии.

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

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

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

Какая схема достаточна для фотографий и домашних документов

Для сравнительно небольшого семейного архива сложная серверная архитектура редко нужна.

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

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

Ни один отдельный компонент этой схемы не решает все четыре сценария.

Именно поэтому оценивать надежность по числу дисков в NAS недостаточно.

Что проверить в уже работающем NAS

Начать полезно не с покупки нового железа, а с попытки восстановить один файл.

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

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

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

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

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

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