Резервна копія з інкрементними даними. Інкрементне резервне копіювання. Incremental backup: інкрементне резервне копіювання

💖 Подобається?Поділися з друзями посиланням

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

Клонування

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

Резервне копіювання у вигляді образу

Образ – точна копія всього розділу або носія (пристрою), що зберігається в одному файлі.

Резервне копіювання в режимі реального часу

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

Схеми ротації.

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

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

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

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

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

"10 наборів" Дана схема розрахована на десять наборів носіїв. Період із сорока тижнів ділиться на десять циклів. Протягом циклу за кожним набором закріплено один день тижня. Після чотиритижневого циклу номер набору зсувається на один день. Іншими словами, якщо у першому циклі за понеділок відповідав набір номер 1, а за вівторок - номер 2, то у другому циклі за понеділок відповідає набір номер 2, а за вівторок - номер 3. Така схема дозволяє рівномірно розподілити навантаження, а отже, і знос між усіма носіями.

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

Зберігання резервної копії

1. Стрічка стримеру - запис резервних даних на магнітну стрічку стримеру;

2. «Хмарний» бекап» - запис резервних даних за «хмарною» технологією через онлайн-служби спеціальних провайдерів;

3. DVD чи CD - запис резервних даних на компактні диски;

4. HDD – запис резервних даних на жорсткий дисккомп'ютера;

5. LAN - запис резервних даних на будь-яку машину всередині локальної мережі;

6. FTP – запис резервних даних на FTP-сервери;

7. USB - запис резервних даних на будь-який USB-сумісний пристрій (такий, як флеш-карта або зовнішній жорсткий диск);

8. ZIP, JAZ, MO – резервне копіювання на дискети ZIP, JAZ, MO.

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

    Інкрементний бекап рівня 0 еквівалентний повному бекапу, який був відзначений як рівень 0.

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

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

Повні резервні копії

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

Інкрементні резервні копії

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

Інкрементні резервні копії визначаються за допомогою ключове слово INCREMENTAL команди BACKUP. Ви вказуєте INCREMENTAL LEVEL.

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

    Диференціальний:Тип інкрементного бекапу за замовчуванням, який резервує всі блоки, змінені після останнього інкрементного резервного копіювання або на рівні 1, або на рівні 0

    Сукупний (Кумулятивний):Резервує всі блоки, змінені після останнього резервного копіювання на рівні 0

Приклади

    Щоб виконати інкрементне резервне копіювання на рівні 0, використовуйте таку команду:

  • Щоб виконати сукупне інкрементне резервне копіювання, використовуйте таку команду:

    RMAN> BACKUP INCREMENTAL LEVEL 1 CUMULATIVE DATABASE;

RMAN робить повні резервні копії за замовчуванням, якщо не вказано ні FULL, ні INCREMENTAL. Стиснення невикористаних блоків призводить до пропуску блоків, які жодного разу не здійснювався запис, при резервуванні в резервні набори - навіть для повних резервних копій.

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

Відзначте:Можна виконувати будь-який тип резервного копіювання (повний або інкрементний) бази даних, яка знаходиться в режимі NOARCHIVELOG – якщо, звичайно, база даних не відкрита. Зауважте також, що відновлення обмежується часом останнього резервного копіювання. База даних може бути відновлена ​​до останньої зафіксованої транзакції, лише коли база даних перебуває в режимі ARCHIVELOG.

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

Повні бекапи

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

Інкрементальні бекапи

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

Плюси інкрементального резервування порівняно з повним

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

Багатьом відомі різні системи створення образів дисків та резервного копіювання даних, наприклад Acronis True Image, Pagaron Drive Backup, Ghost, Time Machine для Mac-сумісних комп'ютерів та ін. Компанія Microsoft також впровадила у свої операційні системи систему резервного копіювання даних, яка доступна як звичайних користувачів, так і для системних адміністраторів. Перед випуском операційної системи Windows Vista компанія Microsoftпропонувала користувачам систему резервного копіювання NTBackup та утиліту System Restore, які мали безліч недоліків. З виходом Windows Vista та переходом на формат зберігання образів VHDз'явилася можливість простішого резервного копіювання даних та створення образів операційної системи засобами нового комплексу утиліт під назвою Windows Backup and Restore. Після випуску нових операційних систем цей компонент удосконалювався та модифікувався. У цій статті ми розглянемо, що пропонує компанія Microsoft кінцевому користувачеві для резервування даних у операційній системі Windows 8, що нещодавно вийшла. Але спочатку коротко розповімо про основні типи резервного копіювання, які реалізовані в численних продуктах різних компаній.

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

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

Клонування розділів та створення образів

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

