Чи можна знімки NetApp використовувати як резервні копії?

Наш магазин дуже сильно покладається на знімки обсягу NetApp для створення резервних копій. Ми використовуємо традиційні резервні копії стрічок на основі агентів для деяких наших даних, але за великим рахунком ми покладаємося на знімки для більшості наших систем. Крім того , ми не маємо сувору політику контролю змін або будь-централізоване управління конфігурацією , так всенаших серверів, незалежно від того, резервні копії даних, які надають їхні послуги, потрібно було б перебудувати з голого металу (і без будь-якої реальної документації). Звичайно, це робить знімки дуже привабливою пропозицією для управління, оскільки ми можемо просто відновити весь сервер, дані користувача та конфігурацію. Ми використовуємо консоль віртуальної пам’яті NetApp для створення знімків наших сховищ даних VMware на базі NFS та SnapDrive NetApp для сировинних пристроїв, відображених (фізичні) LUN, які подаються безпосередньо гостям. Ми робимо критичні знімки SnapMirror в іншому Filer. Звичайно, ми регулярно перевіряємо процес відновлення.

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

• Резервна копія повинна бути атомною. Тобто, резервне копіювання не може розраховувати ні на що інше для його відновлення.
• Резервну копію потрібно відокремити від системи, це резервне копіювання (поза діапазоном).
• Резервну копію потрібно скопіювати або перевезти на віддалений сайт (поза сайтом)

Як я розумію, знімки NetApp працюють за методологією Redirect-On-Write (RoW). У макеті файлів WAFL використовується набір покажчиків (метаданих?), Які насправді посилаються на кожен блок зберігання, де б він не був. Щоб зробити знімок, система просто бере копію метаданих тома і зберігає їх у зарезервованому просторі. Будь-які записи (створення / зміни / видалення) переспрямовуються на нові блоки. Це повинен бути спеціальний соус, який робить WAFL NetApp таким чудовим, що вам не потрібно читати, а потім записувати старі дані в зарезервований простір, а потім записувати ваші нові дані на старі, як знімки Copy-On-Write.

Я повністю визнаю, що я не можу точно зрозуміти, як працюють зйомки NetApp Volume Snapshots, але якщо моє розуміння є більш-менш правильним, Snaphots NetApp не відповідає моїм критеріям резервного копіювання.

• Вони не атомні. "Знімок" - це насправді лише набір покажчиків на вихідні дані. Якщо вихідних даних більше немає, метадані марні.
• Знімок не відокремлюється від системи. Якщо хтось видаляє неправильний том, я втрачаю знімок. Якщо NetApp Filer вибухне на маленьких кошенят, я втрачаю резервну копію. Я можу використовувати SnapMirror для переміщення моїх знімків до іншого Filer, але знову ж таки, це просто переміщення метаданих, а не фактичних блоків. Якщо я втрачу оригінальний об'єм, я не бачу, як знімок, скопійований на інший Filer, допоможе.

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

Резервні копії виконують дві функції.

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

Ніякої політики утримання

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

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

Розглянемо цю ситуацію:

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

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

Підсумок

Знімки Netapp не захищають вас від реальної втрати даних. Якщо заблокований обсяг видаленого тома або втрата даних на файлі вимагають відновлювати дані.

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

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

Вони досить добре захищають від будь-яких помилок або проблем користувачів, які не користуються нетаптом (системи, що отримують доступ до томів).

Вони не захищають від катастрофічних апаратних збоїв самого netapp. Я розумію, що SnapMirror копіює всі дані (на знімку) на інший файл [1], тому SnapMirroring до іншого файлера повинен захищати цей набір даних від катастрофічних збоїв одного файлера.

Основна проблема, звичайно, полягає в тому, що якщо хтось, хто керує netapp, видаляє гучність, то всі знімки йдуть з нею. SnapMirror до іншого файлера повинен адекватно захищати від цього.

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

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

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

[1] http://www.netapp.com/us/system/pdf-reader.aspx?m=snapmirror.pdf&cc=us

Ви повинні прочитати відмінну відповідь @Basil зараз, але ось два мої центи:

Знімки не відомі додаткам

Тільки тому, що ви зробили знімок базового обсягу пам’яті, це не означає, що дані цього об’єму підлягають відновленню. MS SQL є прекрасним прикладом цього - вам потрібно переконатися, що ваша база даних є транзакційною, перш ніж зробити знімок сховища, яке він використовує інакше, як @freiheit згадав, що вам не краще, ніж відновитись після відмови. DBA люблять використовувати різні LUN для різних частин SQL для кращого використання системи зберігання, тимчасових баз даних на швидкому зберіганні, системних баз даних для повільного зберігання, лише для читання або архівуваних даних на масовому зберіганні та робочих даних десь посередині. Якщо ви тільки ті томи миттєвих знімків це дуже малоймовірно , що ви зможете відновити базу даних.

NetApp постачає ряд інструментів Snap для ознайомлення з додатком знімків. SnapManager для SQL забезпечує цю обізнаність. В екосистемі Microsoft, я вважаю, є також інструменти SnapManager для Exchange та SharePoint. SnapDrive не має цієї програми. Він просто забезпечує зручний спосіб управління сховищем в межах гостя.

Якщо ви зберігаєте всі ваші дані IIS та конфігурацію на LUN та знімаєте ці LUN безпосередньо, ви не можете гарантувати, що дані підлягають відновленню. Запитайте мене, як я знаю ...

Кілька типів зберігання можуть мати різні графіки знімків

Якщо ви представляєте сховище на своїх серверах різними способами, це може ускладнити ваше знімок та зображення відновлення. ONTAP NetApp - це багатопротокольна пропозиція, і цілком можливо, що ви використовуєте більш ніж один метод або тип зберігання для певного сервера. У нашому магазині деякі наші сервери отримують свій C: \ диск через сховище даних на базі NFS та їх "накопичувальні" накопичувачі через неочищені LUN-адреси пристрою. Ми робили знімки RDM LUN, але не сховища даних NFS. Це ускладнило відновлення сервера .

Знімки не мають гарантованої політики утримання

Знову ж таки, @Basil дійсно висвітлює це добре, але варто ще раз повторити. Можна заповнити свій Snap Reserve таким чином, коли Snpashot Autodelete видаляє знімки, які, природно, не старіли до видалення. Знову. Це може бути дуже погано, якщо ви або ваші клієнти очікуєте, що знімки три тижні будуть доступні.

Знімки є вбудованими

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

Знімки дозволяють продовжувати погані оперативні практики

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

І тоді приходять знімки! Нам не потрібно відступати і звертатися до деяких наших основних оперативних практик, оскільки ми можемо просто зробити знімок усіх наших серверів! І ми можемо використовувати SnapMirror для переміщення цих знімків поза сайтом, щоб ми могли використовувати їх як резервні копії!

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