Групи доступності alwayson і завдання sql server: заключні міркування щодо резервних копій

Відео: SQL Server 2012 AlwaysOn. Огляд нової технології

Перерахуємо, що потрібно зробити і за чим простежити в процесі управління резервними копіями і для груп доступності AlwaysOn.
• Забезпечте регулярне тестування резервних копій. В одних мережах досить буде робити це раз на тиждень або раз на місяць, в інших навіть інтервал в добу може виявитися занадто великим - тільки ви можете судити про те, наскільки важливо для ваших даних перебувати під постійною зашітой- і не забувайте, що дані високої доступності не належать до тієї ж категорії, що і дані, що захищаються від аварійних відмов, таких як певні форми ушкоджень, програмні збої, помилки користувачів і т. д.
• Обов`язково документуйте всі процеси і процедури, необхідні для відновлення даних у надзвичайній ситуації. Підготовкою такої документації дол дружин займатися співробітник, який може дати роз`яснення по максимальному числу надзвичайних ситуацій та задокументувати способи виходу з таких ситуацій або пояснення до них, але написана вона повинна бути на рівні, зрозумілою для техніків молодшої ланки, оскільки, швидше за все, саме такі фахівці прибудуть за викликом або будуть знаходитися на чергуванні в момент збою бази даних.
• Подбайте про те, щоб у вас під рукою були угоди про рівень обслуговування або документи, що визначають допустимий обсяг можливих втрат даних, а також прийнятний час простою в разі сбоя- вони допоможуть вам визначити показники експлуатаційної готовності. Якщо ці показники не будуть чітко визначені і доступні, ви просто не зможете домогтися успіху. Можливо, ви відновите дані після катастрофічного збою, проте може статися, що ніхто з керівництва не має ні найменшого поняття про те, що система SQL Server може простоювати протягом якогось часу, і ніхто не чекатиме «справжнього» простою, тому що , згідно з уявленнями керівництва, ви заплатили за обладнання та ліцензії SQL Server, а значить, отримали гарантію того, що ваші бази даних завжди доступні.
• Обов`язково простежте за тим, щоб ваша документація містила відомості про те, як здійснюється діагностика максимально широкого кола несправностей (відмови кластерів, пошкодження баз даних, пошкоджені або зламані бази даних, потенційно пошкоджені бази даних і т. П.).
• Прослідкуйте за тим, щоб у ваших документах по відновленню після аварійного збою містилася інформація про те, який вищої інстанції слід передавати питання (включаючи актуальну контактну інформацію), якщо події будуть розгортатися не так, як ви очікували.



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





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


Крім того, вам потрібно буде звертати особливу увагу на «фрагментацію» резервних копій (розглянуту в одній зі статей серії), а також забезпечувати коректну «синхронізацію» завдань резервного копіювання та логічних схем на всіх хостах для реплік (як описано в попередніх статтях). Отже, з резервними копіями ми розібралися, і тепер настав час переходити до четвертого розділу справжньою серії, в якому я розгляну більш складні теми (такі, як головні сервери, групи доступності, що розміщуються в декількох подсетях, і т. Д.) І розповім про деякі альтернативні варіанти вирішення проблем управління завданнями і синхронізації.