Повне файлове резервування

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

Диференційне резервування

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

Інкрементне резервування (Incremental backup)

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

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

Windows Backup and Restore

Компонент Windows Backup And Restore (Архівація та Відновлення) став доступний користувачам починаючи з виходу операційної системи Windows Vista та відповідає за створення повного бекапа операційної системи з можливістю інкрементного резервування. З виходом операційної системи Windows 8 цей компонент змінив назву Windows 7 File Recovery. Хоча він нічого зі свого функціоналу і не втратив, Microsoft рекомендує використовувати для резервування даних нову утиліту File History, яка включена до операційних систем Windows 8 і Server 2012, але про неї ми розповімо трохи пізніше. Windows Backup And Restore дозволяє створювати автоматичний повний бекап на змінний носій, оптичні дискиабо у спеціальне місце на віддаленому сервері.

Остання можливість доступна лише певних редакцій Windows 7/8, оскільки позиціонується як рішення для ІТ-адміністраторів компаній. Повний бекап системи у разі використання цього компонента передбачає не тільки збереження файлів користувачів, а й можливість створення образу всієї операційної системи та резервування окремих дисківкомп'ютера. Для користувача також є створення виключно образу системи, який згодом можна не тільки витягти на новий носій цього комп'ютера, але й використовувати як віртуальний диску системах віртуалізації. У разі застосування цього компонента користувач може задати ті папки, які потрібно резервувати, а також вказати ті системні диски, які потрібно зберігати при повному бекапі. При резервуванні лише файлів користувача Windows Backup And Restore використовує інкрементне резервування даних, що дозволяє отримати більше зліпків файлів у різні моменти часу. Зазвичай повне резервування виконується раз на тиждень і передбачає не тільки резервування файлів користувача, а й створення образу системи, а також копіювання даних для точок відновлення компонента Windows System Recovery. Процес відновлення файлів користувачів може відбуватися прямо з-під операційної системи - він досить простий і зрозумілий більшості користувачів. Відновлення системи при серйозному збої може бути здійснено за допомогою вбудованих утиліт Windows Recovery. Для цього необхідно або створити новий спеціальний диск відновлення або використовувати настановний образопераційна система, з якої вона встановлювалася на ПК раніше. Під час завантаження в режимі відновлення Windows Recovery запропонує користувачеві на вибір такі режими відновлення: відновлення файлів, перехід до певної точки відновлення, вилучення резервного образу системи на основний системний диск. Дані відновлення в цьому випадку можуть бути взяті з оптичного носія, зовнішнього або внутрішнього накопичувача, а також з мережевого сховища даних. Редакція операційної системи у разі ролі не грає. На жаль, незважаючи на те, що Windows Backup And Restore – досить потужний і зручний компонент операційної системи, компанія Microsoft заявила, що, згідно з проведеними дослідженнями, цією утилітою користуються в кращому разі 5% користувачів. У зв'язку з цим для більш простого та ефективного резервування даних компанія Microsoft розробила для користувачів наступне покоління резервування системи – Windows File History.

Windows File History

Windows File History, новий компонент операційних систем Windows 8 і Server 2012, до певної міри заміщає свого попередника - Windows Backup And Restore. Він має замінити лише інкрементне файлове резервування, тоді як створення образів системи та режим повного резервного копіювання можуть бути виконані виключно з допомогою Windows 7 File Recovery. Компонент Windows File History спочатку розроблявся як зручне та практичне рішення для користувачів, яким потрібний прозорий спосіб резервування своїх важливих даних. При розробці цієї утиліти особливу увагу було приділено простоті ініціалізації процесу у поєднанні з можливістю зручного та швидкого перегляду всіх збережених даних. Процес резервування за допомогою нової утиліти відбувається непомітно для користувача автоматичному режиміі вимагає від нього додаткових дій. Не можна не відзначити модифікування резервування на мережеві пристрої, що дозволяє легко та зручно працювати зі збереженими файлами, якщо використовуються мобільні підключення або слабкі канали зв'язку.

За основу утиліти Windows File History було взято частину базового функціоналу Windows Backup And Restore, в якій перероблено візуальну складову, відповідальну за представлення збережених даних користувача. Перегляд раніше збережених даних тепер доступний файлового менеджера Windows Explorerза допомогою окремої вкладки History. Це дозволяє швидко знайти необхідні файлиі відновити їх у будь-яке місце в системі. Незважаючи на те, що процес резервування ґрунтується на інкрементному резервуванні, при роботі з ним не виникає думки, що це саме резервування, це швидше історія створення, модифікування або видалення файлів користувачів, доступна в будь-який момент. Такий підхід до резервування даних, безумовно, підійде більшості недосвідчених користувачів, оскільки процес зручний і наочніший у застосуванні, ніж робота з Windows Backup And Restore.

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

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

