Скільки часу триватиме передача цього файлу?

У мене є 12 годин для резервного копіювання 2 ТБ даних.

Я хотів би створити резервну копію на мережевій папці на комп'ютері за допомогою споживчих жорстких дисків WD 2TB Black 7200 об / хв. Гігабітний Ethernet.

Які ще змінні мені потрібно врахувати, щоб побачити, чи це можливо? Як я налаштував цей розрахунок?

Два важливих чинника тут - це те, наскільки швидко джерело може викладати дані, і як швидко кінець прийому може скористатися ними. GigE - це справді хороший старт, який теоретично означає, що це може зайняти всього 4,7 години. Фактори, які можуть це підвищити:

• Якщо мережні буфери приймаючого кінця закінчуються (джерело подає занадто швидко).
• Якщо кінець відправки сильно фрагментований, він не зможе розмістити дані зі швидкістю лінії.
• Якщо кінець прийому є чим-небудь іншим, але злегка фрагментованим, він може не в змозі написати досить швидко.
• Щось у вашому мережевому шляху - це вивільнення смуги частот (якийсь прихований порт висхідної лінії, насичений іншим трафіком).

Мій підрахунок зворотного конверта говорить, що вам потрібно передавати поточну швидкість близько 49 Мб / секунду, щоб вона працювала. Якщо цей жорсткий диск голий, а мережевий стек взагалі пристойний, можливо, саме рівень фрагментації джерела визначає кінцеву швидкість.

Редагувати : я бачу з коментарів, які ви плануєте в системі резервного копіювання на диск.

Ще кілька речей, які слід врахувати. Використання декількох цільових накопичувачів у смуговій конфігурації - це справді хороший спосіб паралелізації процесу пошуку та зменшення штрафу за фрагментацію. RAID10 - найкраще рішення для цього, хоча Raid5 / 6 може працювати, якщо ваша RAID-карта достатньо швидка, щоб обробляти її. Якщо це не так, RAID10 - ваша єдина надмірна надія. 7.2K RPM-накопичувачі дійсно можуть бути використані в цих ситуаціях, я це роблю зараз, але з накопичувачами на 500 ГБ, а не 2 ТБ. Ви дійсно дуже хочете, щоб ці диски писали послідовно якомога більше і зменшували випадкові записи.

Випадкові записи викликаються кількома способами. Якщо ваша система резервного копіювання просто копіює файли на нове місце, ви просто створюєте файли мільйонів, і резервні копії будуть у цьому випадку неминуче випадковими. Ви хочете уникати резервних систем, які роблять це. Якщо ваша резервна система створює великі архівні файли (наприклад, 10 ГБ файлів), випадкові введення / виведення трапляються, коли ці файли фрагментуються.

Уникнення фрагментації великих файлів вимагає декількох кроків:

• Переконайтесь, що в будь-який момент часу записується лише один файл.
  • Є кілька винятків із цього, якщо ви працюєте у файловій системі правильного типу в Linux, але я не знаю, чи є ви. Якщо ви користуєтесь NTFS, дотримуйтесь одного автора.
• Має бути достатньо вільного простору для того, щоб один великий файл писався одним шматочком.
  • Після деякого часу ви біжите, слідкуйте за своєю діаграмою фрагментації.
• Якщо можливо, налаштуйте систему резервного копіювання, щоб створити файл загалом перед використанням. Ви можете отримати кілька 10 ГБ файлів, які в основному порожні, але принаймні вони суміжні і допоможуть зменшити фрагментарність в процесі старіння системи.

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

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