Я собираюсь реализовать очень большой сервер хранения, который будет использоваться в качестве реального NAS для нескольких других серверов (все на базе Linux).
Я имею в виду очень большие от 4 ТБ до 20 ТБ полезного пространства (хотя вряд ли мы сделаем его 20 ТБ).
Сервер хранения будет иметь RAID 10 для защиты данных и производительности, но нам все равно понадобится решение для резервного копирования, включая резервное копирование за пределами площадки.
У меня вопрос: Как сделать резервную копию такого количества данных !?
Я не могу просто подключить портативный жесткий диск и перенести файлы. В настоящее время у нас нет других устройств с таким объемом памяти.
Нужен ли мне бюджет для второго внешнего сервера хранения или есть лучшее решение?
Есть много способов обработки данных такого размера. Во многом это зависит от вашего окружения и от того, сколько денег вы готовы потратить. В общем, существует несколько общих стратегий «получить данные с сервера»:
Это 100 км обзора. Как только вы начнете увеличивать масштаб, все становится намного более фрагментированным. Как уже упоминалось, LTO5 - это особая ленточная технология, предназначенная для такого рода нагрузок с высокой плотностью. Другой идентичный массив хранения является хорошей целью, особенно если вы можете использовать что-то вроде GlusterFS или DRBD для получения данных оттуда. Также, если вам нужна резервная копия вращение или просто возможность продолжать работу в случае отказа массива повлияет на то, что вы вставили.
Как только вы остановитесь на методе просмотра на 100 км, следующей большой задачей станет освоение программного обеспечения. Факторы, влияющие на это, - это то, что вы можете установить на свой сервер хранения в первую очередь (если это NetApp, это одно, сервер Linux с большим количеством хранилищ - совсем другое дело, как и сервер Windows с большим количеством хранилищ) , какое оборудование вы выберете (например, не все пакеты резервного копирования FOSS хорошо справляются с ленточными библиотеками) и какое хранение резервных копий вам необходимо.
Вам действительно нужно выяснить, какое аварийное восстановление вы хотите. Простая репликация в реальном времени проще, но не позволяет восстановить данные с прошлой недели только сейчас. Если для вас важна возможность восстановления данных с прошлой недели, тогда вам нужно спроектировать такие вещи. По закону (в США и других странах) некоторые данные должны храниться более 7 лет.
Проще всего выполнить простую репликацию. Для этого предназначен DRBD. Как только первоначальная копия сделана, она просто отправляет изменения. Осложняющими факторами здесь являются сетевое расположение, если ваш второй массив не находится рядом с основным DRBD, это может быть невозможно. Вам понадобится второй сервер хранения, по крайней мере, с таким же пространством для хранения, как и первый.
О резервном копировании на магнитную ленту ...
LTO5 может хранить 1,5 ТБ данных без сжатия. Чтобы кормить этих монстров, требуется очень быстрая сеть, которая представляет собой либо Fibre Channel, либо SAS 6 Гбит / с. Поскольку вам необходимо создать резервную копию более 1,5 ТБ при ударе, вам нужно изучить автозагрузчики (вот пример: ссылка на сайт, 24-слотовый 1-дисковый автозагрузчик от HP). Благодаря программному обеспечению, которое их поддерживает, они будут заменять кассеты во время резервного копирования. Они великолепны. Вам все равно придется вытаскивать ленты, чтобы отправить их за пределы площадки, но это чертовски лучше, чем торчать всю ночь, чтобы загрузить ленты самостоятельно, когда резервная копия требует их.
Если лента дает вам 'наследие, фу'heebiegeebies, виртуальная ленточная библиотека может быть больше вашей скорости (например, эта от Quantum: ссылка на сайт). Они выдают себя за ленточные библиотеки для резервного копирования программного обеспечения, в то же время сохраняя данные на диск с помощью надежных (как вы надеетесь) методов дедупликации. Более изящные даже скопируют виртуальные ленты на настоящие, если вам нравятся подобные вещи, что может быть очень удобно для ротации за пределами площадки.
Если вы не хотите возиться даже с виртуальными лентами, но все же хотите делать резервные копии прямо на диск, вам понадобится массив хранения, достаточно большой, чтобы обрабатывать эти 20 ТБ, а также столько данных об изменении сети, которые вы хотите держать в руках. Различные пакеты резервного копирования обрабатывают это по-разному. Некоторые технологии дедупликации действительно хороши, другие - хитрые клуджи. Я лично не знаю о состоянии пакетов программного обеспечения для резервного копирования FOSS в этой области (я слышал о Bacula), но их может быть достаточно. Многие коммерческие пакеты резервного копирования содержат локальные агенты, которые вы устанавливаете на серверах для резервного копирования с целью увеличения пропускной способности, что имеет много достоинств.
LTO-5 музыкальный автомат? вам понадобится от трех до 15 лент для резервного копирования этого массива, что не является безумно большим числом. Музыкальный автомат позаботится о замене лент за вас, а хорошее программное обеспечение для резервного копирования (например, bacula) будет отслеживать, какие файлы находятся на какой ленте.
Вы также захотите учесть время, необходимое для резервного копирования такой большой файловой системы, поскольку весьма вероятно, что в течение этого периода FS изменится. Для достижения наилучших результатов была бы очень полезна файловая система, поддерживающая моментальные снимки, так что вы можете сделать мгновенный моментальный снимок и выполнить полное или инкрементное резервное копирование для него, а не для действующей файловой системы.
Вам, вероятно, следует посмотреть на резервное копирование на диск, так как на ленту уйдет много времени, а при последовательном доступе восстановление будет длиться вечно.
Обязательно воспользуйтесь преимуществами дифференциал или добавочный резервное копирование - резервное копирование только изменений, с какой бы периодичностью вы ни были.
Наверное, идеальным решением было бы 2-й сервер аналогичного размера в другом месте, где регулярно отправляются инкрементные резервные копии, которые можно было бы быстро заменить, если главный сервер когда-либо выйдет из строя. Однако другим вариантом было бы использовать съемные диски на месте, которые затем вывозятся на хранение.
Когда вы имеете дело с таким большим объемом данных, также имеет смысл разбейте свои резервные копии на более мелкие задания резервного копирования, и если все они не могут копироваться каждый день, распределите резервные копии так, чтобы для параметра A было выполнено резервное копирование в один день, а для параметра B - на следующий.
Всегда думайте о процедуре восстановления. Однажды мы были уязвлены, когда нам пришлось восстановить файл из задания резервного копирования размером в несколько сотен гигабайт, что потребовало много памяти и много времени, чтобы заново построить индекс резервного копирования и восстановить. В конце концов, мы не смогли завершить это за день, и нам пришлось построить выделенный сервер восстановления, чтобы наш основной сервер резервного копирования мог продолжать свои ночные задания!
- добавлено -
Вы также хотите думать о дедупликация технологии, которые могут сэкономить огромное количество места, не создавая резервную копию одной и той же информации несколько раз для нескольких пользователей. Многие решения для резервного копирования или файловые системы предлагают дедупликацию как часть своей функциональности.
Во-первых, перечислите риски, от которых вы защищаетесь. Некоторые общие риски:
Затем оцените стоимость различных решений по предотвращению рисков, например:
Затем оцените стратегии ротации (насколько далеко назад вы хотите иметь возможность восстановления, сколько данных вы можете позволить себе потерять).
Затем выберите, чего стоят ваши данные.
У меня есть заказчик с двумя похожими системами на 12 ТБ в двух разных зданиях, подключенными на 1 ГБ. Один - производственная система; он копируется постепенно (с ежедневными снимками) в другой с большим rdiff-резервное копирование утилита. rdiff-backup должен быть доступен в вашем стандартном репозитории дистрибутива.
Автономное резервное копирование (удаленное зеркало)
используйте rsync, хотя ssh (только изменения) - первое резервное копирование должно быть выполнено локально, но после этого резервное копирование будет легким в зависимости от изменений
если нужно хранить версии с изменениями - rdiff-backup
http://www.nongnu.org/rdiff-backup/
Файловая система btrfs в Linux звучит многообещающе, но все еще находится в стадии активной разработки
Прежде чем планировать свою стратегию, посмотрите на свое фактическое «содержание» и на то, как часто оно меняется. Часто люди просто еженедельно переносят одни и те же данные на магнитную ленту без уважительной причины.
Технологии дедупликации от некоторых поставщиков позволяют создавать моментальные снимки, чтобы избавить вас от восстановления отдельных файлов, но для защиты вам всегда потребуется удаленное хранилище.