Сервер резервного копирования с ZFS

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

Самым важным в компании является SQL Server и его базы данных. Есть 10 баз данных, но только 2 из них действительно важны. Первый 8ГБ, в основном текстовые данные и цифры. Второй - около 300 ГБ с 16 ГБ в месяц, содержащий файлы PDF и GIF.

Для сохранения хранилища текущая политика резервного копирования состоит из одной полной резервной копии в неделю и 6 различий. Я думаю, это около 350 ГБ в неделю, 1,4 ТБ в месяц.

После прочтения статей о повреждении данных без вывода сообщений я решил попробовать ZFS с Nexenta Community Edition.

Мой вопрос: хорошо ли ZFS с дедупликацией для хранения файлов резервных копий с точки зрения надежности или мне стоит подумать о резервном копировании на магнитную ленту или о чем-то еще?

РЕДАКТИРОВАТЬ: я знаю, что сейчас мы не можем предсказать производительность, коэффициент дедупликации и т. Д., Но я хочу знать, если это вообще хорошая идея.

Конечно, ZFS достаточно стабильна, чтобы делать подобные вещи, существует множество очень крупных и надежных производственных платформ, полностью основанных на ZFS и Nexenta.

Тем не менее, всегда хотелось иметь локальные резервные копии на основе дисков, такие как та, которую вы предлагаете, И резервные копии на съемном диске или на ленте, которые ежедневно отправляются за пределы площадки для защиты от пожара / землетрясения / Ктулху и т. Д.

Так что мой ответ - да, все хорошо, но я бы выбрал оба варианта, если вы можете.

(при условии, что вы имеете в виду использование дедупликации в ZFS по сравнению с программным обеспечением для резервного копирования)

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

Использование дедупликации в ZFS чрезвычайно интенсивно использует ОЗУ. Поскольку дедупликация происходит в режиме реального времени, когда данные передаются / записываются в пул хранения, в памяти поддерживается таблица, которая отслеживает блоки данных. Это таблица ДДТ . Если на вашем сервере хранения ZFS недостаточно оперативной памяти для размещения этой таблицы, производительность сильно снизится. Nexenta предупредит вас, когда таблица превысит определенный порог, но к тому времени будет слишком поздно. Это может быть дополнено использованием устройства L2ARC (кеш чтения), но многие ранние пользователи ZFS попали в эту ловушку.

Видеть:

ZFS - уничтожение дедуплицированного звола или набора данных останавливает работу сервера. Как восстановить?

ZFS - Влияние отказа кеш-устройства L2ARC (Nexenta)

Когда я говорю, что для использования дедупликации требуется много оперативной памяти, я оцениваю потребности в оперативной памяти и L2ARC для набора данных, который вы описываете, - 64 ГБ + ОЗУ и 200 ГБ + L2ARC. Это не мелкие инвестиции. Хранение большого количества системных файлов Windows и документов с изображениями, которые не будут перечитаны, заполнит этот ДДТ очень быстро. Окупаемость, возможно, не стоит тех инженерных работ, которые должны идти вперед.

Лучшая идея - использовать сжатие в zpool, возможно, используя возможности gzip для более сжимаемых типов данных. Дедупликация того не стоит, так как есть хит, когда вам нужно удалить дедуплицированные данные (необходимо ссылаться на DDT).

Кроме того, как вы будете представлять хранилище для вашего программного обеспечения для резервного копирования? Какой набор программного обеспечения для резервного копирования вы будете использовать? В средах Windows я представляю ZFS как блочное хранилище для Backup Exec через iSCSI. Я никогда не находил функции ZFS CIFS достаточно надежными и предпочитал преимущества устройств с оригинальным форматированием.

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

Альтернативной ОС является OpenIndiana, которая так же хороша и время от времени получает более частые обновления.

Другой вариант - настроить второй ZFS-сервер с меньшим (потенциально) пулом хранения с включенным сжатием. Вы можете использовать это второе устройство для статического резервного копирования. Таким образом, вы можете обойтись без кеша чтения, а также не нуждаетесь в глупом количестве процессора / оперативной памяти для его обработки.

Мы запускаем такую ​​настройку, где я работаю:

• Основной сервер хранения OpenIndiana [ основной ] с шестью дисками по 2 ТБ в пуле RaidZ1 из трех наборов зеркальных пар. Это, в то же время сокращая доступное пространство хранения, обеспечивает быстрый и многократно избыточный пул хранения.
• Вторичный сервер хранения [ резервное копирование ] также работает под управлением OpenIndiana с аналогичной конфигурацией дисков, которая служит исключительно в качестве устройства резервного копирования.
• У main есть скрипт, который запускается из задания cron, которое регулярно делает снимки / tank / [dataset] в течение дня
• Каждый вечер выполняется очередное задание cron, которое переносит снимки дня по сети для резервного копирования . Как только начальная синхронизация всех ваших снимков сделана (однократная процедура), инкрементная природа снимков означает, что изменения передаются на ваше устройство резервного копирования очень быстро.

У меня есть краткое изложение того, как настроить отправку и получение ZFS здесь: http://kyrill-poole.co.uk/blog/tech/zfs-send-and-receive/