Практичні кроки щодо створення системи резервного копіювання, Журнал мережевих рішень

Хтось впроваджує рішення підвищеної надійності та наївно вважає, що таким чином забезпечує безпеку даних. Однак стійкість до відмови не замінює резервування: якщо логічна помилка сталася на одному сервері, вона ж буде відтворена і на дублюючому. Так що відмовостійкий кластер і масив RAID теж потрібно резервувати.

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

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

Звичайно, як часто роблять, можна довіритися думці колег по цеху, які вже мають ту чи іншу СРК. Зробивши приблизну оцінку вартості такої ж системи, ви можете придбати її, передати до ІТ-підрозділу для введення в експлуатацію і раптом виявити, що ліцензій не вистачає, в СГД розміщуються тільки архіви за останній тиждень або передача даних не вкладається у вікно резервного копіювання. Помилка зрозуміла — треба було замовити попереднє обстеження ІТ-системи та провести навчання працівників.

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

Виходить, що вибір вендора СРК, якого порадив знайомий CIO, колега чи інтегратор, який проводив обстеження, не є оптимальним? Варіант замовлення проектування у двох або трьох незалежних інтеграторів для отримання кількох рішень від різних виробників не варто навіть розглядати, оскільки після таких обстежень грошей на впровадження вже не залишиться.

Розкид за сценаріями резервного копіювання

ЯК САМОСТІЙНО ПРОВІСТИ ОБСТЕЖЕННЯ І ВИБРАТИ ВЕНДОРА СРК

Тепер спробуємо дати відповідь на найважливіше для власника компанії питання про вартість рішення. Потреба в резервному копіюванні дозріла, всі це розуміють, але мало хто уявляє, скільки грошей потрібно викласти за СРК. Чому саме стільки? І який буде ефект? Коли повернуться інвестиції? Дати відповіді на всі ці питання і отримати оцінку вартості СРК цілком може директор з інформаційних технологій, якому для цього зовсім не обов'язково мати спеціальні знання системного адміністратора.

Таблиця 1. Класифікація сервісів підприємства

Виконуючикласифікацію, потрібно визначитися, яку мету ви маєте, створюючи СРК, — відновлення сервісів після збою (Disaster Recovery) чи архівне зберігання даних. У першому випадку, як правило, достатньо зберігати резервні копії за тиждень та недільні за місяць, у другому необхідний триваліший період зберігання, який може бути встановлений внутрішніми вимогами компанії або законодавством. Практика показує, що частота звернення до архівів експоненційно зменшується з часом, тобто ймовірність того, що дані будуть потрібні більш ніж через місяць, дуже мала.

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

Таблиця 2. Графік резервного копіювання

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

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

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

А ЧИ ПОТРІБНА СРК? Які ризики вона запобігає?

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

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

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

Таблиця 3. Джерела даних, що захищаються

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

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

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

МЕТОДИКА КОПІЮВАННЯ ДАНИХ

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

Таблиця 4. Технічні вимоги до СРК

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

Якщо ви вважаєте, що зробили вже достатньо, беріть свої вимоги та надсилайте на оцінку до відділів підготовки продажів різних вендорів або інтеграторів. Багато компаній готові боротися за потенційного покупця, забезпечують достатню фінансову підтримку передпродажних офісів і можуть безкоштовно виконати розрахунок. Будь-який замовник, що належить до корпоративного сегменту (Enterprise), може сміливо звертатися до лідерів із квадрантуGartner та запитувати попередню оцінку вартості сценаріїв СРК. Для невеликих компаній, ймовірно, не потрібно додаткового апаратного забезпечення і підійде ПЗ, що вільно розповсюджується, що має досить довгу історію експлуатації і позитивні відгуки.

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

У результаті у вас з'являться пропозиції щодо проектування СРК на базі рішень кількох вендорів та відповідно до кількох сценаріїв. Вам залишиться врахувати наявні обмеження та ухвалити рішення про вибір цільової моделі в рамках відведеного бюджету. Згрупуйте сервіси за класифікацією та підсумуйте рядки реєстру, а потім продемонструйте CEO варіанти реалізації СРК. Покажіть наочно, за які гроші він отримає відновлення сервісів компанії та з якою швидкістю. Вкажіть, які ризики запобігають та яка передбачувана ціна цих ризиків (див. табл. 5).

Таблиця 5. Вибір сценарію та рішення СРК

ПІСЛЯМОВА

Під час обстеження потрібно приділити увагу питанням зв'язку СРК з іншими системами, наприклад, системами моніторингу, а також спрогнозувати зростання обсягів резервного копіювання, потребу в масштабованості системи та передбачити заходи безпеки при організації зберігання даних. Не забудьте разна рік виконувати аудит даних, що копіюються, на відповідність вимогам бізнесу.

Сергій Чекмасов - начальник служби експлуатації програмно-апаратного комплексу Карельського РДУ, філії ВАТ «СВ ЄЕС». З ним можна зв'язатися через: http://www.linkedin.com/in/chekmasoff.

Поділіться матеріалом з колегами та друзями

---