давний читатель, впервые спрашивающий :)
Я много читал об iSCSI и SAN в целом и считаю, что смог ответить на большинство своих вопросов и опасений по этой теме, но этот вопрос остается:
Как сделать резервную копию SAN?
Далее следует более или менее реальный сценарий, а также мои мысли и вопросы по этому поводу.
Предположим, вам удалось убедить руководство вашей небольшой (в лучшем случае среднего размера) компании предоставить средства для небольшого, но подходящего решения для хранения данных, то есть SAN на основе iSCSI. Предположим, он состоит из сервера с множеством дисков в корпусе и запущенным OpenFiler, или даже MD3000i (Dell) или MSA2000i (HP), которые, как я понимаю, являются наиболее распространенными решениями начального уровня.
LUN экспортируются на сервер, на котором должны храниться репозитории кода, документы, изображения и т. Д., Другой сервер, на котором работает несколько баз данных, еще один, который использует LUN в качестве дисков для гостей виртуализации (DomU на языке Xen) и еще один сервер. который экспортирует один большой LUN, содержащий домашние каталоги пользователя, через NFS (это чистый магазин Linux). Я считаю, что преимущества очевидны: отдельные серверы не нуждаются в большом количестве локального хранилища, а миграция серверов или служб становится проще.
Но теперь вам нужно иметь решение для резервного копирования всех или большей части хранимых данных. Как ты это делаешь? Вы запускаете программное обеспечение для резервного копирования (мне нравится rsnapshot) на каждом сервере, на котором есть данные для резервного копирования? Куда вы помещаете эти данные? На выделенном сервере резервного копирования с большим количеством локальных хранилищ? Или еще в SAN? Какое "общее" решение для резервного копирования SAN, если оно есть?
Я ищу передовой опыт и советы от людей, у которых больше, чем у меня, опыт работы с SAN.
Спасибо!
Изменить: учитывая, что бюджет для SAN очень ограничен, я думаю, что ищу непатентованные, очень общие и дешевые решения вопроса резервного копирования. Во всяком случае, если такие решения существуют. На ленты или второй идентичный SAN-массив денег не будет. Должен был сделать это более явным, извините.
Похоже, что мы находимся в похожей лодке с точки зрения размера и сложности инфраструктуры.
По сути, у меня есть SAN, который обрабатывает мои производственные данные, а затем у меня есть сервер резервного копирования с локально подключенным хранилищем довольно приличного размера, подключенным к ленточной библиотеке (LTO-3, несжатый 400 ГБ / лента)
По сути, я делаю резервные копии на уровне данных. Поскольку я использую Linux, я выполняю rsync, чтобы получить данные с машины, подключенной к SAN, на машину резервного копирования, а затем записываю данные на ленту. Мне повезло, что у меня достаточно локального хранилища на сервере резервного копирования, чтобы я мог хранить копию локально, а затем просто синхронизировать различия, но если вы не можете это настроить, многие решения для резервного копирования используют идею буферизации каталог для локального хранения данных во время записи на ленту.
Из-за способа записи на ленту очень плохая идея напрямую передавать поток из сети на ленту, например в файловую папку Windows или NFS. Это полностью убивает скорость записи на ленту И убивает срок службы вашего ленточного накопителя. Поэтому используйте локальный диск для буферизации данных.
Решение для резервного копирования, которое я использую, называется Amanda, оно довольно эзотерично по своей конфигурации, но имеет коммерческую версию (по цене 100 долларов США за резервное копирование сервера), которая имеет веб-конфигурацию, и вы также можете получить расширения для подключения непосредственно к различным базы данных.
РЕДАКТИРОВАТЬ
Поскольку вы упомянули об отсутствии лент, я бы порекомендовал бедному человеку виртуальную ленточную библиотеку (VTL), то есть внешние USB-накопители. Аманда, по крайней мере, может обращаться к файлам так, как если бы они были VTL, и я уверен, что другие программные пакеты тоже могут.
На самом деле, у жестких дисков есть определенный срок службы. Если ваша компания тратит достаточно денег на покупку SAN, вам следует поработать над ними, чтобы получить устройство смены ленты. На самом деле они не такие дорогие, как раньше, особенно если вы не покупаете на переднем крае.
Мы используем кластер NetApp 3020 SAN с сохраненными на нем данными iSCSI, FC и CIFS. Этот продукт поддерживает дамп NDMP на локально подключенный ленточный автозагрузчик SCSI. Используя это, я получаю идеальные копии моих iSCSI и FC LUN, а также файловые резервные копии моих данных CIFS, совместно используемых из NetApp. Я использую BackupExec для управления резервным копированием NDMP, и скорость исключительно высока, потому что это локальное SCSI-соединение с NetApp.
Самая дешевая (и самая слабая) форма резервного копирования, которую вы могли бы сделать, - это хранить снимки с некоторые форма случайного долгосрочного резервного копирования.
Это предполагает дешевизну снимков - это зависит от того, как они реализованы. Файловые системы копирования при записи, такие как NetApp WAFL и SUN ZFS, имеют моментальные снимки, которые практически не требуют затрат, в отличие от затрат O (n) на копирование моментальных снимков. Дешевые снимки действительно хороши.
Простое хранение снимков на самом деле не является решением для резервного копирования, но я не уверен, что при ваших ограничениях возможно какое-либо реальное решение без серьезного взлома.
Кроме того, я серьезно предубежден здесь как разработчик NetApp, но вы должны хотя бы серьезно разговаривать некоторым продавцам NetApp, прежде чем вы решите, что они вне вашего ценового диапазона. :-)
Ленточная библиотека с прямым или оптоволоконным подключением + NDMP может быть довольно удачным решением, но если ваша система хранения не может использовать что-то подобное для записи на ленту или если бюджет особенно ограничен, вы можете оказаться в положении использовать традиционное решение для резервного копирования для резервного копирования данных в LUN с помощью клиента резервного копирования на хосте, подключенном к SAN.
В подобном сценарии данные, размещенные в SAN, обрабатываются так же, как физические диски в клиенте, для которого выполняется резервное копирование.
Хотя функциональность NDMP иногда включается в систему хранения (как NetApp), приложения резервного копирования могут взимать дополнительную плату за резервное копирование через NDMP. Например, в нашей среде NetBackup лицензии NDMP были намного дороже, чем обычные лицензии на резервное копирование ОС-клиента.
упс .. только что обновился и увидел ваше дополнение re: не имея $ на кассеты. Куда вы планируете размещать резервные копии, если не на ленту или другую сеть хранения данных?
Использование всего диска для резервного копирования возможно, но обычно не считается бюджетным вариантом для любого большого объема данных. Точно так же резервное копирование данных в одну и ту же сеть SAN может снизить некоторые риски, если вы будете осторожны (например, убедитесь, что диски будут полностью разделены), но на самом деле это не предлагает какого-либо полного сбоя или защиты от сбоев. То же самое касается резервного сервера с большим количеством дисков ... некоторого уровня защиты, но если место, где находятся как SAN, так и сервер резервного копирования big-honkin, подвергается серьезному отключению или аварии, все эти данные исчезают.
Мы продолжали использовать существующую инфраструктуру резервного копирования, которая была у нас даже до перехода на SAN. У нас есть отдельные хосты, на которых работает Legato Networker, еженощно выполняющий дамп в систему Storagetek Tape. Честно говоря, если вы ищете дешевое решение ... резервное копирование на диск, вероятно, дешевле всего, у вас также есть возможность транспортировать эти диски в другое место, если это необходимо, как на магнитные ленты.
Поскольку у вас не так много данных, возьмите подержанный ленточный накопитель SDLT или ранний ленточный накопитель LTO 1,2 ... их сотни, поскольку они устарели по сравнению с LTO-3, 4