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