Дуже часто я чую фрази на кшталт «навіщо мені бекап, у мене ж є RAID!». Або «я роблю бекапи на другий HDD в сервері!». Або щось подібне. Дуже часто через кілька місяців після цього я чую питання «а як мені відновити убиті дані?». І це засмучує.
Вимоги?
Давайте визначимося з термінологією. Що таке резервна копія?
Логічно припустити, що це копія даних, попередньо збережена з метою відновлення в разі знищення оригіналу.
Звідси випливає перша вимога - ізольованість. Не має сенсу робити копію документів на квартиру і зберігати її там же, де оригінал. Так не має сенсу робити копію даних і зберігати її на тому ж диску / в тому ж сервері, що і оригінал. Логічно? Цілком.
Їдемо далі. Якщо ми робимо копію даних, значить, боїмося їх втратити. Так? Так. Значить, все що резервуються дані для нас цінні. Так? Знову так. Звідси друга вимога - цілісність. Чи не сенсу в копіюванні без перевірки цілісності - на виході ми цілком можемо отримати биті дані або втратити частину безповоротно.
Ще один пункт. Уявімо, що ви видалили файл. Або не файл, а багато файлів. Наприклад, випадково зробили «rm -rf ./ test». І пішли спати, зі спокійною совістю. А опівночі стався ... бекап. Але ось невдача - налаштований він був так, що створював повну копію даних без урахування версій і змін. Тобто видалив віддалений вами файл і на резервному носії теж - зробив річ, зворотний своєму призначенню. Представили? Третя вимога - версіонірованія. Ви повинні мати можливість повернути попередній стан своїх даних, а не тільки мати дві однакові копії.
І що в результаті?
У підсумку ми отримали три вимоги, яким повинна відповідати система резервного копіювання для того, щоб носити це горде ім'я і надійно зберігати ваші дані. Ізольованість захистить від збою обладнання або зовнішніх факторів (пожежі, потопу і т.д.), а також зловмисного видалення даних (не дозволить зловмиснику або вірусу заразити / видалити і бекап теж), контроль цілісності гарантує, що зарезервовані всі ваші дані і ви не залишитеся у розбитого корита при втраті основного примірника, дізнавшись про проблеми занадто пізно, версіонірованія не дасть бекап-системі перемістити кулю з ноги користувача, який прострелив собі коліно - йому ж в голову.
Ближче до практики.
Чи забезпечує ваша схема цілісність даних? Наприклад, якщо на резервному носії закінчиться місце і копія не зможе коректно зберегтися - ви про це дізнаєтеся?
Чи забезпечує вона повноту? Якщо це додаток - збережені налаштування, якщо база даних - схема і т.д.
Чи можна з існуючої копії отримати працюючий оригінал? Або чогось не вистачає?
Чи уявляєте ви собі, що будете робити, якщо втратите основні дані? Чи є (нехай найпростіша) методика відновлення? Чи всі її пункти здійсненні і достатні для отримання даних? Практиці відомі приклади, коли бекап робився на зашифрований HDD, а складний і безпечний ключ шифрування зберігався не в голові у власника і навіть не на жовтому папірці, а ... так-так, на те ноутбуці, звідки і робився бекап. Як ви розумієте, при крадіжці ноутбука дані були втрачені безповоротно.
Проведіть «вчення» - уявіть, що основний носій втрачений і спробуйте відновитися. Упевнений, з першого разу у вас нічого не вийде, або з'ясується, що багато насправді не зовсім так, як ви представляли раніше.
Міфи і приклади поганих рішень
Чомусь люди люблять обманювати себе. Наприклад, багато хто вірить, що RAID замінює бекап і гарантує збереження даних. Особливо якщо RAID НЕ простенький - перший, а навернений, 5ий наприклад.
Але RAID - НЕ бекап. З певних вище критеріїв в загальному випадку не виконуються всі три - дзеркальні диски не ізольовані, які не контролюються і не версіоніруются. Падіння файлової системи, випадковий «rm -rf /» або помилка при роботі з розділами знищить дані на обох дисках і RAID нічим не допоможе їх зберегти. Більше того, якщо пошкоджену FS на одному диску зазвичай можна відновити хоча-б частково, то розпався масив - майже завжди немає.
Поширена схема «окремий HDD для бекапа» теж нежиттєздатна. По-перше, резервні дані доступні і уразливі для зловмисника, вірусу або звичайною помилки на кшталт вищезгаданого «rm -rf /». По-друге, є безліч ситуацій, причому дуже ймовірних, які знищать одночасно обидва диска. Наприклад бурхлива і красива (зі спецефектами) смерть блоку живлення. Або перекинуте на комп'ютер прибиральницею відро води. Або ... багато їх.
Утиліти начебто dropbox теж для бекапа мало годяться - якщо, звичайно, не передбачена версіоніруемость. Випадково зіпсувавши дані в основний копії ви втратите і резервну, ледь між ними синхронізуються зміни. Дані буде вже не повернути.
замість висновку
Бережіть свої дані, витративши 15 хвилин «до» - можна заощадити 15 годин «після». Не забувайте бородатий анекдот про тих, хто не робить бекапи і тих, хто їх вже робить.
Особливості довгострокового зберігання резервних копій
Відповідно до законодавчих вимог, галузевих нормативів і корпоративних політик від компанії можуть вимагатися тривалі терміни зберігання корпоративної інформації (5, 10 і навіть 30 років). На що потрібно звернути особливу увагу в такому випадку? При плануванні довгострокового резервного копіювання потрібно враховувати, що термін
Зворотний бік бекапа
Стандартна приказка на будь-які з даними: бекап робити треба було. І як би ніхто заперечити не може. Однак ... Коли ми говоримо «бекап робити треба» зазвичай ми говоримо про бекап тих даних, які втрачені. Мовляв, витратив би 2 хвилини, не засмучувати б зараз про втрачений місяці роботи. Однак, в цій фразі є лукавство. Якби ми знали, що саме
