Продовження «досвідчених дрібниць». Попередні частини: раз, два, три.
Сьогодні я розповім про принципи справи бекапа, які вишикувалися в результаті проб і помилок, і не раз рятували ситуацію в самий, здавалося б, несподіваний момент.
Бекапи - це страховка компанії від нещасного випадку. Робити бекапи - це навіть не правило, це аксіома. Який би не був пропалений адмін, і у нього іноді може «здригнутися рука», і з помилкою написаний скрипт, або випадково натиснута кнопка здатні наворотити багато бід, що вже говорити про посипалися HDD, пожежу та інші катаклізми. Так, бекапи витратні (час, ресурси, обладнання), їх сьогочасний ефект неочевидний, але головне що вони дають - страховка ризиків компанії. А це - дорогого коштує. Здавалося б, твердження зрозумілі всім, але при цьому нерідко виникає ситуація, коли сервер впав, бекап є, а зробити нічого не можна, система не відновлюється. І починаються танці для бубна з оркестром, витягування хоч якихось даних і т. п. радості.
Для початку давайте введемо і чітко розділимо такі поняття як архівування і бекап. Наприклад ось так:
- Архівування - це резервне копіювання з ДОВГОСТРОКОВИМ зберіганням даних. Процедура, коли один раз скопіювали, і забрали в банківський сейф. Звернення до архіву, це швидше виняток ніж правило, і процедура це може бути досить тривалою (залежно від того де і як зберігаються архіви).
- Бекап - це резервне копіювання з КОРОТКОСТРОКОВИМ зберіганням даних. Процедура, коли копіювання відбувається регулярно, носії перезаписуються, є поняття «глибина зберігання». При цьому доступ до бекапу зазвичай повинен бути максимально швидким.
Архівування
Архівування потрібно не всім і не завжди. Найчастіше це питання постає, коли компанія виходить за рамки «я, мій друг, дружина і кур'єр», і стосується зазвичай тільки файлів, фінансових баз, поштових баз, тобто тих документів, які і неелектронного життя прийнято зберігати в архівах (листи, накази, бухгалтерська первинка тощо).
Архіви зазвичай робляться раз на рік і зберігаються на зовнішніх носіях де-небудь в сейфі, в банківській комірці, на дачі у гендиректора (потрібне підкреслити). Тут все в цілому зрозуміло, головне не забувати хоча б раз на рік перевіряти стан архіву (наприклад, одночасно із записуванням нового відновити частину даних зі старого), і стежити за носіями, щоб ви завжди могли прочитати архів будь-якої глибини (наприклад, у мене була ситуація, коли був потрібен архів, який був зроблений 5 років тому, і зберігався на стрічці, що для якої не тільки був зламаний і списаний, але і вже давно не випускався. Архів звичайно прочитали, але скільки нервів і зв'язків для цього знадобилося - краще не згадувати).
Останні пару років, до речі, все частіше для архівів використовуємо не стрічки, а банальні HDD. Їх обсягів- вистачає, швидкість роботи - достатня для архіву, ціна - в рамках розумного, а єдиний інтерфейс підключення (раніше IDE, зараз SATA) усуває проблему «зламаного стримера», що важливо, оскільки дані можна прочитати практично на будь-якому комп'ютері, без залучення спец обладнання (як у випадку зі стрічками). Коли IDE зовсім пропаде, ймовірно скопіюємо на SATA (або що там буде після).
Бекап
Завдання бекапа як такого - зберігати свіжі резервні копії, для швидкого відновлення «випадково\спеціально віддаленого», або «згорілого», або «неправильно сконфігурованого». Якщо архіви зазвичай зберігаються стільки скільки живе організація, а іноді і довше, то для бекапів вже можна ввести поняття глибина зберігання, тобто час після закінчення якого бекап буде застарівати, і його можна перезаписати більш свіжими даними. Бекап загалом можна розділити на дві основні частини: бекап даних і бекап систем, і окремо стоїть бекап вмісту систем. Остання дуже велика і конкретна тема, сильно залежна від того, вміст яких саме систем ви хочете бекапити (поштовий сервер, БД, CRM, налаштування ПЗ тощо), тут її описувати не будемо.
Бекап систем
Бекап систем - це коли вам потрібно бекапити не окремі файли, а повністю всю систему, яка може складатися з декількох компонентів (наприклад, спец-ПО, база SQL, файлові дані), і відновлювати її краще цілком, ніж по частинах. Тут все досить просто: вибираєте бекап-софт (ціна, функціонал, зручність) і бекапіте систему так, щоб ви гарантовано могли відновити її, навіть у разі повної поломки сервера. Підходять всілякі Acronis'и, Symantec System Recovery тощо. Важливо пам'ятати ось що:
- ви повинні ВМІТИ відновлювати з бекапа. Тренуйтеся де завгодно, коли завгодно, але ви ПОВИННІ ВМІТИ це робити.
- продумуйте що саме ви бекапіте. Це значуще значення для універсальних серверів, коли, наприклад, на одному сервері крутиться БД, ваш внутрішньокорпоративний сайт і додатково причеплений том під файлові ресурси. У такій ситуації не варто заради бекапа зв'язки «складнобудований SQL + ваш сайт» бекапити з ним заодно ще й другий файловий том в 1500 Тб. Взагалі прагніть до ситуації «одне завдання - один сервер», не вішайте все-все-все на одну машину, а якщо вже повісили то бекапте його «системно».
- ваш софт повинен вміти відновлювати на інше залізо, що відрізняється від поточного. І ви повинні це хоча б раз спробувати!
- «системні» бекапи, особливо систем постійно використовуваних, не варто зберігати глибиною більш ніж тиждень. Подумайте самі, навіщо вам бекап вашого контролера домену давністю в місяць? У разі критичної ситуації вам знадобиться найсвіжіший бекап. А всі інші - це підстраховка, на випадок якщо «найсвіжіший» з якихось причин не відпрацював. Відводити на таку підстраховку більше ніж 1-2 ітерації, на мій погляд нелогічно і надміру витрачає місце.
- є системи, які складно взаємопов'язані з усією інфраструктурою, і відновити їх, навіть маючи під рукою свіжий «системний бекап» конкретного сервера, буває нелегко. Навскидку: Active Directory, Exchange и т.д. Виділіть час, вивчіть документацію, і в тестовому середовищі, хоча б раз - але спробуйте відновити АБСОЛЮТНО ВСЕ! Краще навчіться це робити в спокійній обстановці з Інтернетом під рукою, ніж з розлюченим начальником над головою.
Бекап даних
Бекап даних, це бекап окремих, самостійних даних (в основному це вміст вашого корпоративного файлосховища). Тут багато мудрості не потрібно - бери та копіюй, можна хіба що поміркувати над схемою бекапа. Я, наприклад, дотримуюся наступної схеми:
- У вихідні робиться повний бекап усіх даних. Глибина зберігання 28 днів, тобто є чотири незалежні повні бекапи. Таким чином за останній місяць ми зможемо відновити дані за будь-який вихідний день.
- По робочих днях робиться диференційний бекап, з глибиною зберігання 14 днів. Таким чином за останні два тижні ми можемо відновити дані за будь-який з днів.
- в перші вихідні кожного місяця, окремо від інших робіт, робиться місячний бекап, з глибиною зберігання в 12 місяців. Це щось середнє між бекапом і архівом. З одного боку термін зберігання досить великий, з іншого - нерідка ситуація коли потрібно відновити дані «пару місяців тому, максимум півроку». Як варіант, можна не робити місячний бекап окремою роботою, а просто копіювати відповідний тижневий.
Крім того, я намагаюся дотримуватися ось яких правил:
- використовую диференційний, а не інкрементальний бекап. (Якщо ви не знаєте що це таке - обов'язково прочитайте документацію, це досить важливі поняття). Мені важливіше виграш у швидкості відновлення, ніж в обсязі резервних копій.
- планую час бекапа так щоб встигати до ранку. Якщо бекап виконується довше - розбиваю його на кілька робіт, кілька серверів, або піднімаю питання про інше, більш швидкісне, обладнання.
- у розкладі бекапа намагаюся дотримуватися проміжків пов'язаних з тижнями (7 днів, 28 днів і т. д.) і не прив'язуватися до «перших\останніх днів місяця». Тиждень - досить постійна величина, 7 днів і в більшості випадків субота, неділя - це вихідні.
- використовую диски, а не стрічки. Мені не подобається дорогий посередник-стітей між даними в бекапі і даними в файлосховищі. Якщо він з якихось причин не працює, то надовго порушується вся система бекапу. Якщо використовувати жорсткі диски, то цього можна уникнути.
- намагаюся щоб логічно самостійна частина даних лежала в окремому бекапі. Наприклад, якщо говорити про Symantec Backup Exec, то одна робота = одна media. Дуже не люблю ситуацію, коли одна робота «розмазана» за кількома файлами. Це не тільки вносить сумбур в систему, але і в разі випадкового затирання одного з файлів («рука здригнулася») завдає шкоди не тільки одній роботі але і всім сусіднім.
- в обов'язковому порядку використовую софт з повідомленнями поштою. Якщо це самописний скрипт - ніхто не заважає дописати шматочок, який перевірятиме хоча б наявність нового бекапа, його розміру і надіслати дані поштою. Це сильно економить час у моніторингу бекапу.
Крім усього іншого модно також використовувати т. зв. «моментальні» бекапи, невеликої глибини (1-2 дні) а-ля служба VSS в Windows, коли користувачі самі можу вибирати що відновити з останніх версій документа. Це дуже допомагає, коли користувач вранці відредагував документ, а в обід його видалив і прсит відновити ранковий варіант.
Також можна використовувати DFS систему в ролі постійного онлайн бекапа, але це варто описати в окремому пості, що я пізніше і зроблю.
Продовження слідує.
P.S. Нагадаю, я не встановлюю правил, а ділюся своїм досвідом, досвідом НЕуніверсальним, отриманим у невеликих організаціях (30-500 ПК). Якщо у вас прийнято робити інакше - із задоволенням прочитаю про це в коментарях.
