Типи Бекапів RMAN. Повне, інкрементне та диференційне резервне копіювання Інкрементний бекап

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

Що таке інкрементальне резервне копіювання?

Інкрементне копіювання— це метод копіювання, при якому до початкової копії набору даних крок за кроком приписуються доповнення, що відображають зміни даних (ці покрокові зміни в наборі даних і називаються інкрементами).

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

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

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

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

Як виконати інкрементальний бекап файлів у Handy Backup?

Запрограмувати завдання інкрементного резервного копіювання Handy Backup дуже легко. Виберіть на Кроку 4 у просунутому режимі створення завдання інкрементнеабо змішане інкрементнекопіювання.

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

* На Кроку 1 створенні завдання необхідно поставити галочку навпроти пункту "Просунутий режим".

Рекомендоване рішення для інкрементального резервного копіювання

Крос-платформне рішення для інкрементального бекапу

Інкрементне копіювання файлів та папок у Linux та по мережі

Крім версії для Windows, Handy Backup також повністю підтримує на рівні програми, що виконується дистрибутиви Linux, засновані на Ubuntu 16.04 і 14.04. Також програма надає робочу станцію на Java для мережевих Windows, Linux та FreeBSD машин.

Спробуйте можливості Handy Backup для інкрементного бекапу файлів самостійно,
завантаживши та встановивши безкоштовну 30-денну пробну версіюпрограми з усіма функціями!

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

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

Загальні методи резервного копіювання

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

1. Повна резервна копія

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

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

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

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

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

Переваги та недоліки диференціального резервного копіювання

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

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

Переваги та недоліки інкрементних резервних копій

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

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

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

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

Примітка: Розмір блоку залежатиме від програм або вибраного користувачем розміру, якщо таке підтримує програма. Зазвичай розмір блоків знаходиться в діапазоні від 1 до 32 кілобайт.

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

Переваги та недоліки дельта блочного резервного копіювання

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

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

Примітка: Прикладом застосування такого методу резервного копіювання є FastBittm, який використовують великі компанії, такі як Microsoft, IBM та Compaq.

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

Переваги та недоліки бінарних патчів резервних копій

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

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

6. Дзеркальні резервні копії

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

Коли використовуються дзеркальні резервні копії

Дзеркальні копії без стиснення добре підходять у випадках, коли більшість копіюваних файлів вже стиснуто в архіви. Наприклад, музичні файли у форматі mp3 або wma, зображення у форматі jpg або png, відео в DivX, mov або flv форматі. Крім того, більшість інсталяторів також стиснуті. Якщо включити ці файли в звичайну процедуру повного резервного копіювання, яка застосовує стиснення, то ви помітите, що крім того, що таке копіювання буде виконуватися довго, підсумковий архів мало відрізнятиметься у розмірі (дуже мало даних буде стиснуто). У цьому сенсі, найкраще створювати окремі завдання для резервного копіювання для стислих і не стислих файлів. Якщо ваші програми резервного копіювання підтримують фільтри, ви можете їх використовувати для автоматичного вибору підходящих файлів для кожного із завдань.

Переваги та недоліки дзеркальних резервних копій

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

7. Синтетичні повні резервні копії

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

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

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

8. Резервне копіювання з використанням жорстких посилань

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

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

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

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

Примітка: Провідник Windows, підраховуючи розмір, не враховує використання жорстких посилань. Це означає, що якщо файл займає 100 Мб і має два жорсткі посилання, то реально буде споживатися всього 100 Мб диска, в той час як провідник Windowsпоказуватиме використання 200 Мб диска. Цей момент необхідно враховувати при використанні резервного копіювання з використанням жорстких посилань.

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

Заключні слова про резервування

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

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

Сьогодні ми розглянемо принципи організації інкрементального та диференціального резервного копіювання з використанням програми.

Часто користувачі використовують APBackup для повного збереження даних, наприклад в одну і ту ж директорію або щоразу в різні архіви з використанням , а також параметра глибина архіву. Це добре працює на невеликих обсягах даних. Але якщо, наприклад, кожен день необхідно архівувати повністю великий обсяг інформації (наприклад, кілька десятків гігабайт), то повний архів може зайняти багато часу, а так загальмувати роботу комп'ютера. Хоча є механізм дозволяє регулювати навантаження на процесор комп'ютера (завдання низького пріоритету процесу архівування, автоматичні паузи в процесі архівування,..).

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

Чим відрізняється інкрементальне та диференціальне копіювання? Припустимо, ми зробили повну резервну копію вихідного каталогу і тепер кожен день необхідно зберігати зміни цього каталогу. У разі інкрементального бекапу, щодня програма архівуватиме лише нові або змінені файли з моменту останнього бекапу (повного або інкрементального). Таким чином, щоб відновити вихідний каталог у разі аварії нам знадобиться повний архів та ВСІ інкрементальні копії з моменту створення цього повного архіву. У разі диференціального копіювання щодня створюватиметься наростаючий архів нових та змінених файлів з моменту повного архіву. Тобто. кожен наступний диференціальний архів містить файли, що входять до всіх попередніх диференціальних архівів. При відновленні нам знадобиться лише повний архів та ОСТАННИЙ диференціальний.

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

Отже, для певності, припустимо, нам необхідно організувати резервне копіювання папки C:\work\в архів D:\backup\. Ми будемо робити повний бекап у неділю (наприклад, вихідний, коли ніхто не працює з сервером), а інкрементальні копії щовечора решти днів тижня.

Режим копіювання може бути БУДЬ-ЯКИЙ, програма буде працювати однаково в будь-якому режимі: Архівування (можливо з використанням зовнішнього архіватора), копіювання, копіювання на FTP. У прикладі це буде архівування з використанням внутрішнього архіватора.

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

Назвемо завдання TEST_FULL, режим копіювання: «Архівувати», Вид резервного копіювання: "Зберігати всі файли"

Розклад: щотижня по неділях.

Джерело: "C:\WORK"

Для збереження повного архіву використовуємо папку "d:\backup\", архів має префікс "FULL_" + формат дати. Глибина = 1, тобто. буде збережено лише 1 останній повний архів.

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

Тепер, коли завдання для повного резервного копіювання готове, можна створити копію для налаштування інкрементального резервного копіювання. Копію завдання можна зробити, перебуваючи в основному вікні програми через меню "Завдання"-> "Створити копію (F5)"

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

Опис: TEST_INC, Вид резервного копіювання: "Тільки нові та змінені файли (з останнього архіву)". Це якраз інкрементальний режим резервного копіювання. Для вибору диференціального режиму необхідно вибрати режим копіювання: "Тільки нові та змінені файли (з останнього повного архіву)"

У розкладі змінимо дні тижня виберемо всі дні тижня, крім неділі, коли у нас буде відбуватися повне резервне копіювання

На закладці «Збереження архіву»необхідно змінити префікс архіву на інший, ніж у повної копії, змінимо на «INC_». А також змінимо глибину архіву на 7 ДНІВ. Т.к. для відновлення нам знадобляться ВСІ інкрементальні копії з повного архіву тобто. усі копії за останні 7 днів. Що стосується диференціального копіювання глибину можна ставити 1 день, т.к. нам потрібно буде лише останній архів.

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

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

Багатьом відомі різні системи створення образів дисків та резервного копіювання даних, наприклад 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.

Диференціал проти інкрементного резервного копіювання

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

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

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

Відмінності

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

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

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

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

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

Диференціальні резервні копії швидше, ніж інкрементні резервні копії для невеликих баз даних.

Інкрементне резервне копіювання вигідніше для великих наборів даних.