Бібліотека користувача. Добірка матеріалів, інструкції, питання відповіді та навчання | covid-19

Резервне копіювання інформації в організації

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

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

Основними тенденціями на 2017-2019 роки ми бачимо наступні види резервного копіювання:

  • копіювання в хмару з будь-яких пристроїв за принципом «підписки» за кожен гігабайт даних за допомогою хмарних сервісів, які через встановлений в систему агент «заливають» копії в хмару. Приклад тому — Commvault
  • копіювання в хмару з допомогою Veaam і подібних продуктів (Acronis / Symantec / HP Data Protector). Вимагає підготовки провайдера, налаштування коннектора між хмарою провайдера і «наземної» віртуальним середовищем.
  • копіювання "інхауси" за допомогою софтових рішень від виробників NAS систем або виділених сховищ корпоративного сектора
  • розподілений бекап за допомогою вбудованих в ОС Windows Server рішень

Завдання резервного копіювання в організації

Створення резервних копій інформації найчастіше переслідує дві мети:

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

Наприклад, в копії для швидкого відновлення системи вам може бути доступна тільки остання, актуальна версія якого-небудь документа, а в архіві можуть зберігатися все його минулі версії.
Ці дві мети цілком можна поєднувати, вести і довготривалий архів, і робити «зліпки» системи для аварійного відновлення, особливо якщо даних небагато і ІТ-інфраструктура компанії нескладна. Але слід чітко розмежовувати: що і з якими цілями ви робите, які використовуєте ресурси для кожного завдання, де і як довго будуть зберігатися ці резервні копії, виходячи з вимог бізнесу.

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

Резервне копіювання VS Надмірне резервування

Щоб устаткування продовжувало працювати, навіть якщо якийсь окремий компонент відмовить, в нього вноситься певна надмірність — «зайві» компоненти або обчислювальні ресурси, які в звичайному робочому режимі можуть здатися непотрібними.

Приклад надлишкового резервування:

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

Розпорядок резервного копіювання

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

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

Види резервного копіювання в організації

Існують різні технології резервного копіювання, які відрізняються витратами коштів і часу:

  • повне резервне копіювання — вибрані дані будуть скопійовані цілком. Найнадійніший спосіб, але потребує найбільшої кількості ресурсів, місця для зберігання даних і часу копіювання, тому в чистому вигляді застосовується рідко, зазвичай комбінується з іншими видами (наприклад, перший раз з системи знімається повна копія, а потім резервуються тільки внесені зміни). Дозволяє відновити втрачені дані з нуля швидше за всіх інших видів копіювання
  • інкрементне копіювання — записуються тільки ті дані, які були змінені з часу минулого бекапа. Для таких копій потрібно значно менше пам'яті, ніж при повному копіюванні, і знімаються вони значно швидше. Зрозуміло, при такому підході необхідно періодично робити і повну резервну копію, при будь-якій аварії систему відновлюють з такої копії, а потім накочуються на неї всі наступні інкрементні копії в хронологічному порядку. Важливий момент: інкрементне копіювання відновлює видалені файли і багато проміжних версій, які змінювалися, так що при відновленні слід передбачити додатковий дисковий простір на цей випадок
  • диференціальне резервне копіювання — схоже на інкрементне, тобто копіюються тільки зміни, зроблені з моменту останнього повного копіювання. Відмінність в тому, що в кожну наступну копію зберігаються зміни з попередньої і додаються нові. Виходить, що для відновлення після аварії знадобиться тільки повна копія і остання з диференціальних, що значно скорочує час відновлення. Мінусами, в порівнянні з інкрементного копіюванням, є великий обсяг копій (іноді можна порівняти з повним копіюванням) і більший час копіювання.
Щоб вибрати відповідний для кожного конкретного випадку вид копіювання, слід попередньо оцінити, як мінімум, скільки місця доступно для зберігання резервних копій, скільки часу вийде виділити на «вікно бекапа» без шкоди для бізнес-процесів.

Топологія резервного копіювання

За своєю топології схеми резервного копіювання також різняться.

  • Децентралізована схема. Її суть в тому, що на кожному сервері і робочої станції може бути власне ПО для резервного копіювання, що працює незалежно від інших вузлів мережі. Всі дані вивантажуються на який-небудь загальний мережевий ресурс, звідки потім потрапляють в архів або відновлюються, при необхідності. Переваги схеми в тому, що вона надзвичайно проста, легко реалізується і зазвичай не вимагає додаткового ПЗ, копіювання виконується штатними засобами операційної системи або СУБД. Є й недоліки — складно встановити загальну політику резервного копіювання та захисту інформації, загальне для всіх програм розклад бекапов, налаштовувати і моніторити діяльність кожної з програм доведеться окремо, що ускладнює адміністрування. Тому децентралізована схема резервного копіювання підійде або для невеликої і нескладної мережі, або для випадків, коли централізовану схему неможливо організувати в силу будь-яких обмежень
  • Централізована схема — для її реалізації необхідно спеціалізоване клієнт-серверне ПЗ. Серверна частина встановлюється на сервер резервного копіювання та централізовано управляє встановленими у користувачів програмними агентами, які збирають, копіюють інформацію про систему або відновлюють її з копії. У такому варіанті легко налаштовувати загальні політики створення резервних копій, розклад бекапов, всі учасники можуть працювати згідно із загальною для компанії інструкцією щодо створення резервної копії інформації
  • Централізована схема резервного копіювання без програм-агентів — спрощений варіант попередньої схеми, коли серверна частина використовує тільки існуючі служби і сервіси (наприклад, збирає дані з спеціально призначених загальних папок Windows). Схема не дуже надійна, в ній є відома проблема, коли відкриті в поточний момент для редагування файли не потрапляють в резервну копію і при збої системи можуть бути втрачені. Тому застосовувати її варто тільки на невеликих мережах і за умови високої користувальницької дисципліни
  • Змішана схема — поєднання централізованої і децентралізованої. Програми-агенти встановлюються тільки на деяких серверах мережі, від інших пристроїв дані на ці сервера відправляють їх локальні програми, кожна своїми засобами. А вже з цих серверів накопичену інформацію програми-агенти централізовано зберуть, оброблять і відправлять в загальне сховище.

Місце зберігання резервних копій

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

Організаційні моменти і людський фактор

Крім суто технічних моментів, в організації резервного копіювання інформації важливий і організаційний аспект. Необхідно розробити положення про резервне копіювання інформації і домогтися його виконання усіма задіяними співробітниками. Зокрема, в такому положенні повинно бути наступне:
  • регулярність копіювання, резервне копіювання за розкладом і перед важливими змінами в системі
  • повторний огляд бекапів — необхідно періодично перевіряти, чи дійсно виходить відновити працездатну базу або систему з резервної копії
  • документування процедур відновлення, на випадок, якщо відновлювати систему доведеться повністю відмінене. Природно, доступ до такої документації повинен бути обмежений
  • визначення умов, при яких система вважається непрацездатною і необхідно почати процедуру відновлення
1161
RSS
Немає коментарів. Ваш буде першим!