1

У меня есть 12 часов для резервного копирования 2 ТБ данных.

Я хотел бы выполнить резервное копирование на общий сетевой ресурс на компьютер, используя обычные жесткие диски WD 2TB Black 7200rpm. Гигабитный Ethernet.

Какие еще переменные мне нужно рассмотреть, чтобы увидеть, возможно ли это? Как бы я настроить этот расчет?

2 ответа2

4

Здесь важны два фактора: как быстро источник может передавать данные и как быстро принимающая сторона может их зафиксировать. GigE - это действительно хорошее начало, которое теоретически может занять всего 4,7 часа. Факторы, которые могут увеличить это:

  • Если сетевые буферы принимающей стороны исчерпаны (источник слишком быстро).
  • Если отправляющий конец сильно фрагментирован, он не сможет передавать данные на скорости линии.
  • Если принимающая сторона немного фрагментирована, возможно, она не сможет писать достаточно быстро.
  • Что-то на вашем сетевом пути перегружает bandwitdh (какой-то скрытый порт восходящей линии связи насыщается другим трафиком).

Мой подсчет конвертов говорит о том, что вам нужно передавать около 49 МБ / с, чтобы это работало. Если этот жесткий диск обнажен, а сетевой стек вообще приличный, вероятно, именно исходные уровни фрагментации будут определять предельную скорость.

Изменить: я вижу из комментариев, что вы планируете систему резервного копирования на диск.

Еще несколько вещей, чтобы рассмотреть. Использование нескольких целевых дисков в конфигурации чередования - это действительно хороший способ распараллелить процесс поиска и снизить потери фрагментации. RAID10 - лучшее решение для этого, хотя Raid5/6 может работать, если ваша карта RAID достаточно быстра для этого. Если это не так, то RAID10 - ваша единственная избыточная надежда. В таких ситуациях можно использовать диски с частотой вращения 7,2 тыс. Об /мин, я делаю это прямо сейчас, но с дисками емкостью 500 ГБ, а не 2 ТБ Вы действительно, действительно хотите, чтобы эти диски записывали как можно более последовательно и максимально сокращали количество случайных записей.

Случайные записи вызываются несколькими способами. Если ваша система резервного копирования просто копирует файлы в новое место, вы просто создаете bajillion файлы, и в этом случае резервное копирование будет неизбежно случайным. Вы хотите избежать систем резервного копирования, которые делают это. Если ваша система резервного копирования создает большие архивные файлы (например, 10 ГБ), случайный ввод-вывод происходит, когда эти файлы фрагментируются.

Чтобы избежать фрагментации больших файлов, необходимо выполнить несколько шагов:

  • Убедитесь, что только один файл записывается в любой момент времени.
    • Есть некоторые исключения из этого, если вы используете правильную файловую систему в Linux, но я не знаю, так ли это. Если вы используете NTFS, держитесь одного писателя.
  • Должно быть достаточно свободного места для записи одного большого файла в одном чанке.
    • По прошествии некоторого времени следите за своей диаграммой фрагментации.
  • Если возможно, настройте систему резервного копирования для общего создания файла перед использованием. Вы можете получить 10 ГБ файлов, которые в основном пусты, но, по крайней мере, они являются смежными и помогут уменьшить фрагментацию по мере старения системы.
0

Если ваше соединение может выполнить 1000 мегабит, то передача всех этих данных займет около 4,5 часов (1 мегабит - это 0,125 МБ), поэтому это может сработать, но, возможно, в зависимости от конфигурации сети использовать большую пропускную способность вашей сети для этого времени.

Лучшая альтернатива для резервного копирования, особенно если вы хотите только сохранять резервные копии изменений и фактически не генерируете 2 ТБ данных каждые 12 часов, - это передавать только реальные изменения. Я предлагаю вам взглянуть на rsnapshot, который является хорошей оболочкой для rsync . Таким образом, вы делаете полную длинную передачу только один раз в начале, и обновление снимков будет намного быстрее. На суперпользователе уже есть несколько уроков rsnapshot.

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .