Навіщо потрібно робити резервні копії? Адже обладнання дуже і дуже надійне, до того ж є «хмари», які за надійністю кращі за фізичні сервери: при правильному налаштуванні «хмарний» сервер запросто переживе відмову інфраструктурного фізичного сервера, а з точки зору користувачів сервісів, буде невеликий, ледве помітний стрибок часу обслуговування. До того ж, дублювання інформації найчастіше вимагає оплатити «зайвий» процесорний час, дискове навантаження, трафік мережі.
Ідеальна програма працює швидко, не тече по оперативній пам'яті, не має дірок та не існує.
-Невідомий
Оскільки програми все ще пишуться білковими розробниками, а процес тестування часто відсутній, плюс постачання програм вкрай рідко відбувається із застосуванням «best practices» (які самі по собі теж програми, а отже, неідеальні), системним адміністраторам найчастіше доводиться вирішувати завдання, які звучать коротко, але ємно: "повернути, як було", "привести базу до нормальної роботи", "повільно працює - відкочуємо", а також моє улюблене "не знаю що, але полагодь".
Крім логічних помилок, які вилазять внаслідок недбалої роботи розробників, або збігу обставин, а також неповного знання чи нерозуміння дрібних особливостей побудови програм — у тому числі сполучних та системних, включаючи операційні системи, драйвера та прошивки, є ще й інші помилки. Наприклад, більшість розробників покладається на рантайм, зовсім забуваючи про фізичні закони, обійти які за допомогою програм все ще неможливо. Це і нескінченна надійність дискової підсистеми і взагалі будь-якої підсистеми зберігання даних (включаючи оперативну пам'ять і кеш процесора!), І нульовий час обробки на процесорі, відсутність помилок при передачі по мережі і при обробці на процесорі, і затримки мережі, які рівні 0. Не варто нехтувати й горезвісним дедлайном, адже якщо до нього не встигнути — будуть проблеми набагато нюанси роботи мережі та диска.
Як же бути з проблемами, які постають у повне зростання і нависають над цінними даними? Живих розробників замінити нема чим, та й не факт, що можна буде найближчим часом. З іншого боку, повністю довести, що програма працюватиме як задумано, поки що вийшло лише у кількох проектів, і зовсім не обов'язково можна буде взяти та застосувати докази на інші схожі проекти. Також подібні докази займають багато часу, і вимагають особливих навичок і знань, а це практично зводить до мінімуму можливість їх застосування з урахуванням дедлайнів. До того ж ми ще не вміємо у надшвидку, дешеву та нескінченно надійну технологію зберігання, обробки та передачі інформації. Подібні технології, якщо існують, то у вигляді концептів, або — найчастіше — лише у фантастичних книгах та фільмах.
Хороші художники копіюють, великі художники крадуть.
-Пабло Пікассо.
Найвдаліші рішення і напрочуд прості речі зазвичай відбуваються там, де зустрічаються абсолютно несумісні, на перший погляд, поняття, технології, знання, галузі наук.
Наприклад, у птахів і літаків є крила, проте незважаючи на функціональну схожість — принцип дії в деяких режимах збігається, і технічні проблеми вирішуються аналогічно: порожнисті кістки, використання міцних і легких матеріалів і т.п., — результати абсолютно різні, хоч і дуже схожі. Кращі зразки, які ми спостерігаємо в нашій техніці, також переважно запозичені у природи: герметичні відсіки у кораблів і підводних човнів — пряма аналогія з кільчастими хробаками; побудова raid-масивів та перевірка цілісності даних - дублювання ланцюжка ДНК; а також парні органи, незалежність роботи різних органів від ЦНС (автоматія роботи серця) та рефлекси – автономні системи в Інтернеті. Звичайно брати і застосовувати готові рішення «в лоб» загрожує проблемами, але хто знає, може, інших рішень і немає.
Знати б, де впадеш — соломки підстелив би!
—Білоруське народне прислів'я
Отже, резервні копії життєво необхідні тим, хто бажає:
- Мати можливість відновити роботу своїх систем з мінімальними простоями, а то й зовсім без них
- Сміливо діяти, тому що у разі помилки завжди є можливість відкату
- Звести до мінімуму наслідки навмисного псування даних
Тут – трохи теорії
Будь-яка класифікація довільна. Природа класифікує. Класифікуємо ми, бо нам так зручніше. І класифікуємо за даними, які ми беремо також довільно.
-Жан Брюлер
Незалежно від фізичного способу зберігання, логічне зберігання даних можна умовно розділити по 2 способам доступу до цих даних: блочне та файлове. Такий поділ останнім часом дуже розмитий, адже чисто блокових, як і чисто файлових, логічних сховищ не існує. Однак для простоти вважатимемо, що вони є.
Блокове зберігання даних має на увазі, що є фізичний пристрій, куди записують дані деякими фіксованими порціями, блоками. Доступ до блоків йде за деякою адресою, кожному блоку відповідає своя адреса в межах пристрою.
Резервна копія зазвичай робиться шляхом копіювання блоків даних. Для забезпечення цілісності даних на момент копіювання припиняється запис нових блоків, а також зміна наявних. Якщо брати аналогію зі звичайного світу - найближче шафа з однаковими пронумерованими осередками.
Файлове зберігання даних за принципом логічного пристрою близько до блокового і найчастіше організується поверх. Важливі відмінності - наявність ієрархії зберігання та людинозрозумілі імена. Виділяється абстракція у вигляді файлу - іменованої області даних, а також каталогу - спеціального файлу, в якому зберігаються описи та доступи до інших файлів. Файли можуть мати додаткові метадані: час створення, прапори доступу тощо. Резервують зазвичай так: шукають змінені файли, потім копіюють їх в інше, однакове за структурою файлове сховище. Цілісність даних зазвичай реалізують шляхом відсутності файлів, які йде запис. Метадані файлів резервуються аналогічно. Найближча аналогія — бібліотека, де є розділи з різними книгами, а також каталог з людинозрозумілими іменами книг.
Останнім часом іноді описують ще один варіант, з якого, в принципі, і почалося файлове зберігання даних, і яке має ті ж архаїчні риси: об'єктне зберігання даних.
Від файлового зберігання відрізняється тим, що не має вкладеності більше одного (плоска схема), а імена файлів хоч і людиночитані, але все ж таки більше пристосовані для обробки машинами. При резервному копіюванні об'єктні сховища найчастіше обробляють подібно до файлових, але зрідка є й інші варіанти.
— Є два види системних адміністраторів, ті, хто не робить резервні копії, і ті, хто ВЖЕ робить.
— Насправді три види: ще є ті, хто перевіряє, що резервні копії можна відновити.-Невідомий
Також варто розуміти, що сам процес резервного копіювання даних здійснюється програмами, тому йому притаманні ті самі мінуси, як і іншій програмі. Щоб прибрати (не виключити!) залежність від людського фактора, а також особливостей, які окремо не сильно впливають, але разом можуть дати відчутний ефект, застосовують т.зв. правило 3-2-1. Є багато варіантів, як його розшифрувати, але мені більше подобається наступне трактування: зберігати треба 3 набори тих самих даних, 2 набори треба зберігати в різних форматах, а також 1 набір треба мати на географічно віддаленому сховищі.
Під форматом зберігання слід розуміти наступне:
- Якщо є залежність від фізичного способу зберігання змінюємо фізичний спосіб.
- Якщо є залежність від логічного способу зберігання змінюємо логічний спосіб.
Для досягнення максимального ефекту правила 3-2-1 рекомендується змінювати формат зберігання обома способами.
З точки зору готовності резервної копії за її прямим призначенням – відновлення працездатності, – розрізняють «гарячі» та «холодні» резервні копії. Гарячі від холодних відрізняються лише одним: вони одразу ж готові до роботи, тоді як холодні для відновлення вимагають деяких додаткових дій: розшифровки, вилучення з архіву тощо.
Не варто плутати гарячі та холодні копії з online та offline копіями, які мають на увазі фізичну ізоляцію даних, і по суті є іншою ознакою класифікації способів резервного копіювання. Так offline копія — не підключена безпосередньо до системи, де її треба відновити — може бути як гарячою, так і холодною (з точки зору готовності до відновлення). Online копія може бути доступна безпосередньо там, де її треба відновлювати, і найчастіше є гарячою, але бувають холодні.
Крім того, не варто забувати, що сам процес створення резервних копій зазвичай не закінчується створення однієї резервної копії, а копій може бути досить велике число. Отже, треба розрізняти повні резервні копії, тобто. ті, що відновлюються незалежно від інших резервних копій, а також різницеві (інкрементальні, диференціальні, декрементальні тощо) копії — ті, які не можуть бути відновлені самостійно та вимагають попереднього відновлення однієї чи кількох інших резервних копій.
Розрізні інкрементальні копії — спроба заощадити розмір простору для зберігання резервних копій. Таким чином, в резервну копію пишуться лише змінені дані з попередньої резервної копії.
Різнісні декрементальні створюються з тією ж метою, але трохи іншим шляхом: робиться повна резервна копія, але реально зберігається лише різниця між свіжою копією та попередньою.
Окремо варто розглянути процес резервного копіювання поверх сховища, яке підтримує відсутність зберігання дублікатів. Таким чином, якщо писати повні резервні копії поверх нього, реально буде записана лише різниця між резервними копіями, проте процес відновлення резервних копій відбуватиметься аналогічно до відновлення з повною копією і повністю прозоро.
Quis custodiet ipsos custodes?
(Хто застереже самих сторожів? — лат.)
Дуже неприємно, коли резервних копій немає, проте набагато гірше, якщо резервна копія начебто й зроблена, але при відновленні з'ясовується, що вона не може бути відновлена, тому що:
- Цілісність вихідних даних було порушено.
- Сховище із резервними копіями пошкоджено.
- Відновлення працює неквапливо, не можна користуватися даними, які частково відновлені.
Правильно побудований процес резервного копіювання має враховувати подібні зауваження, особливо перші два.
Цілісність вихідних даних можна гарантувати кількома способами. Найчастіше використовуються такі: а) створення зліпків файлової системи на блочному рівні; б) «заморозка» стану файлової системи; в) особливий блоковий пристрій зі зберіганням версій; г) послідовний запис файлів або блоків. Також застосовуються контрольні суми, щоб забезпечувати перевірку даних під час відновлення.
Пошкодження сховища також можна знайти за допомогою контрольних сум. Додатковий метод — застосування спеціалізованих пристроїв, чи файлових систем, у яких не можна змінювати вже записані дані, але можна дописувати нові.
Для прискорення відновлення застосовується відновлення даних з декількома процесами відновлення — за умови, що немає «пляшкового шийки» у вигляді повільної мережі або нешвидкої дискової системи. Щоб обійти ситуацію з частково відновленими даними, можна розбити процес резервного копіювання на відносно невеликі підзавдання, кожна з яких виконується окремо. Таким чином, з'являється можливість послідовно відновити працездатність із прогнозуванням часу відновлення. Ця проблема найчастіше лежить в обмежувальній площині (SLA), тому не будемо зупинятись на цьому докладно.
Знається на прянощах не той, хто додає їх у кожну страву, але той, хто ніколи не додасть до нього нічого зайвого.
-В. Синявський
Практика в частині застосовуваного ПЗ у системних адміністраторів може різнитися, але загальні принципи однаково, однак, ті ж, зокрема:
- Настійно рекомендується використовувати готові рішення.
- Програми мають працювати передбачувано, тобто. не повинно бути недокументованих особливостей чи вузьких місць.
- Налаштування кожної програми має бути простим настільки, щоб не доводилося щоразу читати керівництво або шпаргалку.
- Рішення наскільки можна має бути універсальним, т.к. сервера за своїми апаратними характеристиками можуть відрізнятися і дуже.
Для зняття резервних копій із блокових пристроїв є такі поширені програми:
- dd, знайома ветеранам системного адміністрування, сюди ж належать подібні програми (та сама dd_rescue, наприклад).
- Вбудовані деякі файлові системи обслуговуючі програми (утиліти), створюють зліпок (dump) файлової системи.
- Всеїдні утиліти; наприклад, частинаclone.
- Власні, найчастіше собственнические, рішення; наприклад, NortonGhost і пізніші.
Для файлових систем завдання резервного копіювання частково вирішується за допомогою методів, що застосовуються для блокових пристроїв, проте завдання можна вирішити і ефективніше, використовуючи, наприклад:
- Rsync, універсальна програма та протокол для синхронізації стану файлових систем.
- Вбудовані засоби архівації (ZFS).
- Сторонні засоби для архівації; найпопулярніший представник - tar. Є й інші, наприклад, dar – заміна tar із орієнтацією на сучасні системи.
Окремо варто згадати про програмні засоби забезпечення консистентності даних під час створення резервних копій. Найчастіше застосовують такі варіанти:
- Монтування файлової системи в режим лише читання (ReadOnly), або заморожування файлової системи (freeze) - метод застосовується обмежено.
- Створення зліпків стану файлової системи або блокового пристрою (LVM, ZFS).
- Застосування сторонніх засобів для організації зліпків, навіть у випадках, коли попередні пункти не можуть бути забезпечені з будь-яких причин (програми виду hotcopy).
- Техніка копіювання при зміні (CopyOnWrite), проте вона найчастіше прив'язана до ФС (BTRFS, ZFS).
Отже, для невеликого сервера необхідно забезпечити схему резервного копіювання, яка відповідає таким вимогам:
- Проста в роботі - не потрібні особливі додаткові дії при роботі, мінімальні дії зі створення та відновлення копій.
- Універсальна працює як на великих, так і на малих серверах; це важливо при зростанні числа серверів або масштабуванні.
- Встановлюється пакетним менеджером, або в одну-дві команди виду «завантажити та розпакувати».
- Стабільна - використовується стандартний або вже давно усталений формат зберігання.
- Швидка у роботі.
Претенденти з тих, хто більш-менш відповідає вимогам:
- rdiff-резервна копія
- rsnapshot
- відрижка
- duplicati
- лукавість
- нехай дуп
- давати
- zbackup
- рестик
- borgbackup
Як тестовий стенд буде застосовуватися віртуальна машина (на базі XenServer) з наступними характеристиками:
- 4 ядра 2.5 ГГц,
- 16 гб оперативної пам'яті,
- 50 гб hybrid storage (СХД із кешуванням на SSD у 20% від розміру віртуального диска) у вигляді окремого віртуального диска без розмітки,
- 200 Мбіт канал в Інтернеті.
Як сервер-приймач резервних копій буде застосовуватися практично така ж машина, тільки з жорстким диском на 500 гб.
Операційна система — Centos 7 x64: стандартна розбивка, додатковий розділ використовуватиметься як джерело даних.
Як вихідні дані візьмемо сайт на wordpress, з медіафайлами розміром 40 гб, базою даних на mysql. Так як віртуальні сервери дуже різняться за характеристиками, а також для кращої відтворюваності, тут є
результати тестування сервера за допомогою sysbench.sysbench -threads=4 -time=30 -cpu-max-prime=20000 cpu run
sysbench 1.1.0-18a9f86 (using bundled LuaJIT 2.1.0-beta3)
Запуск тесту з наступними опціями:
Кількість ниток: 4
Initializing random number generator від поточного часу
Prime numbers limit: 20000
Initializing worker threads…
Нитки розпочато!
Швидкість процесора:
events per second: 836.69
Пропускна здатність:
events/s (eps): 836.6908
time elapsed: 30.0039s
total number of events: 25104
Latency (ms):
хв: 2.38
в середньому: 4.78
максимум: 22.39
95-й процентиль: 10.46
сума: 119923.64
Чесність ниток:
events (avg/stddev): 6276.0000/13.91
execution time (avg/stddev): 29.9809/0.01
sysbench -threads=4 -time=30 -memory-block-size=1K -memory-scope=global-memory-total-size=100G -memory-oper=read memory run
sysbench 1.1.0-18a9f86 (using bundled LuaJIT 2.1.0-beta3)
Запуск тесту з наступними опціями:
Кількість ниток: 4
Initializing random number generator від поточного часу
Running memory speed test with following options:
block size: 1KiB
total size: 102400MiB
operation: read
scope: global
Initializing worker threads…
Нитки розпочато!
Total operations: 50900446 (1696677.10 per second)
49707.47 MiB transferred (1656.91 MiB/sec)
Пропускна здатність:
events/s (eps): 1696677.1017
time elapsed: 30.0001s
total number of events: 50900446
Latency (ms):
хв: 0.00
в середньому: 0.00
максимум: 24.01
95-й процентиль: 0.00
сума: 39106.74
Чесність ниток:
events (avg/stddev): 12725111.5000/137775.15
execution time (avg/stddev): 9.7767/0.10
sysbench —threads=4 —time=30 —memory-block-size=1K —memory-scope=global —memory-total-size=100G —memory-oper=write memory run
sysbench 1.1.0-18a9f86 (using bundled LuaJIT 2.1.0-beta3)
Запуск тесту з наступними опціями:
Кількість ниток: 4
Initializing random number generator від поточного часу
Running memory speed test with following options:
block size: 1KiB
total size: 102400MiB
operation: write
scope: global
Initializing worker threads…
Нитки розпочато!
Total operations: 35910413 (1197008.62 per second)
35068.76 MiB transferred (1168.95 MiB/sec)
Пропускна здатність:
events/s (eps): 1197008.6179
time elapsed: 30.0001s
total number of events: 35910413
Latency (ms):
хв: 0.00
в середньому: 0.00
максимум: 16.90
95-й процентиль: 0.00
сума: 43604.83
Чесність ниток:
events (avg/stddev): 8977603.2500/233905.84
execution time (avg/stddev): 10.9012/0.41
sysbench -threads=4 -file-test-mode=rndrw -time=60 -file-block-size=4K -file-total-size=1G fileio run
sysbench 1.1.0-18a9f86 (using bundled LuaJIT 2.1.0-beta3)
Запуск тесту з наступними опціями:
Кількість ниток: 4
Initializing random number generator від поточного часу
Extra file open flags: (none)
128 files, 8MiB each
1GiB total file size
Block size 4KiB
Number of IO requests: 0
Read/Write ratio для комбінованого random IO test: 1.50
Periodic FSYNC enabled, calling fsync() each 100 requests.
Calling fsync() at the end of test, Enabled.
Using synchronous I/O mode
Doing random r/w test
Initializing worker threads…
Нитки розпочато!
Пропускна здатність:
read: IOPS=3868.21 15.11 MiB/s (15.84 MB/s)
write: IOPS=2578.83 10.07 MiB/s (10.56 MB/s)
fsync: IOPS=8226.98
Latency (ms):
хв: 0.00
в середньому: 0.27
максимум: 18.01
95-й процентиль: 1.08
сума: 238469.45
Цією заміткою починається великий
цикл статей про резервне копіювання
- Резервне копіювання, частина 1: Навіщо потрібне резервне копіювання, огляд методів, технологій
- Резервне копіювання, частина 2: Огляд та тестування rsync-based засобів резервного копіювання
- Резервне копіювання, частина 3: Огляд та тестування duplicity, duplicaty, deja dup
- Резервне копіювання, частина 4: Огляд та тестування zbackup, restic, borgbackup
- Резервне копіювання, частина 5: Тестування bacula та veeam backup for linux
- Резервне копіювання, частина 6: Порівняння засобів резервного копіювання
- Резервне копіювання, частина 7: Висновки
Джерело: habr.com