Варіант стратегії швидкого і надійного резервного копіювання / відновлення VLDB по мережі, Інші СУБД, Бази даних, статті

Автор: Томас Грохсер (Thomas H. Grohser)
За сприяння: Ліндсей Аллен (Lindsey Allen)
Технічна експертиза статті: Sanjay Mishra, Lubor Kollar, Stuart Ozer, Thomas Kejser, Juergen Thomas, James Podgorski, Burzin Patel
Переклад: Олександр Гладченко, Ірина Наумова
Редактура перекладу: Олексій Халак
Дата видання: червень 2009р.
Тематика статті: SQL Server 2008

Резюме: Розмір баз даних безперервно зростає, так само, як і зростають вимоги до надійності і доступності баз. Одночасно з цим як ніколи важливим стає вимога швидкого і надійного відновлення даних. Цей документ присвячений проблемам проектування сталого резервного копіювання і рішень з відновлення дуже великих баз даних (VLDB). У цій статті на реальному прикладі демонструється як найкраще використовувати функціональність SQL Server 2008 для здійснення резервного копіювання і відновлення, якими володіє SQL Server 2008, А також створення планів резервного копіювання і відновлення VLDB по мережі.



Введення


Резервне копіювання і відновлення баз даних у SQL Server схожі на багато інших, що оточують нас в реальному світі речі; Ви зможете не зрозуміти їх цінність, коли зіткнетеся з ними вперше. За ці роки всі ми стикалися з такими ситуаціями, коли не виявлялося під рукою потрібної резервної копії; наслідком цього ставала втрата бізнесу компанією, втрата роботи для людей і втрати даних. Компанії знаходять виправдання, для того, щоб не робити резервне копіювання і не створювати план відновлення. Часто чути фрази, подібні цим: “У нас є кластер, так що нам не потрібна резервна копія”, або “Нам не потрібен план відновлення, тому що ми робимо резервні копії кожен день”. Що ми зрозуміли за ці роки, так це те, що резервні копії та план відновлення потрібні у всіх випадках.



Короткий огляд Рішення



Угода про якість сервісу

Найважливіший крок для створення успішної стратегії резервного копіювання, це розробка та затвердження правильного угоди про рівень сервісу (SLA). Якщо вимоги SLA невідомі, неможливо організувати вірну стратегію резервного копіювання і відновлення.
SLA повинне відповісти на наступні питання:


Є багато інших положень SLA, які потрібно не забути погодити, але ми не станемо зупинятися в цій статті на абсолютно всіх положеннях можливого варіанту угоди.
Для розглянутого в цій статті варіанти стратегії, вимоги в SLA були наступні:




Короткий опис

Функції резервного копіювання і відновлення надаються SQL Server досить прості Основним завданням стає проектування рішень, здатних забезпечити виконання всіх вимог бізнесу та заданий рівень ефективності навіть в разі серйозного відмови обладнання або програмних систем.
Дуже великі бази даних (VLDB) привносять свою специфіку і додаткові проблеми в процес резервного копіювання, особливо якщо ці бази знаходяться під великим навантаженням. З метою забезпечення можливості відновлення після аварій цілком резонною мірою є розміщення резервних копій баз даних у різних місцях. Копіювання їх по мережі привносить додаткову складність реалізації, порівняно з резервуванням на локальні пристрої довготривалого зберігання. Уявіть собі завдання по резервному копіюванню OLTP бази даних, розміром в пару Терабайт; з високою робочою навантаженням; з жорсткими вимогами до продуктивності обслуговування транзакцій і доступності; в даній ситуації абсолютно нереально використовувати для резервування програмні інтерфейси (API) віртуальних пристроїв резервування (Virtual Backup Device Interface – VDI), що дозволяють задіяти наявні в сучасних системах зберігання (SAN) можливості резервування, придатні для використання з SQL Server. Крім того, якщо завдання ускладнюється ще й тим, що угоду про якість сервісу вимагає повного відновлення системи менш ніж через 4:00 (включаючи застосування всіх файлів копій журналу транзакцій). Ця технічна стаття як раз і присвячена опису можливого варіанту вирішення саме такого завдання, що реалізується за допомогою засобів SQL Server 2008.
Повне рішення резервного копіювання має включати в себе як повну резервну копію, так і можливо, різницеві резервні копії і безліч резервних копій журналу транзакцій. У описуваної тут стратегії, різницеві резервні копії приводили б до фактичного збільшення сумарної тривалості процедури відновлення баз даних, так що вони в запропонованому рішенні використовуватися не будуть. Резервні копії журналу транзакцій в рішенні присутнім будуть, і виконуватися вони будуть з частотою – один раз на хвилину. Впровадження та настройка рішень, коли резервні копії журналу транзакцій доставляються і відновлюються на іншому сервері, для баз даних великого розміру само по собі досить складна справа, так що опис подібних рішень буде зроблено в інших статтях. Ця ж стаття зосереджена на описі високопродуктивних і добре масштабованих методів створення повних резервних копій.



