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

Вступ

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

Для захисту від втрати інформації використовуються системи резервного копіювання та відновлення даних (Backup & Recovery). Система резервного копіювання та відновлення даних - це програмний або програмно-апаратний комплекс для створення копій даних з певною періодичністю для їх подальшого відновлення. Крім захисту від втрати даних системи резервного копіювання також дозволяють забезпечити організувати безперервність роботи співробітників за рахунок швидкого відновлення операційної системи (при наявності її образу) або відновлення даних на іншому комп'ютері.

Як працюють системи резервного копіювання та відновлення даних

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

Головні розділові лінії між різними системами резервного копіювання та відновлення даних проходять по сферам їх використання - для персональних потреб, в невеликих компаніях і «домашніх офісах» (SMB / SOHO / ROBO) або в середніх (Enterprise) і великих компаніях (Large Enterprise). Залежно від цього розрізняється ціна систем резервного копіювання і відновлення даних, що використовуються типи сховищ, типи платформ, що надаються функції і т.д. Розглянемо деякі з цих критеріїв.

Одне з основних відмінностей для систем резервного копіювання і відновлення даних - це тип носіїв для зберігання даних. Для зберігання резервних копій може використовуватися стрічка, оптичні диски (CD, DVD, Blu-Ray і т.д.), «жорсткі» диски (HDD), твердотільні диски (SSD), мережеві сховища. Кожен з них має свої переваги і недоліки. Наприклад, зберігання даних на стрічках тільки на перший погляд здається анахронізмом. Сучасні стрічкові пристрої досить дешеві і гарантують тривале зберігання даних. Але ось відновлення даних з таких носіїв може бути дуже довгим. Тому вони більше підходять для архівації даних. «Жорсткі» диски дозволяють виконувати резервне копіювання і відновлення досить швидко, однак у них висока ціна і не найдовше час життя.

Альтернативою «жорстким» дискам є використання «хмарних» сховищ, в яких тип систем зберігання прихований від користувачів. Звичайно, в якості «заліза» в них використовуються будь-які диски, але проблема збереження дисків лягає на постачальника послуг. А що ж ціна? Забезпечення додаткових гарантій збереження вимагає великих грошей на утримання «хмарної» інфраструктури (може підтримуватися дублювання даних, «гаряча» заміна дисків, RAID-масиви). Однак при цьому ефективність використання дискового простору може бути вище, тому що «Хмарою» може користуватися кілька клієнтів і ефективність його використання буде вище, ніж у системи резервного копіювання та відновлення даних, встановленої безпосередньо в компанії. В результаті цього ефективність тієї чи іншої системи складно порахувати апріорно, тому в кожній конкретній ситуації вибору системи зберігання повинен передувати економічний розрахунок.

Ще одна відмінність - це тип використовуваних платформ. Система резервного копіювання та відновлення даних може бути реалізована у вигляді програмного забезпечення, програмно-апаратного комплексу або у вигляді послуги (software-as-a-service). Програмне забезпечення коштує дешевше і вимагає окремих систем зберігання. Тому такі системи підходять для персонального використання і невеликих компаній. Для великих компаній такі системи можуть використовуватися в зв'язці зі спеціальними сховищами даних. Для середніх і великих підприємств більше підходять системи резервного копіювання та відновлення даних, виконані у вигляді програмно-апаратних комплексів (PBBA, Purpose-Built Backup Appliance). Дані пристрої підрозділяються на дві категорії:

1. PBBA target systems (цільовісистеми). Дані комплексивиступает тільки в якості цільового пристрою для резервного копіювання. Таке рішення вимагає використання додаткового програмного забезпечення для автоматизації, управління і консолідації резервного копіювання, яке, в свою чергу, повинно бути розміщено на додатковому серверному обладнанні з розгорнутою операційною системою для інтеграції всіх перерахованих компонент. До таких пристроїв відносяться EMC Data Domain, HP StoreOnce і т.д.
2. PBBA integrated systems (інтегровані системи). цеповністю закінчені рішення, яке не потребує додаткових складових для повноцінної роботи. Вони включають в себе сервера, дискові масиви і програмне забезпечення для здійснення резервного копіювання. Такі системи мають більшу інтеграцію між апаратурою і програмним забезпеченням і можуть включати додаткові інструменти для роботи з мережею (наприклад, балансування навантаження). Такі рішення не вимагають додаткових інвестицій в інфраструктуру, мають менші витрати на розгортання і інтеграцію, а також простіше супроводжувати і адмініструвати. До таких пристроїв відносяться EMC Avamar, Symantec Appliance BE + NBU і т.д.

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

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

1. Дублювання дозволяє здійснювати одночасне копіювання на кілька джерел, що збільшує надійність зберігання даних.
2. Дедуплікація дозволяє проводити аналіз і стиснення дубльованих даних. В результаті зменшується навантаження на канали передачі даних і місце для зберігання даних.
3. Створення образів системи. Періодичне копіювання не тільки даних, але і образів системи дозволяє швидко відновити робоче місце співробітника навіть в разі пошкодження операційної системи або персонального комп'ютера, що забезпечує безперервність його роботи.
4. Балансування навантаження. Дозволяє оптимізувати навантаження на кілька сховищ для найбільш швидкого виконання операцій з резервними копіями.
5. Сумісність з програмним забезпеченням (операційними системами і СУБД). Дозволяє створювати «зліпки» файлів і баз даних, які можуть змінюватися в процесі створення резервної копії, для їх коректної цілісної передачі і відновлення.
6. Різні інструменти для віддаленого адміністрування. Це досить різноманітний набір функцій, що дозволяють автоматизувати роботу адміністратора. До них може ставитися віддалена установка агентів на комп'ютери користувачів, перевірка створених архівів, ручне або автоматичне злиття резервних копій і т.д.
7. Робота з віртуальними пристроями.
8. Робота з «хмарними» сховищами.
9. Алгоритми відновлення даних. При втраті даних для збільшення швидкості відновлення даних використовуються різні алгоритми, що дозволяють відновлювати тільки потрібні дані, виключати дублювання при відновленні і т.д.

Світовий ринок систем резервного копіювання і відновлення даних

Кількість систем резервного копіювання і відновлення даних в світі досить обмежена. Магічний квадрат від компанії Gartner вказує, що перші місця на ринку займають такі компанії, як CommVault, EMC, IBM і Symantec.

Малюнок 1.«Магічний квадрат»Gartner для систем резервного копіювання і відновлення даних

У 2013 році аналітична компанія IDC випустила детальний звіт (Worldwide Quarterly Purpose Built Backup Appliance Tracker) про ринок спеціалізованих пристроїв для резервного копіювання (PBBA, Purpose Built Backup Appliance). Згідно з його даними, виручка компаній в даному сегменті за другий квартал 2013 року склала 720,2 млн. $, Що на 7,3% більше, ніж рік тому.

Таблиця 1. Доходи виробників в сфері спеціалізованих пристроїв резервного копіювання (в мільйонах доларів)

Виробник	2 квартал 2012		2 квартал 2013
	Об'єм продажу	Частка ринку	Об'єм продажу	Частка ринку

З наведеної таблиці видно, що більше половини ринку займає компанія EMC (62.6%). На другій позиції знаходиться компанія Symantec (12.4%), третє місце займає IBM з часткою ринку 7,3%. Четверте і п'яте місце займають компанії HP (5.3%) і Quantum (2.5%), всі інші компанії займають на ринку менше 2% і в сумі складають 10% ринку. З помітних тенденцій можна вказати на зменшення частки ринку компанії IBM на 40,4% і збільшення частки компанії Symantec на 71.3%.

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

