Як зробити резервну копію SAN?

читач давно, перший запитувач :)

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

Як ви "створюєте резервну копію SAN?"

Далі йде більш-менш реальний сценарій та мої думки та запитання щодо нього.

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

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

Але тепер потрібно мати резервне рішення для всіх або більшості збережених даних. Як ти це робиш? Чи запускаєте програмне забезпечення для резервного копіювання (мені подобається rsnapshot) на кожному сервері, який має дані для резервного копіювання? Куди ви кладете ці дані? На спеціальному резервному сервері з великою кількістю локального сховища? Або знову в САН? Яке "загальне" рішення, якщо воно є, для резервного копіювання SAN?

Я шукаю кращих практик та порад у людей, які мають більше досвіду, ніж я, які керують SAN.

Спасибі!

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

Ми використовуємо кластер SAN NetApp 3020 SAN з даними iSCSI, FC та CIFS. Цей продукт підтримує скидання NDMP до локально приєднаного автонавантажувача SCSI. Використовуючи це, я отримую ідеальні копії своїх iSCSI та FC LUN, а також резервне копіювання файлів моїх CIFS даних, що передаються з NetApp. Я використовую BackupExec для управління резервними копіями NDMP, а швидкості виняткові, оскільки це локальне підключення SCSI до NetApp.

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

По суті, у мене є SAN, який обробляє мої виробничі дані, потім у мене є резервний сервер із досить пристойним розміром локально прикріпленого сховища, який приєднаний до бібліотеки стрічок (LTO-3, який є 400 Гб, нестиснений / стрічка)

По суті, я роблю резервні копії на рівні даних. Оскільки я запускаю Linux, я роблю rsyncs для отримання даних з SAN-приєднаної машини до резервної машини, потім я записую дані на стрічку. Мені пощастило, що у мене достатньо локального сховища на сервері резервного копіювання, що я можу зберігати копію локально, а потім просто rsync відмінності, але якщо ви не можете встановити це, багато резервних рішень використовують ідею скручування каталог для локального зберігання даних під час запису на стрічку.

Через те, що пише стрічка, дуже погана ідея прямувати з мережі на стрічку безпосередньо, наприклад, спільний доступ до файлів Windows або NFS. Це повністю вбиває швидкість запису на стрічку І вбиває термін експлуатації вашої магнітоли. Тому використовуйте локальний диск, щоб вивести дані на нього.

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

EDIT

Оскільки ви згадали про відсутність стрічок, я рекомендував би віртуальній бібліотеці стрічок (VTL) бідолахи, тобто зовнішніх накопичувачів USB. Аманда, принаймні, може адресувати файли так, ніби вони були VTL, і я впевнений, що можуть також і інші програмні пакети.

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

Про найдешевший (і найслабший) спосіб резервного копіювання, який ви могли зробити, - це робити знімки навколо, з деякою формою періодичного резервного копіювання на довший термін.

Це передбачає, що знімки дешеві - це залежить від того, як вони реалізовані. Копіювання файлових систем запису, таких як WAFL NetApp та ZFS SUN, має знімки, які практично дорівнюють нулю, на відміну від O (n) вартості знімків копіювання. Дешеві знімки дійсно дуже приємні.

Просто збереження знімків навколо насправді не є резервним рішенням, але я не впевнений, що будь-яке реальне рішення можливе під вашими обмеженнями без серйозних злому.

Також я тут серйозно упереджений як розробник NetApp, але вам слід серйозно поговорити хоча б з деякими продавцями NetApp, перш ніж зробити висновок, що вони вийшли з вашого цінового діапазону. :-)

Бібліотека стрічок з додатковою або волокнистою зв'язком + NDMP може бути досить гладким рішенням, але якщо ваша система зберігання не може використовувати щось подібне для запису на касету або якщо бюджет особливо обмежений, можливо, ви можете мати використовувати традиційне рішення для резервного копіювання даних в LUN через клієнт резервного копіювання на хості, приєднаному до SAN.

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

Хоча функціональність NDMP іноді включається до системи зберігання даних (a NetApp), додатки для резервного копіювання можуть фактично стягувати додаткові кошти за резервне копіювання за допомогою NDMP. Наприклад, у нашому середовищі NetBackup ліцензії NDMP були набагато дорожчі, ніж звичайні ліцензії на резервне копіювання ОС-клієнта.

oops .. просто оновився і побачив ваше доповнення re: не маючи $$ для стрічок. Де ви плануєте розміщувати резервні копії, якщо не на стрічці чи іншому SAN?

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

Ми продовжували використовувати наявну інфраструктуру резервного копіювання, яку ми мали, перш ніж навіть переїхати до SAN. У нас є окремі хости, які працюють Legato Networker щоночі скидають у систему Storagetek Tape. Чесно кажучи, якщо ви шукаєте дешеве рішення ... резервне копіювання на диск, мабуть, найдешевше, ви також маєте можливість транспортувати ці накопичувачі в інше місце, якщо це потрібно, подібно до стрічок.

Оскільки у вас немає багато даних, знайдіть використаний SDLT або ранній стрічковий накопичувач LTO 1,2 ... навколо них сотні, оскільки вони застарілі порівняно з LTO-3, 4