Якщо для повного резервного копіювання LTO-3 потрібно більше однієї стрічки. У чому полягає мій наступний крок обладнання?

ГАРАЗД. деякі фактори враховують

Я використовую Backup Exec 12.x / 13.x, маю середовище сервера 2003/2008, включаючи Exchange.

У мене відбувається резервне копіювання на диск (Full / Diff), яке не залежить від резервного копіювання на LTO (Full / Diff). З декількох причин я не хотів би просто перейти на створення резервного копіювання з диска на магнітофон, і я хотів би тримати резервну копію прямо в LTO.

В даний час у мене є один привід LTO-3 без навантажувача / робота / бібліотеки. У коробці, що обслуговує привід LTO, в ній є карта Adaptec 39160 Ultra160 SCSI . В даний час я використовую одну стрічку для Full (одна на тиждень) та одну стрічку для Diff (чотири дні на тиждень до зняття стрічки). Повна резервна копія наштовхується на бар’єр 372,5 Гб, і коли резервне копіювання не закінчується в суботу, він все ще чекає стрічки в понеділок вранці.

Уорд згадав про те, щоб поставити другу повну стрічку LTO3 в понеділок вдень / ввечері після звичайного робочого часу. Проблема з цим порівнюється нижче:

Нормальний потік

• В п'ятницю вставити LTO3 стрічку 1 для повного резервного копіювання за 1 тиждень
• Понеділок вставте стрічку LTO3 для диференціала
• У вівторок, середу, четвер різниці використовують стрічку, яку вставили в понеділок
• повторити протягом 2 тижня

2 стрічки LTO3 для повного резервного потоку

• В п'ятницю вставити LTO3 стрічку 1 для повного резервного копіювання за 1 тиждень
• Понеділок вставляйте LTO3 стрічку 2 для повного резервного копіювання за 1 тиждень
• Понеділок вставляйте LTO3 стрічку 1 для повного резервного копіювання за тиждень 1 (для перевірки процесу)
• В понеділок вставляйте LTO3 стрічку 2 для повного резервного копіювання за тиждень 1 (для перевірки процесу)
• У вівторок вставити стрічку LTO 3 для диференціалу
• Середа, четвер різниці використовують стрічку, яку вставили у вівторок
• повторити протягом 2 тижня

Додаткові заміни стрічки їдять через понеділок через 6 годин (починаючи з моменту, коли я кладу другу стрічку). Якби я зробив це о 5:00, я був би тут майже до півночі, міняючи стрічки. Це не рахуючи часу простою в Sat / Sun / Mon в очікуванні стрічки.

Тепер я можу вимкнути процес підтвердження та зберегти дві заміни стрічки та скоротити процес "резервного копіювання" на кілька годин, але я не можу просто поставити стрічку 2 і піти пізніше наприкінці дня, якщо не вимкну перевірку . Після розливу резервної копії на другу стрічку подовжує процес резервного копіювання, але він також

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

І так, я не збираюся в суботу сидіти там 6+ годин і няню диска з стрічкою. Я хотів би мати життя поза роботою. 12 годинних днів ПН досить погані, коли вони трапляються. Я не збираюся постійно прив’язуватися до 6-денного робочого тижня.

Стрічковим приводом є Dell PowerVault 110T LTO3. Сервер резервного копіювання на Gigabit Ethernet використовує лише один NIC і може заповнити повну стрічку приблизно за 12 годин.

Я можу змінити процес резервного копіювання, щоб відокремити один з найбільш інтенсивних серверів на повну резервну копію на власній LTO, щоб тимчасово відключити це рішення, але незабаром я думаю, що мені потрібно вибрати один із таких варіантів:

1. Купіть привід LTO-3 і скористайтеся наявністю другої фізичної стрічки. Це менш бажаний варіант і має сенс лише, якщо диски LTO-3 значно дешевші, ніж диски LTO-4, що не так.