Як використовувати даний документ

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



Реалізація надійного резервування по мережі

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



Коли резервну копію можна вважати правильною?

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



У підсумку, повний цикл резервування складається з наступних кроків:



  1. Резервне копіювання бази даних.
  2. Копіювання файлів на зберігання в віддалену область. В якості сховища може використовуватися файловий сервер, стрічкове пристрій або їх комбінація (цей крок може бути об’єднаний з першим, коли резервне копіювання здійснюється безпосередньо на пристрій в мережі).
  3. Відновлення бази даних з віддаленої області.
  4. Виконання перевірки відновленої бази засобами DBCC CHECKDB.
  5. Виконання перевірки коректності самих даних, щоб упевнитися в їх логічної правильності з точки зору програми та користувачів. Цей крок є додатковим, але ми рекомендуємо не виключати його з циклу. Основна частина перевірки з прикладної точки зору зачіпає трансформацію (ETL) даних з відновленої бази даних в інформаційне сховище, потім виконується заздалегідь продуманий набір звітів, що дозволяють переконатися в цілісності даних.

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



    Основні опції вбудованого механізму резервування і відновлення

    Вбудовані засоби резервного копіювання і команди відновлення в SQL Server 2008 надають наступні можливості:


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



    Що може піти не так?

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


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



    Виконання надійного резервного копіювання по мережі

    Припустимо, є база даних з ім’ям MyVLDB, яку потрібно зберегти. База даних MyVLDB знаходиться на сервері з ім’ям SQL01. Файл-сервер, на якому ми хочемо розмістити резервну копію, називається BAK01. ПР¾ Ð »Ð ½ Ð ¾ Ñ Ñ, ью Ð º Ð ² Ð ° л Ð ¸ Ñ “Ð ¸ Ñ † Ð ¸ Ñ € Ð ¾ Ð ² Ð ° Ð ½ Ð ½ Ð ¾ Ðμ Ð ¸ Ð ¼ Ñ Ñ” Ð ° Ð ¹ Ð »Ð ¾ Ð ² Ð ¾ Ð ³ Ð ¾ Ñ € ÐμÑ ÑƒÑ € Ñ Ð ° ackup. Ð Ð ° Ñ € Ð ¸ Ñ ÑƒÐ ½ Ð º Ðμ 1 Ð ¿Ñ € Ð ¾ Ð ¸ Ð »Ð» ÑŽÑ Ñ, Ñ € Ð ¸ Ñ € Ð ¾ Ð ² Ð ° Ð ½ Ð ° Ñ Ñ, Ð ° Ð º Ð ¾ Ð ½ Ñ “Ð ¸ Ð ³ ÑƒÑ € Ð ° Ñ † Ð ¸ Ñ.

    Рисунок 11: Конфігурація мережі і дискової підсистеми файлового сервера резервних копій

    Схожі статті:


    Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

    Коментарів поки що немає.

    Ваш отзыв

    Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

    *

    *