Автономные решения для резервного копирования 40 ТБ данных /35 миллионов файлов на одном диске
У меня есть сервер с 40 ТБ данных и 35 миллионами файлов. В то время как сам сервер имеет рейд и все такое прочее, я обеспокоен тем, что произойдет, если что-то физически уничтожит сервер (пожар, молния и т. Д.).
Система предназначена для запуска всего с одного диска (множество унаследованного кода), поэтому сегментирование на маленькие диски не вариант (ресурсы, необходимые для перезаписи кода, запрещены).
Мне было интересно, какие экономически эффективные варианты резервного копирования существуют. Перемещение их в размещенное решение находится на столе, но поскольку большая часть этих данных является мультимедийными данными, которые должны часто обрабатываться фермой серверов, что может вызвать проблемы с задержкой и пропускной способностью.
редактировать: под "одним приводом" я имею в виду с точки зрения пользователя. Сами данные могут быть распределены на одном диске, при условии, что программное обеспечение, которое обращается к этим данным, может обрабатывать все как один диск.
1 ответ
Как сказал Чоппер, мы не даем рекомендаций по продуктам и услугам - поэтому все, что я собираюсь вам рассказать, довольно общее. Вам придется пойти в свой мыслительный шкаф (возможно, в свой плачущий угол, увидев некоторые ценники) и выяснить, как этого добиться в вашей среде.
Если вы спрашиваете "Как мне создать резервную копию этого сервера?", Как вы думаете, вы пытаетесь понять, начните с определения ваших требований:
- Сколько данных?
- Как часто вам нужно это делать?
- Как часто это меняется? (Сколько будет в каждом цикле резервного копирования?) И т. Д.
Знание этого поможет вам понять, какое решение может быть наиболее эффективным. Вероятно, вы можете сделать само резервное копирование с помощью многих коммерческих (или с открытым исходным кодом) инструментов резервного копирования, но выбор носителя и расписание резервного копирования будут отличаться.
- Много больших объемов изменений
Вы, вероятно, кандидат на репликацию SAN и SAN (или эквивалент с NAS). По сути, клонируйте всю файловую систему на другой сайт и передайте изменения по выделенной сетевой ссылке.
Обратите внимание, что это не настоящая "резервная копия" - если кто-то удаляет важный файл, он исчезает из обоих мест - он просто дает вам аварийное восстановление. - Большой начальный набор, но низкий уровень громкости
Единственное базовое резервное копирование и последующие инкрементные резервные копии после этого (возможно, с "консолидацией" или "синтетическими полными" резервными копиями, чтобы контролировать время восстановления) могли бы хорошо работать здесь.
Выбор типа носителя также важен - ленты являются традиционными и довольно большими.
Если стоимость лент слишком высока, терабайтные диски тоже относительно дешевые и надежные. Оптический носитель, вероятно, не подходит для вашего набора данных размером 40 ТБ.
Репликация SAN по выделенному каналу связи - отличное решение помимо затрат. Другим вариантом является резервное копирование в SAN (или просто узел с тонной диска) на вашем удаленном сайте, но для этого также может потребоваться выделенное (FAST) сетевое соединение. Это особенно верно, если ваш набор изменений велик (если у вас есть небольшой набор изменений, вы всегда можете сделать первоначальное резервное копирование локально, а затем отправить устройство хранения за пределы сайта и обойтись более медленной связью).
В дополнение к резервному копированию убедитесь, что вы принимаете во внимание процесс восстановления. Если для восстановления данных через медленную сетевую восходящую линию требуется 3 месяца, резервное копирование может быть не очень полезным...