2. Купіть привід LTO-4 та використовуйте стрічки LTO-4 для повного резервного копіювання та використовуйте стрічки LTO-3 для диференціалів, поки стрічки LTO-3 не обертаються і нові стрічки LTO4 не відповідають ціні стрічок LTO3. Це, ймовірно, отримає мене через резервні вихідні на довгі роки, не змінюючи стрічки. Це також частково стосується взуття, оскільки LTO4 має меншу мінімальну швидкість, ніж LTO3.

3. Купіть те, що може автоматично подавати стрічки. Я припускаю, що до PowerVault 110T я не можу додати щось, і це означатиме придбання нового пристрою, який має стрічку та завантажувач в одному блоці. Це, мабуть, не рентабельно - просто отримання накопичувача та завантаження стрічок вручну, але автоматичне завантаження LTO4 було б найбільшою зручністю. Я дозволю начальнику над мною вирішити між одиночним стрічкою та автозавантаженням.

Еван Андерсон в іншому рішенні зазначив, що ви можете придбати накопичувачі в межах цього цінового діапазону

 LTO-4 (internal drive, 1 tape / day) - $2,766.00  
 LTO-4 (autoloader, 1 tape / day) - $4,566.00

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

Я хочу зробити необхідну покупку деякий час в дорозі, перш ніж ця обертання резервного копіювання стане занадто громіздкою. У мене, мабуть, є кілька місяців.

Ксенні згадує вік серверів та швидкість резервного копіювання. Серверу Exchange 6 років (хоча жорсткі диски набагато новіші). Є кілька 4-річних серверів у поєднанні з дисками сата дисками (WD6400AAKS). Сервери, які я вважаю "новими", на сьогоднішній день мають 2 роки.

Резервне копіювання на диск зі старого сервера обміну було таким же швидким, як 2184 Мб / хв, але в цілому резервне копіювання на диск настільки ж повільне, як і резервне копіювання на стрічку. Насправді резервне копіювання на диск іноді відбувається повільніше, ніж резервне копіювання на стрічковий накопичувач LTO-3. У мене також виникли проблеми з відмовою від накопичувачів та відсутністю відсіків, щоб додати більше дисків. Загалом, резервне копіювання на диск - це навіть більше, ніж перехід LTO3 / 4, але це стосується іншого питання на сервері за замовчуванням, якщо я хотів би ввести інформацію про цю тему.

Я просто підберу кілька номерів із недавньої резервної копії, щоб дати уявлення про швидкість. Це не повний перелік, але дає уявлення про різноманітність швидкостей, що стосуються. Я планую найближчим часом оновити це у форматі староспектного МБ / хв новоспеченого МБ / хв, де oldspeed є старим SCSI 320 LTO3, а newspeed - SAS LTO4.

DC C: ~ 850 Мб / хв
Стан системи постійного струму ~ 700 МБ / хв
Exchange Server C: і стан системи ~ 500 МБ / хв ~ 600 МБ / хв
D Сервер обміну D: ~ 1400 МБ / хв ~ 1200 МБ / хв
Перший сервер Exchange Група зберігання ~ 1100 МБ / хв ~ 700 МБ / хв. Веб-
сервер C: ~ 600 МБ / хв ~ 950 МБ / хв.
Веб-сервер E: ~ 1700 МБ / хв ~ 1950 МБ / хв.
Файловий сервер С: ~ 500 МБ / хв Файл-сервер
: ~ 1500 МБ / хв ~ 2200 Мб / хв
Файл-сервер G: ~ 1800 МБ / хв ~ 2400 Мб / хв
Стан системи
файлового сервера ~ 650 МБ / хв факс-сервер C: ~ 400 МБ / хв ~ 550 МБ / хв
Сервер обліку C: ~ 1300 МБ / хв ~ 1775 МБ / хв.
Сервер бухгалтерського обліку D: ~ 1500 МБ / хв ~ 2250 МБ / хв.
Облік SQL примірник ~ 1600 МБ / хв
сервер додатків С: і стан системи ~ 700 МБ / хв ~ 900 МБ / хв
резервний сервер C: 700 МБ / хв ~ 1800 МБ / Хв.
Резервний сервер E: 1350 Мб / хв ~ 2900 МБ / хв