Російський ринок систем резервного копіювання і відновлення даних

На російському ринку представлені основні світові гравці ринку систем резервного копіювання і відновлення даних, які просувають свої рішення через регіональних партнерів. На ринку представлені продукти компаній EMC, IBM, HP, Symantec, Dell, NetApp, CA Technologies , які в більшості орієнтовані на великі компанії. Компанія CommVault представлена \u200b\u200bна російському ринку в меншому обсязі, в основному її рішення пропонує компанія КРОК. Також популярністю користуються рішення російських виробників Acronis і Paragon Software Group. Їх рішення особливо актуальні у зв'язку з політикою економії багатьох компаній, які починають приділяти особливу увагу показниками «ціна / якість». Для захисту тільки віртуальних систем використовуються рішення російської фірми Veeam Software, проте їх ми розглянемо в рамках наступної спеціалізованої статті.

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

EMC

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

Для оптимізації управління даними використовується додаткове програмне забезпечення EMC Data Protection Adviso. Воно автоматизує моніторинг і аналіз резервних копій, забезпечує відправку повідомлень адміністраторам при виникненні різних подій і дозволяє створювати звіти про роботу резервного копіювання.

Системи резервного копіювання і відновлення даних є досить «гнучкими» і при необхідності можуть масштабироваться за рахунок збільшення дискового простору. EMC Avamar також можуть інтегруватися з системами зберігання даних EMC Data Domain. Дані системи представлені великою лінійкою продуктів від невеликих пристроїв (DD160, DD620), здатних зберігати кілька терабайт, до дуже великих сховищ (DD990) на кілька петабайт.

IBM

У сфері резервного копіювання компанія IBM представлена \u200b\u200bпродуктом IBM Tivoli Storage Manager. Це програмний продукт, який займається створенням резервних копій і управлінням пристроями зберігання. IBM Tivoli Storage Manager сумісний з великою кількістю різних систем зберігання даних. Він забезпечує роботу в локальних (LAN), глобальних (WAN) мережах і розвиваються зараз мережах зберігання даних (SAN).

Tivoli Storage Manager включає в себе кошти для віддаленого адміністрування з будь-якої точки мережі або через Інтернет. Адміністратор може автоматизувати різні етапи роботи системи резервного копіювання та відновлення даних за рахунок створення політик зберігання. Набір політик, налаштований адміністратором, дозволяє не тільки проводити штатні операції, але і оперативно реагувати на виникнення різних незапланованих ситуацій. За рахунок використання ієрархічної системи зберігання в системі під керуванням Tivoli Storage Manager можуть використовуватися різні типи пристроїв зберігання (наприклад, стрічки і «жорсткі» диски).

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

Symantec

