Я занимаюсь ИТ-отделом в небольшой компании. Я хочу разработать новую инфраструктуру, включая новый сервер и отдельный сервер резервного копирования с политикой резервного копирования в масштабах всей компании.
Самое главное в компании - это SQL Server и его базы данных. Есть 10 баз данных, но только 2 из них действительно важны. Первый 8GB, в основном текстовые данные и числа. Второй - около 300 ГБ с ростом на 16 ГБ в месяц, содержащий файлы PDF и GIF.
Для сохранения хранилища текущая политика резервного копирования состоит из одного полного резервного копирования в неделю и 6 разностных. Я думаю, это около 350 ГБ в неделю, 1,4 ТБ в месяц.
Прочитав такие статьи о скрытом повреждении данных, я решил попробовать ZFS с редакцией Nexenta Community.
Мой вопрос: подходит ли ZFS с дедупликацией для хранения файлов резервных копий с точки зрения надежности, или мне стоит подумать о резервном копировании на ленту или о чем-то еще?
РЕДАКТИРОВАТЬ: Я знаю, что сейчас мы не можем предсказать производительность, коэффициент дедупликации и т. Д., Но я хочу знать, хорошая ли это идея вообще.
(при условии, что вы имеете в виду использование дедупликации в ZFS по сравнению с вашим программным обеспечением для резервного копирования)
я буду не рекомендую использовать ZFS родной дедупликация для вашей системы резервного копирования, если вы не проектируете систему хранения специально для нее.
Использование дедупликации в ZFS чрезвычайно интенсивно требует оперативной памяти. Поскольку дедупликация происходит в реальном времени по мере того, как данные передаются / записываются в пул хранения, в памяти хранится таблица, которая отслеживает блоки данных. Это Таблица ДДТ. Если на вашем сервере хранения ZFS недостаточно оперативной памяти для размещения этой таблицы, производительность сильно пострадает. Nexenta предупредит вас, когда таблица вырастет за определенный порог, но к тому времени будет уже слишком поздно. Это может быть увеличено за счет использования L2ARC устройство (чтение кеша), но многие ранние последователи ZFS попали в эту ловушку.
Видеть:
ZFS - уничтожение дедуплицированного zvol или набора данных останавливает сервер. Как вылечиться?
ZFS - влияние сбоя устройства кэш-памяти L2ARC (Nexenta)
Когда я говорю, что требования к ОЗУ высоки для использования дедупликации, я бы оценил потребности ОЗУ и L2ARC для набора данных, который вы описываете, на 64 ГБ + ОЗУ и 200 ГБ + L2ARC. Это немалое вложение. Хранение большого количества системных файлов Windows и документов изображений, которые нельзя перечитывать, очень быстро заполнит этот DDT. Вознаграждение может не стоить инженерных работ, которые необходимо выполнить заранее.
Лучше использовать сжатие в zpool, возможно, используя возможности gzip для более сжимаемых типов данных. Дедупликация не стоит того, потому что возникает проблема, когда вам нужно удалить дедуплицированные данные (необходимо ссылаться на DDT).
Кроме того, как вы представляете хранилище для своего программного обеспечения для резервного копирования? Какой пакет программного обеспечения для резервного копирования вы будете использовать? В среде Windows я представляю ZFS как блочное хранилище для Backup Exec через iSCSI. Я никогда не считал, что функции ZFS CIFS достаточно надежны, и предпочел преимущества устройства с исходным форматом.
Кроме того, вот отличный ресурс ZFS для дизайнерских идей. Вещи о ZFS, которые вам никто не рассказывал
Конечно, ZFS достаточно стабильна для такого рода вещей, существует множество очень крупных и надежных производственных платформ, полностью основанных на ZFS и Nexenta.
Тем не менее, всегда хотелось бы иметь локальные резервные копии на дисках, такие как та, которую вы предлагаете, И резервные копии на съемном диске или ленте, которые ежедневно отправляются за пределы площадки для защиты от пожара / землетрясения / Ктулху и т.
Итак, мой ответ - да, все в порядке, но я бы выбрал оба варианта, если можете.
Альтернативной ОС является OpenIndiana, которая так же хороша и иногда получает более частые обновления.
Другой вариант - настроить второй сервер ZFS с меньшим (потенциально) пулом хранения с включенным сжатием. Вы можете использовать это второе устройство для статического резервного копирования. Таким образом, вы можете обойтись без кеша чтения, а также не будете нуждаться в огромном количестве ЦП / ОЗУ для его обработки.
Мы запускаем такую настройку там, где я работаю:
У меня есть краткое изложение того, как настроить отправку / получение ZFS здесь: http://kyrill-poole.co.uk/blog/tech/zfs-send-and-receive/