Моніторинг Fileserver Я побачив цифри, які змушують мене думати, що контролер рейду стримує швидкість передачі. Контролером є SATA 1.5, але накопичувачі можуть працювати на 3.0. Я помітив, змінивши обсяги з RAID 1 на RAID 10 і не отримавши збільшення швидкості для резервного копіювання. На жаль, подвоєння стійкої швидкості читання не вплинуло на резервне копіювання на стрічковий накопичувач LTO3.

Загалом, резервне копіювання прямо в LTO дає мені гідний орієнтир того, де мої сервери обмежені вводу / виводу. Сервери, що створюють резервну копію нижче 1500 МБ / хв, як правило, мають повільний диск, а сервіс між ними та 2400 МБ / хв - все ще низько висячим плодом. Наприклад, сервер Exchange 2003 втрачає місце на диску і продовжує розширювати базу даних для першої групи зберігання на повільніші частини дисків. Цей сервер буде замінено сервером Exchange 2010 з більш швидкими процесорами та більшою кількістю дисків. Інші сервери отримають оновлення дисків та / або SSD.

http://en.wikipedia.org/wiki/Tape_drive згадує "Коли відбувається чищення взуття , це суттєво впливає на досягнуту швидкість передачі даних, а також на тривалість роботи диска та стрічки". але це не згадує про взуття, що сяє, зменшуючи ефективну ємність стрічки. Переглянувши архівні стрічки з банку, я можу підтвердити, що на стрічках LTO3 витрачено близько 2% до 15% місця. Ніде недостатньо близько, щоб не переходити до LTO4 чи автонавантажувача, але це може бути значним. Для тих, хто з Backup Exec, ви можете розрахувати свої відходи для взуття:

• Зробіть резервне копіювання, яке дозволить створити резервне копіювання близько 100% натурної ємності стрічок без стиснення. Вимкніть стиснення диска та програмного забезпечення під час запуску тесту.
• подивіться на вкладку "Медіа" резервного копіювання exec та порівняйте стовпець "використана ємність" зі стовпцем "Дані". Якщо стиснення вимкнено і цифри збігаються, ви взагалі не взуття.

У моєму випадку у мене була архівна стрічка LTO3 з 272,4 ГБ "використано", але лише 233,67 ГБ "даних" та ще одна з 400,6 ГБ проти 395,19 ГБ. Я також спробував створити резервну копію на LTO4 без стиснення і отримав 833 ГБ "використано" лише 786,77 ГБ "даних". Очевидно, що взуття буде відрізнятися від мого оточення до вашого, але до цього я не думав це перевіряти. Сподіваємось, це дасть вам зрозуміти, як розібратися, скільки ви витрачаєте стрічки у вашому резервному середовищі.

редагувати: нова інформація на веб- сайті http://www.fujifilmusa.com/shared/bin/LTO_Overview.pdf, де відображаються мінімальні швидкості стрічки для LTO3 та LTO4. Схоже, що IBM LTO4 насправді має меншу мінімальну швидкість, ніж IBM LTO3. У будь-якому випадку мій середній сервер занадто повільний, щоб годувати LTO3 / 4 без взуття. Мене хвилює навіть те, що резервне копіювання дискових локальних томів буде надто повільним, щоб швидко подати диск, але мені доведеться перевірити це.

Витягуючи інформацію про повний зріст IBM з PDF вище, я отримую

LTO4 : 30-120MB/s 800GB native (45-240MB/s compressed)
LTO3 : 40- 80MB/s 400GB native (60-160MB/s compressed)
LTO2 : 18- 35MB/s 200GB native (27- 70MB/s compressed)
LTO1 : 15- 15MB/s 100GB native (30- 30MB/s compressed)  