Компанія Symantec надає два продукти для резервного копіювання та відновлення даних - це Symantec Backup Exe і Symantec NetBackup, які призначені для роботи в середніх і великих мережах. Дані програми включають в себе весь набір необхідних для резервного копіювання функцій (дедуплікація, автоматична цільова реплікація, міграція між комп'ютерами, робота з фізичними та віртуальними пристроями, робота в гетерогенному середовищі і т.д.). Дані продукти можуть працювати з різними системами зберігання даних.

Окремо варто згадати додаткові технології по роботі з віртуальними машинами. Технологія віртуалізації Symantec V-Ray об'єднує в собі віртуальні та фізичні резервні копії і дає користувачам єдиний доступ до всіх резервних копій, включаючи VMware, Hyper-V і фізичні пристрої, дозволяючи швидко відновлювати віртуальні машини, додатки, бази даних, файли, папки і навіть окремі елементи додатків. Вбудована технологія bare metal recovery дозволяє відновлювати дані на обладнанні, відмінному від вихідного, і включає в себе функцію резервного копіювання в віртуальну машину (B2V) і перетворення в віртуальну машину (P2V), даючи користувачам можливість відновити відмовили системи в VMware або Hyper-V оточенні .

Для зручності роботи з системами резервного копіювання та відновлення даних Symantec також випустила на ринок програмно-апаратні пристрої Symantec Backup Exec 3600 Symantec NetBackup 5230. Одним з переваг їх використання є мінімальний час для їх розгортання на підприємстві. Стверджується, що адміністратору знадобиться 20-30 хвилин, щоб пристрої почали працювати і повноцінно виконувати свої функції.

CommVault

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

Функції резервного копіювання в CommVault Simpana включають в себе Дедуплікація, створення образів системи, автоматизацію резервного копіювання, централізоване управління резервними копіями, створення звітів, надання користувачам самостійного доступу до резервних копій, використання політик для ієрархічного зберігання даних, балансування навантаження і т.д. CommVault Simpana забезпечує глибоку інтеграцію в віртуальну інфраструктуру для розширених засобів управління даними для платформ Microsoft Hyper-V, VMware vCenter і VMware vCloud Director.

CommVault підтримують більшість наявні операційних систем і додатків (зокрема, бази даних Oracle, Microsoft, PostgreSQL та MySQL, Documentum, SAP) для того, щоб створювати резервні копії в процесі роботи додатків з мінімальним навантаженням на них.

HP

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

• дедуплікація даних відповідно до технології HP StoreOnce Federated Deduplication як на клієнтів (source based), так і на окремо виділеному сервері (backup server) або ж на системах зберігання даних (target based);
• резервне копіювання і відновлення віртуальних середовищ, включаючи захист як цілком віртуальних машин, так і окремих даних всередині них;
• інтеграцію з функціональністю дискових масивів по створенню апаратних знімків (snapshots) для здійснення резервного копіювання з нульовим простоєм Zero Downtime Backup і миттєвого відновлення інформації Instant Recovery (IR);
• можливість відновлення окремих елементів резервної копії (наприклад, окремого файлу з резервної копії віртуальної машини).

Для зберігання резервних копій використовується лінійка дискових бібліотек з Дедуплікація HPStoreOnce. Рішення базується на серверній платформі HP Proliant Gen8, моделі мають ємність від 8ТБ до 2.2ПБ (до 35ПБ з урахуванням дедуплікаціі) і підтримують швидкість резервного копіювання до 139ТБ / год. Воно може одночасно працювати в режимі VTL (Virtual Tape Library), емулюючи стрічкові приводи, і виступати в якості файлового сховища з доступом по CIFS / NFS.

Dell

Останнім часом компанія Dell наростила портфель рішень для резервного копіювання та відновлення за рахунок придбання компаній Quest Software і AppAssure. Для великих підприємств і компаній Dell пропонує рішення NetVault для організації резервного копіювання всієї інфраструктури, а для компаній малого і середнього бізнесу більш просте рішення Appasure. Для резервного копіювання віртуальних машин використовується додаток vRanger. Російські розробники підрозділу Dell представляють також спеціалізовані рішення Dell Software для гранулярного відновлення AD і Exchаnge, а також унікальну технологію автоматизованого відновлення Active Directory при втраті даних.

Для прикладу розглянемо пристрої Dell PowerVault серії DL і DR (актуальні моделі - DL4000 і Dell DR4100). Пристрої дозволяють виконувати наступні функції:

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

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

Quantum

Компанія Quantum поставляє системи резервного копіювання та зберігання даних. Поставляються стрічкові (SuperLoader; Scalar i40, i80, i500, i6000) і дискові (DXi V1000, 4000, 6500, 6700, 8500) пристрої і пристрої резервного копіювання для віртуальних машин Quantum vmPRO 4000.

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

NetApp

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

NetApp SnapVault - це програмне рішення для швидкого виконання резервного копіювання з диска на диск і захисту даних на рівні блоків. Дозволяє скоротити час створення резервних копій за рахунок інкрементного копіювання на рівні блоків даних. Забезпечує швидке відновлення даних за рахунок великого числа параметрів і точок відновлення.

CA Technologies

Для резервного копіювання та відновлення даних CA Tehnologies пропонує програмне забезпечення CA ARCserve Backup . Воно дозволяє виконувати досить великий обсяг функцій:

• дуплікацію даних для скорочення обсягів використовуваних сховищ;
• підтримку резервного копіювання при роботі з віртуальними машинами під керуванням VMware, Microsoft Hyper-V ™ і Citrix® XenServer;
• підтримка резервного копіювання в «хмарі» для швидкого перенесення даних між фізично віддаленими об'єктами;
• використання резервного копіювання на основі миттєвих знімків (ARCserve D2D) спільно з рішенням традиційного резервного копіювання файлів (CA ARCserve Backup). При цьому використовується загальний каталог резервних копій, щоб прискорити і спростити процес відновлення;
• можливість централізованого управління процесами копіювання і відновлення даних з єдиної консолі.

Для реалізації спеціалізованих завдань використовуються додаткові модулі (CA ARCserve Central Reporting, CA ARCserve Replication, CA ARCserve High Availability), що розширюють функціональність CA ARCserve Backup.

Acronis

Компанія Acronis надає цілу лінійку програмного забезпечення для організації резервного копіювання і відновлення даних. Для домашнього використання призначене додаток Acronis True Image, для малих підприємств використовується Acronis Backup & Recovery Server for Windows, а для великих підприємств - for Windows.

Найбільш функціональним є корпоративний продукт Acronis Backup & Recovery Advanced Server, що дозволяє виконувати велику кількість функцій:

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

Наявність такого набору функцій дає можливість продуктам компанії Acronis бути реальним конкурентом продуктам світових лідерів у цій галузі. Наданий функціонал дозволяє продуктам Acronis претендувати на всі сегменти ринку.

Paragon

Ще одна російська компанія, що випускає системи резервного копіювання та відновлення даних. В її портфелі цілий ряд продуктів для резервного копіювання та обслуговування жорстких дисків - Paragon Hard Disk Manager 12 Suite, Professional, Business, Premium editions (для персональних користувачів і SMB); Paragon Protect and Restore 3 (для великих компаній); Drive Backup 11 Workstation; Drive Backup 11 Server і т.д. На весну 2014 року на російському ринку анонсується випуск Paragon Hard Disk Manager 14, який вже продається на заході.

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

Більшість продуктів компанії Paragon розраховані на персональних користувачів і маленькі і середні компанії. Однак останні продукти компанії, такі як Hard Disk Manager 12 Premium, виходять за рамки SMB і надає додаткові інструменти для роботи в крупних компаніях.

Перерахованими рішеннями повністю не обмежується ринок систем резервного копіювання і відновлення даних в Росії. Є менш поширені продукти, наприклад, Handy Backup Server Network (компанія «Новософт») або BakBone NetVault. Однак їх представленість на російському ринку мала або не піддається точній оцінці, тому вони і не потрапили в список розглянутих нами рішень.

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

висновки

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

Ринок систем резервного копіювання і відновлення даних досить зрілий. На світовому рівні вже досить давно склався набір лідерів в даній області, які з року в рік прагнуть підтримувати високий рівень своїх рішень. Це компанії EMC, CommVault, Symantec, IBM, HP, Quantum, NetApp, CA Technologies. На російському ринку представлені продукти всіх зазначених лідерів. Специфікою ринку є присутність російських гравців - Acronis і Paragon, продукти яких займають свої ніші і затребувані на ринку.

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

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

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

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

• Інформація з комп'ютера
• Інформація з планшетів і смартфонів
• рекомендації користувачеві

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

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

Інформація з комп'ютера

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

Windows 7

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

Натискаємо на «Налаштувати резервне копіювання»

• Потім перед вами з'явиться діалогове вікно з настройками архівації. Виберіть свій жорсткий диск і тисніть на кнопку «Далі».

Вибираємо розташування архіву

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

Вибір об'єктів для архівації самостійно

• Далі, ми перевіряємо встановлені параметри. Тут ви можете встановити розклад для автоматичного створення копії за допомогою кнопки "Змінити розклад».

• Коли все буде встановлено і перевірено, натисніть «Зберегти параметри і запустити архівацію».

процес виконується

• Дочекайтеся закінчення процесу, потім перевірте ваш зовнішній жорсткий диск: записалися на нього ваші дані.

Windows 8.1

• Запустіть панель інструментів в правій частині екрана. Для цього відведіть миша в правий верхній кут потім натисніть на «Пошук».
• Наберіть з клавіатури словосполучення «Історія файлів» без лапок і натисніть Enter. В отриманих результатах натисніть на однойменну папку.
• Ви потрапите у вікно, де потрібно буде натиснути на посилання «Резервна копія образу системи», яка розташована в лівому нижньому кутку вікна.

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

Windows 10

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

Для відновлення даних повторіть пункти до знаходження налаштувань архівації. АЛЕ тепер просто виберіть вкладку або пункт «Відновлення» і просто дотримуйтесь інструкцій в діалоговому вікні на екрані вашого монітора. Нічого складного в цьому немає. Природно, ми з вами розглянули штатні засоби ОС Windows від Майкрософта. Існують і спеціальні програми для проведення аналогічних операцій. Вони можуть бути зручніше, але в плані безпеки і надійності можуть поступатися цим. Тому рекомендується все ж користуватися стандартними утилітами ОС.

Інформація з планшетів і смартфонів

Тут все трохи простіше, так як теж використовуються стандартні програми (наприклад, для iPhone і iPad ми будемо працювати з iTunes). Для всіх гаджетів будь-якій операційній системи процедура виконання резервної копії буде одна і та ж:

• Підключіть свій пристрій до комп'ютера або ноутбука. Дочекайтеся установки відповідних драйверів.
• Запустіть програму, яка призначена для синхронізації з вашим девайсом. Тобто, якщо у вас Айфон, то відкрийте програму iTunes на своєму ПК.
• Знайдіть вкладку або пункт «Синхронізація», або «Резервне копіювання». Клацніть по ній і, слідуючи підказкам на екрані, створіть копію.

• Для відновлення даних в цьому ж вікні знайдіть однойменну кнопку і натисніть на неї.
• Під час виконання комп'ютером цих дій ні в якому разі не відключайте пристрій від USB. Це може скінчитися програмної поломкою девайса.
• Зверніть увагу, що ви можете просто перенести деякі файли зі смартфона або планшета на ПК. Особливо це актуально для власників гаджетів під управлінням операційної системи Android: тут є повний доступ до всіх файлів і папок.
• Власники iOS-девайсів можуть зберігати лише фотографії і відео аналогічним чином: зайдіть в «Комп'ютер» і клацніть правою кнопкою миші по вашому пристрою. Натисніть на «Імпорт фотографій і відео». Слідуючи підказкам на екрані, ви можете не тільки зробити імпорт, але і налаштувати його.

хмарні сховища

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

• OneDrive для Windows
• iCloud і iCloud Drive для iOS і MacOS
• Google диск для Android

Варто відзначити, що є ще універсальні, які ставляться на будь-який пристрій, незалежно від встановленої ОС:

• хмара Mail
• OneDrive
• Google диск

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

• При використанні зовнішнього жорсткого диска або флешки, подбайте про те, щоб вона володіла достатнім об'ємом вільного простору.
• Зверніть увагу, що більшість хмарних сховищ мають обмежену пам'ять для безкоштовного доступу. Наприклад, в iCloud Drive вам доступно буде п'ять гігабайт. Щоб розширити її вам потрібно буде купувати підписку. Якщо у вас не так багато файлів, то купувати нічого не потрібно. Можете також користуватися декількома хмарними сховищами.
• Перевіряйте створення копій: якщо пам'ять на диску або в хмарі закінчилася, то копія не створить. Ви ризикуєте втратити деякі дані, що буде дуже сумним наслідком.
• Якщо ви просто копіюєте деякі файли, то бажано видалити їх з копійованого девайса для звільнення пам'яті на ньому.
• Якщо ви хочете зберегти дуже важливі документи, то краще зробити дві копії. Наприклад, можете одну зробити на зовнішньому жорсткому диску, а іншу за допомогою програми хмарного сховища.

Підведемо підсумки

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

текст лекції

Ключові питання

Лекція № 15. Створення резервної копії

Тривалість: 2 години (90 хв.)

· Виконання резервного копіювання.

· Спостереження за резервним копіюванням.

· Планування резервного копіювання.

Ви можете створити резервну копію за допомогою Enterprise Manager, команд T-SQL або майстра створення резервної копії бази даних Create Database Backup Wizard. У багатьох випадках найпростіше використовувати Create Database Backup Wizard, але Enterprise Manager також нескладно використовувати. З іншого боку, команди T-SQL можна поміщати в сценарії SQL, які можна багаторазово повторювати. Вам слід використовувати метод, найбільш відповідає вашим вимогам.

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

Для створення пристрою резервного копіювання за допомогою T-SQL використовуйте збережену процедуру sp_addumpdevice. Вона має наступний синтаксис:

sp_addumpdevice тіп_устройства, логіческое_імя, фізіческое_імя

Значенням параметра тіп_устройства може бути disk для дискового пристрою, tape для стрічкового пристрою або pipe для під'єднання програмного забезпечення сторонніх форм до системи резервного копіювання. Параметр логіческое_імя - це ім'я, яке ви привласнюєте Цей пристрій; це ім'я використовується для посилання на пристрій в операторах BACKUP і RESTORE. Параметр фізіческое_імя - це ім'я, присвоєне системою пристрою або файлу.

Створивши одне або кілька пристроїв резервного копіювання, ви можете створювати резервні копії.

Щоб створити резервну копію за допомогою Enterprise Manager виконайте наступні кроки.

1. Викличте утиліту SQL Server Backup за допомогою одного з наступних методів.

· Розкрийте папку сервера в лівій панелі Enterprise Manager і потім розкрийте папку Management. Клацніть правою кнопкою миші на Backup і виберіть з контекстного меню пункт Backup A Database (Резервне копіювання бази даних).

· Розкрийте папку сервера в лівій панелі Enterprise Manager, клацніть правою кнопкою миші на Database, вкажіть в контекстному меню пункт All Tasks (Усі завдання) і потім виберіть команду Backup Database.

· Розкрийте папку сервера в лівій панелі Enterprise Manager і потім клацніть на папці Databases. У правій панелі клацніть правою кнопкою миші на базі даних, вкажіть в контекстному меню пункт All Tasks (Усі завдання) і потім виберіть команду Backup Database.

З'явиться діалогове вікно SQL Server Backup (див. Рисунок 16.1).

Малюнок 16.1 - Вкладка General діалогового вікна SQL Server Backup

2. У списку Database верхньої секції у цьому діалоговому вікні виберіть базу даних, для якої хочете створити резервні копії. (Якщо ви використовували третій метод на кроці 1, то ім'я відповідної бази даних вже буде вибрано.) Ім'я резервної копії автоматично формується на основі імені бази даних, хоча ви можете перевизначити це автоматичне ім'я шляхом введення імені резервної копії в текстовому полі Name. Ви можете також ввести опис резервної копії в текстовому полі Description. Це опис може виявитися важливим для вас при відновленні бази даних. Наприклад, якщо ви створюєте цю резервну копію безпосередньо перед видаленням будь-якої таблиці, має сенс включити цей факт в опис. Якщо копіювання здійснюється перед завантаженням нових даних, включіть цю інформацію в ваш опис.

3. У секції Backup (Резервне копіювання) у цьому діалоговому вікні ви повинні вказати тип резервного копіювання. Доступні кнопки вибору будуть варіюватися в залежності від обраної вами бази даних. Наприклад, за замовчуванням для бази даних Northwind встановлений параметр Truncate log on checkpoint. (Усічення журналу транзакцій при створенні контрольної точки). В цьому випадку кнопки вибору Transaction Log і File and Filegroup недоступні для програми резервного копіювання. Секція Backup містить наступні кнопки вибору.

· Database - Complete (База даних - Повне). Повне резервне копіювання бази даних, тобто всіх даних відповідної бази даних.

· Database - Differential (База даних - Різницеве). Різницеве \u200b\u200bрезервне копіювання бази даних, тобто всіх даних, які змінилися з моменту попереднього резервного копіювання.

· Transaction Log (Журнал транзакцій). Створення резервних копій журналу транзакцій; при цьому також відбувається усічення журналу транзакцій.

· File And Filegroup (Файл і група файлів). Створення резервних копій одного файлу або групи файлів; ви повинні вказати цей файл або групу файлів.

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

4. У секції Destination (Місцезнаходження резервної копії) ви повинні вибрати тип пристрою для резервної копії - Tape (Лента) або Disk (Диск). Клацнувши на кнопці Add, ви можете додавати логічні або фізичні пристрої резервного копіювання. З'явиться діалогове вікно Select Backup Destination (Вибір місця розташування резервної копії) (див. Рисунок 16.2).

Малюнок 16.2 - Діалогове вікно Select Backup Destination

У цьому діалоговому вікні ви можете вказати ім'я файлу або вибрати пристрій резервного копіювання зі списку Backup device. Клацніть на кнопці OK, щоб повернутися у вкладку General діалогового вікна SQL Server Backup. У прикладі на малюнку 16.1 в списку Backup to представлені два пристрої. Щоб видалити будь-який пристрій, виділіть цей пристрій і клацніть на кнопці Remove (Видалити). Для перегляду вмісту пристрою клацніть на кнопці Contents (Вміст). Якщо певний пристрій резервного копіювання вже використовувалося раніше, з'явиться наступна інформація про резервної копії.

· Name (Ім'я). Ім'я, вибране тим, хто запускав резервне копіювання.

· Server (Сервер). Ім'я сервера, на якому виконувалося резервне копіювання.

· Database (База даних). Ім'я бази даних, для якої було виконано резервне копіювання.

· Type (Тип). Тип резервного копіювання (Complete, Differential, Transaction Log, Filegroup, File)

· Date (Дата). Дата і час резервного копіювання.

· Expiration (Термін закінчення дії). Термін закінчення дії, зазначений для резервної копії.

· Size (Розмір). Загальний розмір набору резервного копіювання.

· Description (Опис). Опис, заданий для резервної копії.

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

5. У секції Overwrite (Перезапис) діалогового вікна SQL Server Backup ви можете вибирати між перезаписом носія (кнопка вибору Overwrite ...), такого як стрічка або диск, і додаванням до попередніх даних (кнопка вибору Append ...). Але якщо ви використовуєте стрічки і чергуєте їх, то вам потрібно видаляти попередню інформацію. Хоча ви можете перезаписувати цю інформацію, клацнувши на кнопці вибору Overwrite existing media в цьому діалоговому вікні, вам слід замість цього прийняти за правило прати інформацію перед резервним копіюванням. Тим самим ви гарантуєте себе від випадкового перезапису стрічкового або дискового пристрою.

6. У секції Schedule (Розклад) ви можете задати розклад для запуску резервного копіювання в певний час. Створення резервних копій за розкладом особливо корисно для резервного копіювання журналу транзакцій, яке може виконуватися регулярним чином, щоб уникнути переповнення журналу транзакцій. Щоб задати розклад резервного копіювання, встановіть прапорець Schedule і потім клацніть на кнопці огляду (...), щоб з'явилося діалогове вікно Edit Schedule (Редагувати розклад) (див. Рисунок 16.3).

7. Введіть ім'я розкладу в текстовому полі Name. Імена розкладів дозволяють вам створювати кілька розкладів, наприклад, окремий розклад для кожного резервного копіювання.

Малюнок 16.3 - Діалогове вікно Edit Schedule (Редагувати розклад)

У секції Schedule type (Тип розкладу) ви можете вибрати один з наступних типів розкладу (в порядку кнопок вибору): автоматично при запуску SQL Server Agent, коли не буде зайнятий ЦП, запускати резервне копіювання один раз або повторювати його. Якщо у вас вибраний одноразовий запуск резервного копіювання, то ви використовуєте спливає календар On date (Дата) для вибору дати резервного копіювання та поле-лічильник At time (Час) для вибору часу.

Щоб задати розклад для періодично повторюваного резервного копіювання, клацніть на кнопці вибору Recurring (Періодично) і клацніть на кнопці Change (Змінити).

З'явиться діалогове вікно Edit Recurring Job Schedule (Редагувати розклад повторюваних завдань) (див. Рисунок 16.4). Це діалогове вікно надає вам різноманітні гнучкі можливості по створенню розкладу. Використовуючи варіант Daily (Щодня), Weekly (Щотижня) або Monthly (Щомісяця), ви можете вказувати частоту і термін дії відповідного завдання.

8. Клацніть на кнопці OK, щоб повернутися в діалогове вікно Edit Schedule, клацніть ще раз на кнопці OK, щоб повернутися в діалогове вікно SQL Server Backup, і потім клацніть на вкладці Options (див. Рисунок 16.5). У цій вкладці ви можете вказувати, чи потрібно перевіряти носій резервної копії по завершенні резервного копіювання, а також вказувати необхідність і спосіб завдання мітки (заголовка) носія резервної копії. Нижче описуються параметри цієї вкладки.

Малюнок 16.4 - Діалогове вікно Edit Recurring Job Schedule (Редагувати розклад повторюваних завдань)

Малюнок 16.5 - Вкладка Options діалогового вікна SQL Server Backup

· Verify backup upon completion (Перевіряти резервну копію по завершенні). Викликає перевірку носія резервної копії на читаність. Перевіряється тільки цілісність копії; цей процес не перевіряє, що резервна копія містить відповідні дані.

· Eject tape after backup (Витягти стрічку з пристрою після резервного копіювання - тільки для стрічкових пристроїв). Витяг стрічки з пристрою по завершенні резервного копіювання. Цей прапорець корисно використовувати, якщо кілька додатків або користувачів здійснюють доступ до стрічкових пристроїв. Це дозволяє зберегти вашу стрічку від перезапису іншим користувачем.

· Remove inactive entries from transaction log (Видалити неактивні записи з журналу транзакцій - тільки для резервного копіювання журналу транзакцій). Усічення журналу транзакцій після резервного копіювання.

· Check media set name and backup set expiration (Перевіряти ім'я набору носіїв і дату закінчення терміну зберігання набору резервного копіювання) .Указивает, що даний носій потрібно перевіряти і не перезаписувати, якщо не наступила дата закінчення терміну зберігання.

· Backup set will expire (Термін зберігання набору резервного копіювання закінчується - тільки для стрічкових пристроїв). Дозволяє вам задавати дату закінчення терміну зберігання даного носія.

· Initialize and label media (Ініціалізувати і позначити носій - тільки для стрічкових пристроїв). Дозволяє вам задавати мітку для даного носія.

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

Використання операторів T-SQL для резервного копіювання бази даних може виявитися спочатку трохи складніше, ніж використання Enterprise Manager. Але якщо ви належите до тих адміністраторам, які вважають за краще автоматизувати операції за допомогою сценаріїв, цей метод буде для вас зручніше. Крім того, оператор T-SQL BACKUP дає трохи більше можливостей, ніж програма резервного копіювання в Enterprise Manager. У цьому розділі ми розглянемо синтаксис і параметри оператора BACKUP. Насправді існують два оператора резервного копіювання; Вибір з'єднання оператора залежить від типу резервного копіювання, яке вам потрібно виконати. Це такі оператори:

· BACKUP DATABASE. Використовується для резервного копіювання всієї бази даних або файлу або групи файлів.

· BACKUP LOG. Використовується для резервного копіювання журналу транзакцій.

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

Оператор BACKUP для повного резервного копіювання бази даних має наступний синтаксис:

Для цього оператора обов'язковими параметрами є тільки ім'я бази даних і ім'я пристрою резервного копіювання.

Оператор для резервного копіювання файлу або групи файлів має наступний синтаксис:

BACKUP DATABASE імя_бази_данних

имя_файла або імя_группи_файлов [... n]

TO устройство_резервного_копірованія

[WITH необов'язкові параметри]

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

Оператор для резервного копіювання журналу транзакцій має наступний синтаксис:

BACKUP LOG імя_бази_данних

([WITH \\ NO_LOG | TRUNCATE_ONLY)])

| (TO устройство_резервного_копірованія)

[WITH необов'язкові параметри]

Для цього оператора обов'язковими параметрами є тільки ім'я бази даних і параметр WITH NO_LOG або WITH TRUNCATE_ONLY або ім'я пристрою резервного копіювання. Ви можете потім додавати будь-які потрібні вам параметри. Параметри NO_LOG і TRUNCATE ONLY є синонімами; обидва вказують усічення журналу без створення його резервної копії. Якщо ви використовуєте будь-який з цих параметрів в вашому операторі BACKUP LOG, то в разі відмови системи ви не зможете відтворити базу даних до стану, в якому вона перебувала в момент відмови, оскільки не будуть збережені записи журналу. Застосування цих параметрів не рекомендується; використовуйте їх на свій власний розсуд.

У всіх трьох зазначених командах резервного копіювання імя_бази_данних представляє базу даних, для якої буде створена резервна копія. Устройство_резервного_копірованія - це ім'я логічного пристрою резервного копіювання або ім'я фізичної пристрою. Якщо вказана фізична пристрій, то імені пристрою повинен передувати текст DISK \u003d, TAPE \u003d або PIPE \u003d (в залежності від типу пристрою). Ви можете задати один пристрій або набір розділених комами пристроїв.

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

Таблиця 16.1 - Необов'язкові параметри оператора BACKUP

параметр	опис
BLOCKSIZE	Цей параметр вказує розмір фізичного блоку в байтах
DESCRIPTION	Цей параметр вказує текстовий опис набору резервного копіювання. Його корисно використовувати для пошуку потрібної резервної копії, з якої буде виконуватися відновлення
DIFFERENTIAL	Цей параметр вказує разностное резервне копіювання. Його можна використовувати тільки при наявності повної резервної копії бази даних
EXPIREDATE \u003d дата RETAINDAYS \u003d дні	Параметр EXPIREDATE вказує дату, коли закінчується термін дії даного набору резервного копіювання (і коли його можна перезаписувати).
RETAINDAYS	вказує кількість днів, відповідних терміну дії даного набору резервного копіювання
PASSWORD \u003d пароль	Параметр PASSWORD дозволяє вам задавати пароль для резервної копії, що підвищує безпеку самої резервної копії
FORMAT | NOFORMAT	Параметр FORMAT вказує, що заголовок носія повинен бути перезаписан, роблячи тим самим недійсними початкові дані на цьому носії. Параметр NOFORMAT вказує, що заголовок носія не повинен записуватись
INIT | NOINIT	Параметр INIT вказує, що набір резервної копії повинен перебувати в першому файлі на даному носії, причому заголовок носія залишається без змін, але всі дані на цьому носії перезаписувати; іншими словами, INIT вказує перезапис всього, чт.е. на стрічці. Параметр NOINIT вказує, що даний набір резервної копії додається до вмісту носія. Якщо ви повторно використовуєте стрічки, то вам потрібно використовувати цей параметр
MEDIADESCRIPTION \u003d текст	Це текстове поле задає опис набору носіїв
MEDIANAME \u003d імя_носітеля	Вказує ім'я носія
MEDIAPASSWORD \u003d пароль	За допомогою цього параметра ви можете вказувати пароль для набору носіїв
NAME \u003d імя_набора_ резервной_копіі	Цей параметр дозволяє вам задавати ім'я набору резервної копії
NOSKIP | SKIP	Параметр NOSKIP вказує, що перш ніж перезаписувати набори резервних копій на даному носії, будуть перевірятися дати закінчення терміну дії відповідних наборів резервних копій. Параметр SKIP відключає перевірку цієї дати
NO_TRUNCATE	Цей параметр забороняє усічення журналу транзакцій після створення резервної копії. Використовується тільки для резервного копіювання журналу транзакцій
NOUNLOAD | UNLOAD	Параметр NOUNLOAD вказує, що після завершення резервного копіювання носій друку не буде розвантажуватися з пристрою (наприклад, не буде вилучатись стрічка). Параметр UNLOAD вказує, що після закінчення резервного копіювання носій буде вивантажено
RESTART	Цей параметр вказує SQL Server необхідність перезапуску резервного копіювання, яке було перервано
STATS [\u003d відсоток]	Цей параметр вказує висновок повідомлення після виконання певного відсотка резервного копіювання. Його корисно використовувати, якщо ви любите стежити за ходом виконання операцій

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

Прес-центр

Створення резервних копій та відновлення

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

Асоціація виробників і споживачів продуктів систем зберігання SNIA (Storage Networking Industry Association) так визначає операції резервного копіювання:

• Резервна копія (англ. Backup copy) - дані, що зберігаються на енергонезалежних носіях, зазвичай віддалено, призначені для відновлення, в разі якщо оригінал копії даних загублений або недоступний.
• Створення резервних копій (англ. Backup) - процес створення резервних копій.

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

Система блочного резервного копіювання (англ. Image-level або block-level backup) працює безпосередньо з носієм, ігноруючи файлову структуру, і зберігаючи всі матеріали, повністю - операційну систему, робочі дані, настройки та інше. Перевагою виконання даного виду резервного копіювання є висока швидкість. Однак зазвичай при виконанні операцій копіювання потрібно призупинити роботу додатків, щоб копія була цілісною (англ. Consistent).

При виконанні операцій резервного копіювання на файловому рівні (англ. File-level або file-based backup) використовує файлову систему. У цьому випадку відносно простим завданням є відновлення деяких конкретних файлів. В цілому ж, операції резервного копіювання тривають довше, виникає додаткове завантаження операційної системи, а також з'являється проблема доступу до відкритих файлів.

Резервне копіювання може здійснюватися і на рівні додатків (англ. Application-level backup). Операції копіювання і відновлення проводяться за допомогою використання спеціально передбаченого в резервовану додатку програмного інтерфейсу API (англ. Application Programming Interface). Резервна копія являє собою набір файлів і можливо інших об'єктів, що визначаються самим додатком, які разом є відображенням стану програми на деякий момент часу. При даному способі резервного копіювання може виникати проблема сумісності між різними версіями додатків і систем резервного копіювання, що реалізують відповідний інтерфейс.

Система резервного копіювання є службовою підсистемою ЦОД і має такі особливості:

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

При побудові системи резервного копіювання необхідно:

Укластися в скорочений "вікно" резервного копіювання. Вимога цілодобової (24х7) роботи інформаційних сервісів скорочує доступний часовий інтервал зупинки додатків, необхідний для здійснення операції резервного копіювання ( "вікно" резервного копіювання).
• Зменшити трафік даних резервного копіювання в загальній корпоративної обчислювальної мережі.

Методи резервного копіювання.

LAN backup
До появи мереж зберігання даних (Storage Area Network - SAN) для скорочення трафіку резервного копіювання в основній мережі застосовувалася виділена мережа резервного копіювання, а також багаторівнева структура, що включає кілька серверів копіювання. Виділення сервера копіювання і розташування його в мережі "ближче" до продуктивних серверів, що обробляють найбільші обсяги інформації, дозволяє локалізувати трафік резервного копіювання між сервером копіювання і продуктивними серверами і скоротити навантаження на загальну ЛВС.

LAN-free backup
З появою SAN з'явилася можливість передавати трафік резервного копіювання, не через ЛВС, а безпосередньо з серверів на пристрої зберігання даних (зазвичай це стрічкові бібліотеки), підключені до SAN. Такий метод отримав назву "LAN-free backup". При використанні цього методу сервер-клієнт одночасно з іншими завданнями виконує функції сервера копіювання резервуються даних на доступні йому через SAN пристрої зберігання. При цьому на сервер управління резервним копіюванням покладається завдання виконання розпису резервного копіювання шляхом видачі через ЛВС (по протоколу TCP / IP), що управляють, і контролю виконання завдань серверами копіювання. Таким чином, вирішується завдання зменшення трафіку даних резервного копіювання в ЛВС.

Але метод "LAN-free backup" не вирішує проблему "вікна" резервного копіювання. Більш того, даний метод створює додаткове навантаження на сервера-клієнти, покладаючи на них додаткові функції серверів копіювання резервуються даних. Деякі програми дозволяють проводити резервне копіювання без припинення своєї роботи (online backup), це реалізовано в багатьох транзакційних додатках і за допомогою спеціальних опцій програмного забезпечення резервного копіювання, таких як засоби копіювання відкритих файлів. Однак застосування подібних технологій не знижує навантаження на продуктивні сервера, яка при великих обсягах даних (терабайти і більше) може збільшити час вирішення основних завдань вище допустимого порогу.

Serverless backup
Ідеальною була б така схема резервного копіювання, коли дані сервера-клієнта копіюються через мережу зберігання SAN на пристрій зберігання будь-яким стороннім пристроєм (який отримав назву "Data Mover"), не використовуючи при цьому обчислювальні ресурси сервера-клієнта і не перериваючи його роботу. Подібний метод резервного копіювання отримав назву "Serverless backup". Роль "Data Mover" може виконувати як виділений для цієї мети сервер, підключений до того ж дискового масиву, що і продуктивний сервер, так і спеціальний пристрій - маршрутизатор.

CDP (Continious Data Protector)
Згідно з визначенням SNIA, безперервна захист даних (CDP) - це методика постійного відстеження змін даних, і збереження їх в незалежному від вихідних даних сховище, що дозволяє відновлення на будь-який момент часу в минулому. CDP системи можуть бути реалізовані на рівні блоків, файлів або додатків і забезпечувати дрібну гранулярность відновлення об'єктів на будь-який момент часу аж до одиночної операції записи. Згідно з цим визначенням, все CDP рішення мають наступні властивості:

• Зміни постійно відстежуються і записуються
• Всі зміни зберігаються на окремому логічному пристрої
• RPO (точка відновлення) - довільна і не повинна бути визначена заздалегідь.

Приклади впроваджень.

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

Типове питання, з яким звертаються замовники: забезпечення схоронності бази даних системи "1С", розміром близько 1 Гбайт і бази клієнтів в MS Access, близько 300 Мбайт. Інформація важлива вся і втрачати більше дня роботи - не бажано. Бюджет, виділений ІТ-підрозділу, не перевищує 100 000 рублів.

Необхідно зрозуміти вимоги замовника - який обсяг інформації потрібно резервувати, скільки часу потрібно зберігати резервні копії, необхідні наступні документи віддалене зберігання (offline) резервних копій.

Якщо замовнику потрібно зберігати дані за найближчі кілька днів і вартість рішення повинна бути мінімальною, то найбільш простим і зручним рішенням буде невелике мережеве сховище даних (NAS - Network Attached Storage). Ці пристрої випускаються різними виробниками обладнання, мають від 2 до 12 дисків і забезпечують доступ по основних протоколах доступу: CIFS, NFS, HTTP, iSCSI. Структурна схема рішення наведена на малюнку 1.

Рис.1 NAS зберігання.

Вартість цього рішення становить від 15 000 до 70 000 рублів на залежності від обсягів зберігання.

Основні недоліки цього рішення - це неможливість масштабування при зростанні обсягів зберігання та необхідність контролю успішності проведення резервного копіювання.

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

Для створення резервних копій створюються політики резервного копіювання, які регламентують "Що, Куди і Коли". Які дані, куди і з якою періодичністю повинні бути збережені. Додаткові можливості ПО централізованого резервного копіювання дозволяють відновлювати окремі листи і таблиці баз даних без необхідності відновлення всього обсягу даних. Запис резервних копій на стрічкові носії дозволяє організувати віддалене зберігання резервних копій і збереження важливих даних у разі катастрофи. Використання стрічкових носіїв для зберігання архівних копій дозволяє прочитати дані через 50 років після їх запису.

Вартість такого рішення починається від 50 000 рублів і включає сервер для зберігання резервних копій і ПО резервного копіювання.

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

Виклики в роздрібній торгівлі

Замовник: велика страхова компанія.

Короткий опис причини аварії: помилка персоналу, неправильна установка патча на Oracle.

Опис проблеми

Мова йде про велику компанії, яка має зріле ІТ-підрозділ і вкладає достатньо коштів у його обладнання і персонал. Досить сказати, що СУБД Oracle працювала на двох Oracle Exadata, розподілених за двома технологічними майданчикам, з проробленим DR-рішенням і налагодженою системою резервного копіювання.

В один сумний день було прийнято рішення встановити патч на СУБД Oracle. На жаль, інженер не дочитав інструкцію до кінця: «Що я, патч не встановлено без папірця ?!» - і неправильно зробив це. Помилку помітили через кілька годин, коли СУБД стала поводитися дивно і повідомляти про це в журналах. Тоді інженер прийняв рішення відкотитися. Ця дія остаточно знерухомити обидва примірника бази (всі зміни встигли отрепліціроваться на Standby) і зіпсувало всі дані.

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

Рішення

Замовник прийняв рішення відновлюватися з резервної копії. У той час відновлення бази в 5 ТБ (зараз ~ 15 ТБ) зайняло - увага! - більше 30 годин! Разом, через 1,5 дня відновили базу на день раніше аварії. Але даних-то було більше! Все інше силами програмістів і персоналу відновлювали з інших систем компанії, з первинної документації (бланків заяв, копій, сканів). На це пішло ще 1,5 дня напруженої роботи.

Разом

2 High-End системи Oracle Exadata, Oracle Standby, що працює система резервного копіювання та 3 !!! дня повного простою при неправильній установці патча. Чи було це допустимо згідно з регламентом компанії? Звичайно ж ні.

Основна проблема: відсутність коштів швидкого відновлення при логічних помилках.

Як можна було уникнути

Для пом'якшення наслідків подібних аварії потрібно рухатися в двох напрямках. З одного боку, робити резервування частіше, а з іншого - мати можливість швидко відновитися. Могли б допомогти такі продукти:

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

Технологія Snapshot. Миттєві знімки дозволяють резервувати і відновлювати дані за секунди. При цьому вони слабо впливають на продуктивність, і є можливість робити знімки досить часто (наприклад, раз на годину). Таким чином, можна було відкотитися на годину назад і відновлювати тільки годину втрачених даних.

Continuous Data Protection - безперервна захист даних. Це пропрієтарні пристрою або ПЗ, що дозволяє Залогуватися всі записи з можливістю відкату на будь-яку точку в часі. Діє аналогічно Oracle FlashBack, але для будь-яких даних.

Кейс: Апаратний збій

Замовник: Федеральна служба в одному з суб'єктів РФ

Короткий опис причини аварії: апаратна помилка всередині дискового масиву.

Опис проблеми

Цього разу у компанії трохи менше розвинена ІТ-інфраструктура, зате частіше зустрічається у наших замовників: дискові масиви середнього рівня, СУБД Oracle, Standby не використовується.

Як це часто буває, в п'ятницю, коли все вже радісно збиралися додому, стався апаратний збій масиву. Через бага в прошивці при відмові диска масив перетворив дані в кашу. Від цього перестали працювати бази даних сервісу федерального рівня. Більше доби замовник чекав рішення від вендора СГД. Після аналізу всіх логів вендор дав свій висновок: дані втрачені!

Рішення

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

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

Ще кілька днів знадобилося на повне відтворення інфраструктурних сервісів - не було резервних копій операційних систем, бінарників, конфігурацій і т.п.

Всю втрачену інформацію збирали з первинних документів (сторонні бази, паперові документи, дані на комп'ютерах операціоністів), що зайняло ще 3 дні. Деякі документи, можливо, так і не вдалося відновити.

Разом

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

Основні проблеми:

• СРК була налаштована не так, пробні відновлення не проводили.
• Не було коштів оперативного відновлення в разі аварії і дублюючих систем.
• Не було чіткого DR-плану.

Як можна було цього уникнути:

• Використовувати Oracle Standby, розташований на іншому масиві. Це дозволило б протягом нетривалого часу переключитися на працюючий екземпляр даних.
• Oracle ZDLRA дозволив би в набагато більш стислі терміни відновити БД на резервному обладнанні.
• Грамотні планування процесів резервного копіювання і відновлення дозволили б уникнути таких великих втрат і відновитися менш ніж за добу.

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

Основні проблеми систем резервного копіювання

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

Швидкість резервного копіювання та подальшого відновлення

На даний момент швидкість backup прямо пропорційна обсягу даних, при цьому у всіх наших замовників річне зростання даних не менше 30%. За 3-4 роки дані як мінімум подвоюються, але у деяких компаній цей показник навіть вище, при цьому за той же час швидкість резервного копіювання не змінюється зовсім. Тут можна зробити простий висновок, що ті терміни і ті SLA, які були 3-4 роки тому актуальні, зараз потрібно збільшувати як мінімум удвічі. При цьому вимоги бізнесу до відновлення даних (RPO / RTO) постійно зростають.

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

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

Залежність часу відновлення від обсягу даних

Низька гранулярность відновлення

Фактично більшість помилок пов'язано з втратою якоїсь частини даних. При цьому традиційні засоби резервного копіювання дозволяють відновлювати дані безпосередньо з backup, але частіше доводиться відновлювати систему цілком. Якщо ваша база даних займає 15 ТБ, ви витратите на це кілька діб. Замовників, у яких вимога RTO (Recovery Time Objective) - 2 дні, ми не знаємо. У нашій практиці таких прикладів не було, коли б клієнт сказав: «Хлопці, відновлюватися 2 дня - це нормально, я потерплю», - якщо адміністратор випадково видалив кілька рядків з бази даних. Досить часта проблема, з якою стикаються наші клієнти: як вичленувати невеликий шматочок даних з резервної копії, не виконуючи повне відновлення її саму (і не витрачати на це декілька діб).

Надмірне RPO (Recovery Point Objective)

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

приховані помилки

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

На жаль, більшість наших клієнтів цим не займається. Часто складається така ситуація, що всі роблять резервні копії, але до моменту відновлення, виявляється, що їх можна було не робити - вони просто не відновлюються, незважаючи на зовні правильну роботу СРК. Це відбувається з різних причин. І найкраще це можна продемонструвати на прикладі. Один наш замовник використовував систему SAP з базою даних Oracle. Резервне копіювання здійснювалося вбудованими засобами SAP за допомогою одного з найбільших вендорів СРК.

Були налаштовані 2 різні політики резервного копіювання: одна з них файлова - копіювала дані операційних систем і налаштування ПО, а друга - саму базу даних. Оскільки вони були спрямовані на одну і ту ж систему, був налаштований список винятків, в який занесли базу даних. Файлова політика враховувала цей список і не резервувала ті директорії, в яких лежала БД. Через особливості архітектури СРК, політика резервування БД ігнорувала список виключень і коректно копіювала потрібні дані.

В одному з релізів ПО даний вендор виправив цю «помилку», з цього дня обидві політики стали враховувати список виключень і обходити базу даних стороною. Причому це ніяк не відбилося на помилках в ПО СРК, так як вона працювала штатно: всі дані, які не вказані в списку, резервувалися нормально. Система рапортувала про свою справності.

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

несистемний підхід

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

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

Щоб перевірити, наскільки системно ви підійшли до питання побудови СРК, дайте відповідь на кілька простих запитань:

• Чи є у вас вибудувана модель ризиків, в рамках якої прописано місце СРК?
• Від яких збоїв вас захищає СРК?
• Як ви захищаєтеся від інших ризиків (це можуть бути не просто технічні рішення, а й інші компенсаційні заходи)?
• Чи впевнені ви в тому, що система відновиться в встановлені терміни?
• Перевіряли ви це на практиці?

Рішення

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

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

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

Іншим рішенням може бути використання різних засобів додатків, наприклад, Oracle Standby, DB2 HADR, MS SQL Always On. Всі ці засоби дозволяють мати працюючу копію продуктивної системи, відв'язаних від вихідної, яку можна розгорнути миттєво. Це дозволяє почати роботу відразу після збоїв.

Друге - дати можливість відновлювати тільки потрібні дані. Наш підхід враховує, що при відновленні частини даних нам не потрібно копіювати всю систему цілком, ми можемо відновити дані, які нам потрібні на даний момент. Це досягається можливістю швидко розгорнути або використовувати вже розгорнуті системи, які ці дані містять. Так само як і в першому випадку, snapshot дозволяють вирішити цю проблему (можна швидко відкрити snapshot на сусідній сервер і витягнути необхідний шматочок даних). Сюди ж можна віднести технології безперервної захисту даних, наприклад, Oracle Standby з Flashback, рішення continuous data protection (CDP). Вони дозволяють швидко розгорнути працюючу копію даних на потрібний момент часу.

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

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

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

Для найбільш критичних систем тимчасового інтервалу може не бути зовсім - дані потрібно захищати безперервно. Існує кілька рішень цього класу, наприклад, Oracle Standby з FlashBack, який дозволяє відкотити базу даних на деякий час назад завдяки логування всіх змін. Також можна використовувати ПАК Oracle ZDLRA, який практично синхронно отримує всі зміни в БД, або програмно-апаратні комплекси загального призначення, наприклад, EMC RecoverPoint, ПО Vision Solutions Double-Take. Вони теж логіруют всі зміни і дозволяють відновитися на будь-яку точку в інтервалі часу.

Якщо говорити про інновації в системах резервного копіювання та відновлення, не можна не згадати Oracle Zero Data Loss Recovery Appliance (ZDLRA). Цей програмно-апаратний комплекс сімейства Oracle Engineered Systems надає можливість резервного копіювання та швидкого відновлення Oracle Database будь-яких платформ і будь-яких Edition (Enterprise і Standard). В основі ZDLRA лежать віртуальні backup-бази (Virtual Full Backup), одержувані на основі першого повного backup і наступних журналів змін. За рахунок цих віртуальних backup можна відновити базу даних на будь-який момент часу значно швидше, ніж при класичному використанні СРК за схемою «раз на тиждень повний backup, раз на добу інкрементальний». Можна сказати, що ZDLRA продовжує напрямок, заданий Oracle Exadata. У Exadata за рахунок спеціального Software реалізована інноваційна система зберігання, оптимізована під завдання Oracle Database. А в ZDLRA функціонує спеціальне Software, оптимізує резервне копіювання саме Oracle Database.

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

Четверте - зменшення прихованих помилок. Існує тільки один спосіб переконатися в коректній роботі резервної копії - спробувати її відновити. Це найправильніший і рідко використовується нашими замовниками метод.

Але ми пропонуємо вихід і з цієї ситуації. По-перше, мати легко відновлювані екземпляри систем. Це знову історія про snapshot- і standby-системах, які можна досить швидко розгорнути і перевірити. Часу і сил це займе незрівнянно менше, ніж «розмотування» всієї резервної копії. Звичайно, це допомагає далеко не завжди, але залишає трохи більше надії, що в разі надзвичайної ситуації буде можна відновити дані хоча б цими коштами.

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

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

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

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

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