NetApp снапшоты: восстановление файла за 30 секунд против 40 минут с ленты

У нас появился клиент с NetApp. Крупный, с несколькими томами под файловые шары и базы данных. До этого мы работали с IBM FAStT и несколькими менее именитыми железками - NetApp FAS в деле видели только в презентациях вендора. Первые две недели ушли на то, чтобы разобраться как это вообще устроено. Потом было интересно.

Что такое WAFL и почему снапшоты тут особенные

NetApp строит свою файловую систему - WAFL (Write Anywhere File Layout) - так, что снапшот не копирует данные. Он просто фиксирует состояние блочной карты тома в конкретный момент. Новые записи уходят на свободные блоки, старые остаются нетронутыми и доступны через снапшот. Это не LVM snapshot и не теневые копии VSS в Windows Server - механика похожа по эффекту, но реализована на уровне самого массива, прозрачно для любой ОС.

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

Как настраивали расписание

Управление идёт через консоль или telnet/SSH на filer - интерфейс командной строки, минималистичный и конкретный. Для расписания снапшотов команда snap sched:

snap sched vol0 0 2 6@8,12,20

Это означает: 0 еженедельных, 2 ночных снапшота, 6 часовых - в 8:00, 12:00 и 20:00. Для каждого тома своё расписание. Посмотреть текущие снапшоты:

snap list volname

Выдаёт список с именами вида hourly.0, hourly.1, nightly.0, датой и размером «дельты» - то есть сколько изменившихся данных хранит каждый снапшот. Это сразу показывает, насколько активно пишет конкретный том.

У клиента три тома: файловые шары, том под 1С и том под архивы. Для файловых шар поставили плотное расписание - снапшоты каждые два часа плюс ночные. Для архивов - только ночные, там данные почти не меняются.

Тест восстановления

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

Файл удалён. Дальше - через протокол CIFS на шаре появляется скрытая директория .snapshot (в Windows она не видна в обычном проводнике, но доступна если знать путь). Внутри - директории с именами снапшотов, каждая представляет состояние тома на момент снапшота. Находим нужный снапшот, видим файл, копируем обратно на место.

Время от «файл удалён» до «файл восстановлен» - около 30 секунд. Большую часть из них заняло объяснение клиенту куда именно идти в проводнике.

Для сравнения: у того же клиента параллельно работает ленточный бекап - Symantec BackupExec, ленты LTO-2. Тестовое восстановление одного файла с ленты мы делали раньше при приёмке системы. Там счёт идёт на десятки минут - каталогизация, поиск нужной ленты, перемотка, собственно восстановление. Реальная цифра по тому тесту была около 40 минут. Это при условии что лента под рукой, а не в сейфе или у курьера на вывозе.

Тридцать секунд против сорока минут - не абстрактное «быстрее», а конкретная разница в том, насколько человек на том конце провода в панике.

Что стоит иметь в виду

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

Место заканчивается. Если том активно пишется, а снапшотов накоплено много - они начинают занимать существенный объём. Нужно следить за df и за параметром snap reserve. Когда место под снапшоты заканчивается, старые автоматически удаляются - это нормальное поведение, но надо понимать сколько времени назад вы можете откатиться.

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

Клиент после теста сразу спросил - можно ли самостоятельно лазить в .snapshot без звонка к нам. Можно. Это один из редких случаев, когда правильный ответ на запрос пользователя - «сделайте сами, это быстрее». Для остальных задач - планирование ёмкости, мониторинг снапшотов, настройка SnapMirror - мы ведём их в рамках управляемой инфраструктуры, там это часть регулярного обслуживания.