Оновлення : Сервер, який я використовував для резервного копіювання, почав видаляти помилки, тому я перемістив стрічковий диск на інший сервер. Старий контролер SCSI був Adaptec 160, "новий" контролер - це LSI на базі 320 (принаймні, я припускаю, що зовнішній роз'єм є 320, оскільки 4 жорстких диска всередині сервера згадують 320 SCSI в управлінні сервером).

Нова ситуація з сервером залишає мене без резервної копії на диску тимчасово, поки я не отримаю зовнішній корпус для прямого доданого сховища. Взагалі ця дискусія LTO вказала мені на купівлю більше жорстких дисків для моїх серверів. Мені доведеться виконати перенастроювання масивів RAID, щоб збільшити швидкість резервного копіювання та, сподіваюся, підвищити надійність загальної настройки.

Оновлення 2 : Для порівняння, наведеного нижче, використовується старий сервер файлів, у якого вузькі вузли контролера рейду всі передачі при ~ 40 Мб / с, так що ідеально було б близько 2400 МБ / хв. Йдеться про швидкість, необхідну для перевірки краю взуття. Імовірно, потік даних не буде ідеально регулярним і змусить відповідати швидкістю майже весь шлях через тест.

Я більше не знаю розмір буфера та кількість буфера, який я використав для тесту на швидкість старого дисковода LTO3, але він це зовсім не змінив, я отримав, можливо, 100 Мб / хв посилення від настройки буферів. Дані тесту становлять близько 20 ГБ відсканованих тифів і jpgs. Я робив ці тести в п’ятницю вдень, і я не повторював тести достатньо разів, щоб оцінити дані або іншим способом вилучити недійсні дані. Тестування після години, вибір різних даних та інших змінних може помітно вплинути на ці тести.

У всіх тестах використовуються однакові сервери. Старий диск знаходиться на 320 SCSI-контролері LVD, який є PCIx. Новий привід знаходиться на контролері PCIe LSI 3801E SAS. Можливо, що контролер приводу та / або стрічковий привід LTO3 є вузькими місцями. Я не буду тестувати окремі компоненти, лише старе спарене порівняно з новим. Сервер, на якому працює Backup Exec, має 4 ГБ оперативної пам’яті, 32-бітний стандарт 2008 Server, двоядерний процесор Pentium D 3,2 ГГц.

Підключення до мережі здійснюється за допомогою комутатора 1 Гб, обидва сервера перебувають на одному комутаторі. У мене відкрите підключення до віддаленого робочого столу, але при цьому відбувається резервне копіювання + це з'єднання Gb використовується менше, ніж на 50%, і в середньому перевищує 25% використання.

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

Короткі результати тестування :
~ 1500 МБ / хв за допомогою приводу Dell LTO3 та стиснення стрічки LTO3 ON, розмір блоку 64 КБ (тестування багатьох буферів, найкращий результат перерахований тут)

~ 1800 Мб / хв, використовуючи привід Quantum Superloader3 LTO 4 із стрічкою LTO3 (таку ж стрічку, як і вище), стиснення ON, розмір блоку 64KB, розмір буфера 64KB, кількість буфера 10, кількість підводних вод 0, запис режиму одиночного блокування ON, запис SCSI-проходу- через режим ВКЛ

~ 2150 Мб / хв, використовуючи привід Quantum Superloader3 LTO 4 із стрічкою LTO3 (таку ж стрічку, як і вище), стиснення ВКЛ, розмір блоку 256 КБ, розмір буфера 256 КБ, кількість буфера 10, кількість високої води 0, Запис одноблочного режиму ВКЛ, Написання проходу SCSI- через режим ВКЛ
~ 2200 Мб / хв, використовуючи привід Quantum Superloader3 LTO 4 із стрічкою LTO3 (таку ж стрічку, як і вище), стиснення вимкнено, розмір блоку 256 КБ, розмір буфера 256 Кб, кількість буфера 10, підводне число 0, запис режиму одиночного блоку ВКЛ, запис Увімкнено режим проходження SCSI

~ 2050 Мб / хв, використовуючи привід Quantum Superloader3 LTO 4 з компресією стрічки LTO4, розмір блоку 256 КБ, розмір буфера 256 КБ, кількість буфера 10, підводне число 0, запис режиму одиночного блокування ввімкнено, запис режиму проходу SCSI ВКЛ
~ 2250 МБ / хв, використовуючи привід Quantum Superloader3 LTO 4 з вимиканням стрічки LTO4, розмір блоку 256 КБ, розмір буфера 256 КБ, кількість буфера 10, підводне число 0, запис режиму одиночного блоку ввімкнено, запис режиму проходу SCSI увімкнено

~ 2050 Мб / хв, використовуючи привід Quantum Superloader3 LTO 4 з увімкненою компресією стрічки LTO4, розмір блоку 256 КБ, розмір буфера 1 МБ, кількість буфера 10, підводне число 0, запис режиму одиночного блокування ввімкнено, запис режиму проходу SCSI ВКЛ
~ 2300 МБ / хв, використовуючи привід Quantum Superloader3 LTO 4 з віджиманням стрічки LTO4, розмір блоку 256 КБ, розмір буфера 1 МБ, кількість буфера 10, підводне число 0, запис режиму одиночного блокування ВКЛ, запис режиму проходу SCSI

~ 2200 Мб / хв з допомогою квантової Superloader3 LTO 4 приводу з LTO4 стиснення стрічки ON, 256KB розміру блоку, 1 Мб розміру буфера, буфер розраховувати 20, HighWater підрахунок 0, запис Одиночного режиму блоку ON, запис SCSI наскрізного режиму ON
~ 2300 МБ / хв з використанням накопичувача Quantum Superloader3 LTO 4 з компресією стрічки LTO4, розмір блоку 256 КБ, розмір буфера 1 МБ, кількість буфера 20, підводне число 0, запис режиму одиночного блоку ввімкнено, запис режиму проходу SCSI у ВКЛ

Зрозуміло, що настройка блоку важливіша за розмір буфера. Незалежно від розміру блоку або буфера, який ви використовуєте, ви отримаєте кращу ефективність, вимикаючи стиснення, якщо ваші вихідні дані не встигають за мінімальною швидкістю відповідності стрічкових дисків. На жаль, це налаштування на один привід, а не для роботи чи за форматом стрічки, тому ви не можете просто обмежувати стиснення лише повними резервними копіями або LTO3. Вам також доведеться перевірити, наскільки проблема полягає у поєднанні обладнання та програмного забезпечення. Зрозуміло, що удари в продуктивності незначні, і більш важливими тестами буде оптимізація Повної резервної копії від 600 до 800 ГБ замість 20 ГБ. Я спробую оновити ще раз, коли у мене буде кілька тижнів чи місяців резервного копіювання.

Зауважте, що 100 МБ / хв набагато нижче мінімальної швидкості для потокової стрічки з LTO 3, тому ви, ймовірно, втрачаєте неабияку потужність із зупинкою та запуском стрічки (тобто ви, ймовірно, покращуєтесь на 1,5: 1 стиснення, але це втрачається в прогалинах даних на стрічці). Мабуть, це буде гірше з LTO 4, оскільки я думаю, що мінімальна швидкість піднялася.

Disk - Disk - Стрічка допоможе вирішити проблему з мінімальною швидкістю та надасть вам деяку ємність безкоштовно.

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

Редагування: Для LTO 3 ви дійсно бажаєте розміру блоку в 256 КБ для найкращої продуктивності.

Взуття WRT світиться. Немає часу, щоб стрічка перемоталася, якщо буфер коротко працює порожнім, тому він залишить пробіл на стрічці.

неминуче резервне копіювання перевищує потужність, яку ви спочатку планували. Ось що я б запропонував і сказав про вашу ситуацію:

1. Так резервна копія Full перевищує ємність однієї стрічки. Потім використовуйте дві стрічки.

2. Дотримуйтесь рекомендацій Symantec і продовжуйте робити резервну копію на диску, а потім створюйте резервні копії цих дисків на стрічку. плануйте, щоб резервні копії на диск відбувалися через години, коли використовується менше ресурсів. плануйте, щоб резервні копії на стрічку відбувалися в будь-який день протягом дня після завершення резервного копіювання на диску, оскільки резервне копіювання на стрічку не впливає на виробничі системи.

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

4. плануйте, щоб резервні копії на стрічку відбувалися лише протягом тижня, коли ви там, щоб поміняти стрічки.

У мене схожа ситуація, я використовую Dell powervault 110t lto2 диск, і ось що я роблю:

1. в суботу я беру повну резервну копію на диск (резервна копія на папку диска для повних резервних копій).

2. в понеділок по п’ятницю я беру додаткові резервні копії на диск (ще одна резервна папка на диск для інкременталів).

3. Понеділок по п’ятницю я беру резервні копії на стрічку повного та додаткового резервного копіювання на папки диска. коли стрічка досягає своєї ємності, я поміняю її. якщо він досягне ємності посеред ночі, я поміняю його на наступний ранок, і робота зі стрічкою закінчується.

4. після п’ятниці резервне копіювання на роботу із стрічкою я міняю стрічки на наступний тиждень. дві стрічки, які я витягаю, - це повна та додаткова величина від поточного тижня, і я переходжу до моєї 4-тижневої ротації. Тепер я знаю, що всі поточні тижні резервного копіювання даних є на одній стрічці, яка зберігається поза сайтом.

промити і повторити

Ми робимо щось схоже на Джо:

1. субота: повна резервна копія на диску, коли це зроблено, запустіть повну резервну копію цього на касету
2. понеділок: наприкінці дня заклейте другу стрічку і нехай резервна копія закінчиться
3. пн-пт: диференціальне резервне копіювання лише на диск

Якщо ви дійсно повинні робити диск-стрічку незалежно від резервного копіювання диска, я живу, якщо дві резервні копії трохи не синхронізовані:

1. Запустіть диск-диск та диско-стрічку в суботу, диск-диск закінчиться, а диск-стрічка буде чекати другої стрічки в понеділок
2. Закінчіть диск-стрічку в понеділок (я б ще зачекав до кінця дня, щоб поставити стрічку).
3. Пн-пт, зробіть свої дискові дискові диференціали (насправді я бачу, що ви цього не говорите, але я припускаю, що ви це робите)
4. Вт-пт, зробіть свої дисково-стрічкові диференціали

Я не бачу проблем із створенням резервних копій файлів на двох різних носіях. Майже у всіх випадках ви збираєтесь відновити файл із резервної копії диска. Стрічка - це лише резервна копія або простий спосіб впорядкувати кілька наборів резервних копій.

Ось один варіант, який може допомогти вам на деякий час:

Чи розглядали ви розбиття резервної копії на два окремих набори даних? Залежно від того, як організовані ваші файли, ви можете легко розділити їх на два логічні фрагменти (тобто за відділом). Ви зробили б повну резервну копію першого набору даних у ніч на четвер, а повну резервну копію другого набору даних у ніч на п'ятницю. Кожну ніч після цього буде виконуватися два завдання на одній стрічці, що відрізняється для кожного набору даних.

Таким чином, ви не приїжджаєте у вихідні дні, і вам не доведеться няні їздити, чекаючи завершення перевірки. Крім того, ви отримуєте додатковий захист від того, щоб не мати всіх своїх яєць в одному кошику, так би мовити.