За замовчуванням резервування за допомогою утиліти Windows File History відбувається щогодини, проте при необхідності користувач може сам вибрати проміжки часу між кожним резервуванням даних. Користувачеві доступна можливість встановити проміжки між резервуванням від 10 хвилин до 1 дня. Для Windows File History можна встановити лише одне поточне місце для резервування, проте, якщо додати кілька накопичувачів до місць резервування, вони можуть використовуватися поперемінно залежно від їх доступності. Це зручно у разі застосування мережевого сховища та окремого накопичувача. Таким чином, дані будуть зберігатися в кілька місць, залежно від поточної конфігурації. Також не можна відзначити функцію вибору кількості глибини збережених копій. Наприклад, через один або кілька місяців система може автоматично затирати старі дані, замінюючи їх новими. Це дозволяє заощаджувати простір у тому місці, куди відбувається резервування даних. Крім того, користувач може використовувати до 25% простору накопичувача для резервування даних.

Утиліта Windows File History за замовчуванням резервує папки, що найбільш активно використовуються, а саме - «Контакти», «Вибране» та «Робочий стіл». Крім того, резервування автоматично застосовується до всіх папок «Бібліотеки», що використовуються. Користувач може створювати власні бібліотеки даних, які є символьними посиланнями на реальні папки комп'ютера. Тобто, якщо користувачеві необхідно резервувати конкретну папкуна ПК, йому перед інсталяцією Windows File History необхідно додати цю папку до бібліотек. До того ж, якщо деякі папки потрібно виключити з резервування, то користувач може вибірково виключити всі бібліотеки користувача або набір папок, що часто використовуються. З урахуванням активної інтеграції з функцією «хмарного» зберігання даних Windows Skydrive використання цього «хмарного» сервісу може бути націлене на резервування важливих даних користувача, що зберігаються в «хмарі». Щоб така зв'язка працювала, необхідно лише встановити Skydrive, - після цього він автоматично додасться в бібліотеки і буде резервуватися в міру необхідності. На жаль, функція резервування даних на «хмару» поки недоступна користувачам, але компанія Microsoft вже планує додати певну можливість резервувати дані на «хмарні» сховища даних у майбутніх версіях своїх ОС.

Таким чином, нова система резервування Windows File History чудово підходить для більшості користувачів. Простий і зрозумілий інтерфейс з можливістю швидкого додавання та відновлення файлів набагато ближче до сучасного користувача, ніж попередня версіяінкрементного резервування у Windows Backup And Restore.

Про резервне копіювання в Останнім часомбагато говорять та пишуть. І ми, SIM-Networks, зокрема. :)


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

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

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

Як налаштувати бекап

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

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

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

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

Тому дбаємо про правильний розклад бекапів та забезпечуємо віддаленість сховища для копій.

Основні критерії вибору програми для бекапів

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

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

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

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

Повний бекап (full backup)

Тут все зрозуміло з назви: щоразу, згідно з завданням на бекап, створюється повна копія всієї системи, точніше, всіх даних, які ви визначили для резервного копіювання при постановці завдання. Для зменшення підсумкового обсягу резервної копії всі дані стискаються до архіву. Таким чином, у вашому сховищі при повному резервному копіюванні із заданою періодичністю з'являються архіви, де дані в основному дублюються (оскільки протягом тривалого часу не змінюються). Це серйозний недолік, адже витрачається величезний обсяг ресурсів (див.п.1 у списку критеріїв бекапу): місце у сховищі, час створення та процесорний час, обчислювальні потужності, нарешті, ресурси трафіку при транспортуванні архівів у віддалену СГД. І хоча метод повного копіювання раніше був дуже поширеним через високої надійностіУ чистому вигляді на сьогоднішній день він визнаний малоефективним. Наприклад, для резервного копіювання невисокою глибиною (менше двох тижнів) або з високою частотою (раз на добу, раз на кілька годин) повний бекап надмірно витрачає ресурси.

Трохи врятує ситуацію механізм дедуплікації- Виявлення та видалення дублюючих даних у повних копіях. Він також задається спеціальними програмними засобамияк на рівні СГД чи сервера, так і на клієнті безпосередньо. Статистика деяких джерелах наводить вражаючі результати ступеня дедуплікації - від 90% до 98%.

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

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

Інкрементальний або інкрементний бекап (incremental backup)

