Ця нотатка завершує цикл резервного копіювання. У ній йтиметься про логічну організацію виділеного сервера (або VPS), зручну для резервного копіювання, а також буде запропоновано варіант швидкого відновлення сервера з резервної копії без особливих простоїв у разі аварії.
Початкові дані
Виділений сервер найчастіше має щонайменше два жорстких диска, службовців в організацію RAID масиву першого рівня (дзеркало). Це потрібно для можливості продовжити роботу сервера, якщо один диск вийшов з ладу. Якщо це звичайний виділений сервер - може бути окремий апаратний RAID-контролер, з активною технологією кешування на SSD, так що на додаток до звичайних жорстких дисків може бути підключений один або більше SSD. Іноді пропонуються виділені сервери, в яких з локальних дисків присутні тільки SATADOM (невеликі диски, конструктивно - флешка, що підключається до порту SATA), а то й звичайна невелика (8-16гб) флешка, що підключається до спеціального внутрішнього порту, а дані беруться з СХ , підключеної по виділеній мережі зберігання даних (Ethernet 10G, FC і т.д.), а бувають виділені сервери, які завантажуються безпосередньо з СХД. Подібні варіанти я не розглядатиму, оскільки в таких випадках завдання резервного копіювання сервера плавно переходить фахівцю, який обслуговує СГД, зазвичай там є різні фірмові технології створення знімків стану, вбудована дедуплікація та інші радості сисадміну, розглянуті в попередніх частинах цього циклу. Об'єм дискового масиву виділеного сервера може досягати кількох десятків терабайт, залежно від числа та обсягу дисків, підключених до сервера. У випадку VPS обсяги скромніші: зазвичай не більше 100гб (але бувають і більше), а тарифи на такі VPS легко можуть бути дорожчими за найдешевші виділені сервери від цього ж хостера. У VPS найчастіше диск один, тому що під ним буде СГД (чи щось гіперконвергентне). Іноді VPS має кілька дисків з різними характеристиками, для різних цілей:
- невеликий системний - для встановлення операційної системи;
- великий - зберігання даних користувача.
При перевстановленні системи засобами панелі керування диск з даними користувача не затирається, а ось системний перезаливається повністю. Також у випадку з VPS хостер може пропонувати кнопку, яка робить знімок стану VPS (або диска), проте якщо встановити свою операційну систему або забути активувати потрібний сервіс всередині VPS - частина даних може бути втрачена. На додаток до кнопки зазвичай пропонується сервіс зберігання даних, найчастіше сильно обмежений. Зазвичай це обліковий запис з доступом протоколу FTP або SFTP, іноді разом з SSH, з урізаним shell (наприклад rbash), або обмеженням на запуск команд через authorized_keys (через ForcedCommand).
Виділений сервер підключений до мережі двома портами зі швидкістю 1Гбітсек, іноді це можуть бути карти зі швидкістю 10Гбітсек. У VPS мережевий інтерфейс найчастіше один. Найчастіше датацентри не обмежують швидкість мережі всередині датацентру, але обмежують швидкість доступу до Інтернету.
Типове навантаження такого виділеного сервера або VPS становить веб-сервер, база даних, сервер додатків. Іноді можуть бути встановлені різні додаткові послуги, у тому числі для веб-сервера або бази даних: пошуковий движок, поштова система і т.д.
Як простір для зберігання резервних копій виступає спеціально підготовлений сервер, про нього докладніше написано далі.
Логічна організація дискової системи
Якщо є RAID-контролер, або це VPS з одним диском, а також немає особливих переваг по роботі дискової підсистеми (наприклад, окремий швидкий диск для бази даних) - весь вільний простір ділиться так: створюється один розділ, поверх нього створюється група томів LVM , у ній створюються кілька томів: 2 невеликих однакового розміру, що використовуються як коренева файлова система (змінюються по черзі при оновленнях для можливості швидкого відкату, ідея підглянута у дистрибутива Calculate Linux), ще один - для розділу підкачки, решта вільного простору ділиться на невеликі томи , що використовуються в якості кореневої файлової системи для повноцінних контейнерів, дисків для віртуальних машин, файлових систем для облікових записів /home (кожного облікового запису - своя файлова система), файлових систем для контейнерів-додатків.
Важливе зауваження: томи би мало бути повністю самодостатніми, тобто. не повинні залежати як одна від одної, так і від кореневої файлової системи. У разі віртуальних машин або контейнерів цей момент дотримується автоматично. Якщо це контейнери додатків або домашні каталоги — варто подумати про поділ конфігураційних файлів веб-сервера та інших сервісів таким чином, щоб максимально прибрати залежності томів між собою. Наприклад, кожен сайт працює від свого користувача, конфігураційні файли сайту - в домашньому каталозі користувача, в налаштуваннях веб-сервера конфігураційні файли сайтів включаються через /etc/nginx/conf.d/.conf, а, наприклад, /home//configs/nginx/*.conf
Якщо ж дисків кілька - можна створити програмний масив RAID (і налаштувати його кешування на SSD, якщо є потреба та можливості), поверх якого зібрати LVM за правилами, запропонованими вище. Також у цьому випадку можна використовувати ZFS або BtrFS, але тут варто кілька разів подумати: обидві вимагають значно серйознішого підходу до ресурсів, до того ж ZFS не йде в комплекті з ядром Linux.
Незалежно від схеми завжди заздалегідь варто прикинути приблизну швидкість запису змін на диски, після чого обчислити розмір вільного місця, яке буде зарезервовано для створення знімків. Наприклад, якщо наш сервер писатиме дані зі швидкістю 10 мегабайт на секунду, а розмір всього масиву з даними становить 10 терабайт - час синхронізації може досягати доби (22 години - стільки буде передаватися такий обсяг по мережі 1гбітсек) - варто зарезервувати близько 800 гб . Насправді цифра буде меншою, можна сміливо розділити її на число логічних томів.
Влаштування сервера зберігання резервних копій
Головна відмінність сервера для зберігання резервних копій – великі, дешеві та відносно повільні диски. Оскільки сучасні HDD вже переступили планку в 10тб в одному диску - обов'язково застосування файлових систем або RAID з контрольними сумами, тому що за час перебудови масиву або відновлення файлової системи (кілька діб!) може вийти з ладу другий диск через підвищене навантаження. На дисках ємністю до 1тб це було негаразд чутливо. Для простоти опису припускаю, що дисковий простір розділений на дві приблизно однакові за розміром частини (знову ж, наприклад, за допомогою LVM):
- томи, що відповідають на серверах, що використовуються для зберігання даних (на них буде розгортатися остання зроблена резервна копія для перевірки);
- томи, які використовуються як репозиторії BorgBackup (сюди безпосередньо потраплятимуть дані для резервних копій).
Принцип роботи у тому, що створюються окремі томи кожного сервера під репозиторії BorgBackup, куди й потраплятимуть дані з бойових серверів. Репозиторії працюють у режимі лише додавання, що виключає можливість навмисного видалення даних, а за рахунок дедуплікації та періодичного чищення репозиторіїв від старих резервних копій (залишаються річні копії, щомісячні за останній рік, щотижневі за останній місяць, щоденні за останній тиждень, можливо – в особливих випадках – щогодини за останній день: разом 24 + 7 + 4 + 12 + річні – приблизно 50 копій для кожного сервера).
У репозиторіях BorgBackup не активується режим лише додавання, натомість використовується ForcedCommand в .ssh/authorized_keys приблизно такого плану:
from="адрес сервера",command="/usr/local/bin/borg serve --append-only --restrict-to-path /home/servername/borgbackup/",no-pty,no-agent-forwarding,no-port-forwarding,no-X11-forwarding,no-user-rc AAAAA.......По вказаному шляху розміщено скрипт-обертку поверх borg, який, крім запуску бінарника з параметрами, додатково запускає процес відновлення резервної копії після закінчення зняття даних. Для цього скрипт-обгортка створює файл-ознаку поруч із відповідним репозиторієм. Остання зроблена резервна копія після закінчення процесу заливки даних автоматично відновлюється на відповідний логічний том.
Дана конструкція дозволяє періодично чистити непотрібні резервні копії, а також не дозволяє бойовим серверам видаляти на сервері зберігання резервних копій.
Процес резервного копіювання
Ініціатором резервного копіювання виступає сам виділений сервер або VPS, оскільки така схема дає більший контроль над процесом резервного копіювання з боку цього сервера. Насамперед робиться знімок стану активної кореневої файлової системи, який монтується та закачується за допомогою BorgBackup на сервер зберігання резервних копій. Після закінчення зняття даних знімок розмонтується та видаляється.
У разі наявності невеликої бази даних (до 1 гб для кожного сайту) робиться дамп бази даних, який зберігається у відповідний логічний том, туди, де розташовані інші дані цього сайту, але так, щоб дамп не був доступний через веб-сервер. Якщо ж бази великі — слід налаштувати «гаряче» зняття даних, наприклад за допомогою xtrabackup для MySQL, або WAL c archive_command в PostgreSQL. У цьому випадку база даних відновлюватиметься окремо від даних сайтів.
Якщо використовуються контейнери або віртуальні машини, слід налаштувати qemu-guest-agent, CRIU або інші потрібні технології. В інших випадках додаткових налаштувань найчастіше не знадобиться — просто створюємо знімки логічних томів, які потім обробляються аналогічно до знімку стану кореневої файлової системи. Після зняття даних знімки видаляються.
Подальша робота йде на сервері зберігання резервних копій:
- перевіряється остання зроблена резервна копія в кожному репозиторії,
- перевіряється наявність файлу-мітки, що вказує, що процес зняття даних завершено,
- виконується розгортання даних на відповідний локальний том,
- видаляється файл-мітка
Процес відновлення працездатності сервера
Якщо основний сервер гине, запускається аналогічний виділений сервер, який завантажується з деякого стандартного образу. Найімовірніше завантаження буде відбуватися по мережі, однак технік ЦОД, що виконує налаштування сервера, може відразу скопіювати цей стандартний образ на один із дисків. Завантаження відбувається в оперативну пам'ять, після чого запускається процес відновлення:
- виконується запит на приєднання блокового пристрою за iscsinbd або іншим схожим протоколом логічного тома, що містить кореневу файлову систему загиблого сервера; оскільки коренева файлова система має бути невеликою - цей етап повинен бути завершений за кілька хвилин. Також провадиться відновлення завантажувача;
- відтворюється структура локальних логічних томів, приєднуються логічні томи з сервера резервного копіювання за допомогою модуля ядра dm_clone: починається відновлення даних, а зміни записуються відразу на локальні диски
- запускається контейнер із усіма доступними фізичними дисками - повністю відновлюється працездатність сервера, але зі зниженою продуктивністю;
- після закінчення синхронізації даних логічні томи з сервера резервного копіювання від'єднуються, контейнер вимикається, сервер перезавантажується;
Після перезавантаження сервер буде мати всі дані, які були на момент створення резервної копії, а також включати всі зміни, які були зроблені в процесі відновлення.
Інші статті циклу
Резервне копіювання, частина 7: Висновки
Запрошую обговорити запропонований варіант у коментарях, дякую за увагу!
Джерело: habr.com