Порівняно з full backup набагато економічнішим і швидшим, оскільки в цьому процесі копіюються тільки ті файли, які змінилися з часу попереднього резервного копіювання. Вихідні дані, записані спочатку, не перезаписуються. Механізм інкрементального копіювання простий: як початкова точка бекапу Х 0 вибирається час (наприклад, опівночі з неділі на понеділок), в який робиться повний бекап; у точці Х 1 (північ з понеділка на вівторок) робиться копіювання файлів, змінених та/або які з моменту Х 0 ; у точці Х 2 (опівночі з вівторка на середу) копіюються файли, змінені/з'явилися з виконання Х 1 ; … у точці Х n відбувається завершення циклу і робиться наступний повний бекап.

Цей метод набагато економічніше витрачає ресурси та місця у сховищі, і часі, і трафіку передачі даних, порівняно з іншими. Однак при відновленні даних у разі потреби з резервної копії відбувається поетапне відновлення з точок Х n-1… Х 2, Х 1, Х 0 - до останнього повного бекапу включно, і цей процес може тривати багато часу.

Диференціальний бекап (differential backup)

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

При диференціальному бекапі відбувається копіювання "наростаючим підсумком": кожен змінений файл у кожній наступній точці бекапу копіюється заново. Тобто це виглядає як: Х 0 , Х 1 , Х 1 +Х 2 , Х 1 +Х 2 +Х 3 , ... + Х n , Х 0 + Х (1 + ... n)

Словом, дуже громіздко та складно при розрахунку місця у СГД.

Зрозуміти різницю між інкрементальним та диференціальним бекапом досить просто. Фактично – вона в одному слові. Просто порівняйте:

  • інкрементальний обробляє файли, змінені чи створені з виконання попереднього бэкапа;
  • диференціальний обробляє файли, змінені або створені з моменту виконання попереднього повногобекапу.

Інші види резервного копіювання

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

Його відрізняє висока швидкістьстворення, крайня економія місця та значно менша (порівняно з інкрементальним та диференціальним бекапами) кількість надлишкових даних. Здавалося б, застосовувати дельту повинні всі, але цього не відбувається, оскільки створення бекапів у такий спосіб і відновлення інформації відбувається засобами спеціального програмного забезпечення. Крім того, відновлення з дельта-бекапу відбувається дуже довго: дані доводиться збирати з мозаїки змінених шматочків. Тим не менш, цим методом зручно користуватися для забезпечення безперервного захисту даних (коли бэкап файлу робиться безпосередньо після його створення або внесення змін до нього - механізм, який віддалено нагадує автозбереження у файлах Word'а))) або у випадках зниженої пропускної спроможностіпри збереженні резервних копій у віддаленому СГД.

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

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

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

За останні 12-15 років у технологіях резервного копіювання відбулося багато критичних змін, які змусили переглянути ефективність підходів та відкрити нові способи. Наприклад, впровадження технології снепшотів (snapshots) - моментальних «знімків» файлової системи, з яких можна «склеїти» резервну копію, - дозволяють у хмарних системах робити резервне копіювання швидко та безболісно, ​​не зупиняючи віртуальної машини. Крім того, застосовуючись у хмарі, снепшоти дозволяють серйозно економити ресурс СГД, оскільки на диску клієнта місця не займають.

Клієнти SIM-Networks вибирають бекап!

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


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

Якщо ви орендуєте потужності в нашій хмарній інфраструктурі, замовити послугу резервного копіювання SIM-Cloud BaaS, простіше, у пару кліків. Все вже налаштовано та буде підключено автоматично, як тільки ви дасте команду. До речі коли наші інженери розробляли SIM-Cloud BaaS, вони проаналізували ефективність різних типівбекапу і зупинили свій вибір на методі інкрементального копіювання. Наше резервне копіювання у хмарі оптимізовано таким чином, що показник RTO (час відновлення даних із копії) складає в середньому від 15 до 30 хвилин, залежно від обсягу даних. Хмарний BaaS від SIM-Networks відповідає всім заявленим вище критеріям високоякісного резервного копіювання.

Ви можете самостійно вибрати, в якому центрі дата організувати сховище для бекапів. Перший варіант - локальне зберігання: ваші резервні копії зберігаються в тому самому ДЦ, де розгорнуто вашу основну інфраструктуру. Це дає можливість прискорити RTO та RPO. Другий варіант - бекапи відправляються на зберігання в дата-центр, віддалений від того, в якому розгорнуто основну інфраструктуру. Відновлення даних у цьому випадку відбуватиметься трохи повільніше, але фактор безпеки вищий. Якщо ви сумніваєтеся, який варіант вибрати, зверніться до нашої служби Customer Care - вам допоможуть підібрати оптимальне рішення.

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



Розповісти друзям