Як GitLab допомагає робити бекапи великих сховищ NextCloud

Привіт, Хабре!

Сьогодні я хочу розповісти про наш досвід автоматизації резервного копіювання великих даних сховищ Nextcloud у різних конфігураціях. Я працюю СТО в "Блискавка АК", де ми займаємося конфігураційним управлінням IT систем, для зберігання даних використовується Nextcloud. У тому числі з розподіленою структурою, з резервуванням.

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

Передісторія

При адмініструванні Nextcloud гостро постає проблема організації ефективного бекапу, який потрібно обов'язково шифрувати, оскільки дані цінні.

Ми пропонуємо варіанти зберігання бекапу у нас чи у замовника на його окремих від Nextcloud машинах, що потребує гнучкого автоматизованого підходу до адміністрування.

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

Для початку подивимося на вступні дані. Нам потрібно:

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

Для вирішення завдання керування бекапами ми прикрутили GitLab. Докладніше підкатом.

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

Оскільки в нашій компанії прийнято політику Opensource, рішення ми шукали саме з відкритим вихідним кодом. У свою чергу ми ділимося своїми розробками та викладаємо їх. Наприклад, на GitHub є наш плагін для Nextcloud, який ми ставимо клієнтам, що посилює збереження даних у разі випадкового чи навмисного видалення.

Засоби бекапірування

Пошук методів рішення ми розпочали з вибору засобу створення бекапу.

Звичайний tar + gzip працює погано – дані дублюються. Інкремент часто містить дуже мало змін за фактом, і більшість даних всередині одного файлу повторюється.
Є ще одна проблема – надмірність розподіленого сховища даних. Ми використовуємо minio та його дані в принципі надмірні. Або потрібно було бекап робити через сам minio - навантажувати його і користуватися всіма прокладками між файловою системою, і що не менш важливо, є ризик забути про частину бакетів та мета-інформації. Або використовувати дедуплікацію.

Засоби бекапірування з дудплікацією є в опенсорсі (на хабрі були статті на цю тему) та нашими фіналістами стали Borg и Рестик. Про наше порівняння двох додатків нижче, а поки що розповімо як ми організували всю схему.

Управління створенням резервних копій

Borg і Restic хороші, але жоден жоден продукт не має централізованого механізму управління. Для мети управління та контролю ми вибрали інструмент, який і так у нас впроваджений, без якого ми не мислимо свою роботу, в тому числі з автоматизації – це відомий CI/CD – GitLab.

Ідея полягає в наступному: на кожну ноду Nextcloud, що зберігає дані, ставиться gitlab-runner. Раннер запускає за розкладом скрипт, що стежить за процесом бекапірування, і той запускає Borg або Restic.

Що ми здобули? Зворотній зв'язок від виконання, зручний контроль за змінами, подробиці у разі помилки.

Ось тут на GitHub ми виклали приклади скрипта для різних завдань, а ми його в підсумку прикрутили до бекапу не тільки Nextcloud, а й багатьох інших сервісів. Там же лежить планувальник, якщо не хоче руками його налаштовувати (а нам не хоче) і .gitlab-ci.yml

У API гітлабу поки немає можливості змінювати тайм-аут CI/CD, а він там невеликий. Його треба збільшити, скажімо до 1d.

GitLab на щастя вміє запускати не тільки за комітом, але тільки за розкладом, це те, що нам треба.

Тепер про скриття-обертку.

Ми поставили такі умови для цього скрипту:

• Повинен запускатись як раннером, так і руками з консолі з однаковим функціоналом.
• Обов'язково мають бути обробники помилок:
• код повернення.
• пошук рядка у лозі. Наприклад, для нас помилкою може бути повідомлення, яке програма фатальної не вважає.
• Обробка timeout. Час виконання має бути розумним.
• Нам потрібен найдокладніший лог. Але лише у разі помилки.
• Також проводиться ряд тестів перед початком.
• Невеликі плюшки для зручності, які ми знайшли корисними у процесі підтримки:
• Запуск та закінчення фіксується у сислозі локальної машини. Це допомагає пов'язати системні помилки та роботу бекапу.
• Частина лога помилок, коли вони є, видається в stdout, весь лог пишеться окремий файл. Зручно відразу глянути в CI і оцінити помилку, якщо вона тривіальна.
• Режими для дебага.

Повний лог зберігається у вигляді артефакту GitLab, якщо помилки немає, то лог видаляється. Скрипт пишемо на bash.

Будь-які пропозиції та зауваження щодо опенсорсу будемо раді розглянути – welcome.

Як це працює

На ноді, що бекапується, запускається раннер з башевським екзек'ютером. За планувальником у спеціальній ріпі запускається job CI/CD. Раннер запускає скрипт універсальну обгортку для таких завдань, в ньому проходять перевірки валідності репозиторію бекапу, точок монтування і всього, що захочемо, потім виконується бекапірування та очищення старого. Сам готовий бекап вирушає на S3.

Ми працюємо за такою схемою - це зовнішній провайдер AWS або російський аналог (це швидше і дані не залишають РФ). Або клієнту ставимо окремий мініо кластер на його майданчику для цих цілей. Зазвичай так робимо з міркувань безпеки, коли клієнт зовсім не хоче, щоб дані залишали їх контур.

Використовувати фічу відправки бекапу по ssh ми не стали. Безпеки це не додає, а мережеві можливості провайдера S3 сильно вищі за одну нашу ssh машину.

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

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

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

Рідмі російською

Основні функції

• prepare підготовка
• testcheck перевірка готовності
• maincommand основна команда
• forcepostscript функція яка виконується в кінці або помилково. Використовуємо, щоб відмонтувати розділ.

Сервісні функції

• cleanup записуємо помилки або стираємо лог файл.
• checklog Парсим лог на входження рядка з помилкою.
• ret exit handler.
• checktimeout перевірка на таймаут.

Навколишнє середовище

• VERBOSE=1 виводимо помилки на екран одразу (stdout).
• SAVELOGSONSUCCES=1 зберігаємо балку при успіху.
• INIT_REPO_IF_NOT_EXIST=1 Створюємо репозиторій, якщо не було. За замовчуванням вимкнено.
• TIMEOUT максимальний верм'я на основну операцію. Ви можете встановити це як 'm', 'h' або 'd' at the end.

Режим зберігання старих копій. За замовчуванням:

• KEEP_DAILY=7
• KEEP_WEEKLY=4
• KEEP_MONTHLY=6

Змінні усередині скрипту

• ERROR_STRING — string for check in log for error.
• EXTRACT_ERROR_STRING - expression for show string if error.
• KILL_TIMEOUT_SIGNAL - Signal for killing if timeout.
• TAIL — how many strings with errors on screen.
• COLORMSG - Color of mesage (default yellow).

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

Restic vs Borg

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

Наші критерії вибору, крім згадуваних (дедуплікація, швидке відновлення тощо):

• Стійкість до незавершеної роботи. Перевірка на kill-9.
• Розмір на диску.
• Вимоги до ресурсів (ЦПУ, пам'ять).
• Розмір блобів, що зберігаються.
• Робота з S3.
• Перевірка цілісності.

Для тестування ми взяли одного клієнта з реальними даними та загальним розміром 1,6 Тб.
Умови.

Borg не вміє безпосередньо працювати з S3, та ми монтували як fuse диск, через goofys. Restic відправляв до S3 сам.

Goofys працює дуже швидко та добре, і до нього є модуль дискового кешущо ще більше прискорює роботу. Він знаходиться на стадії beta, і, зізнатися, у нас падав із втратою даних на тестах (інших). Але зручність у тому, що сама процедура бекапу не вимагає великого читання, а в основному запису, тому кеш ми використовуємо тільки під час перевірки цілісності.

Щоб знизити вплив мережі, використали місцевого провайдера – Яндекс Хмара.

Результати тестування порівняння.

• Kill -9 з подальшим перезапуском обидва пройшли успішно.
• Розмір на диску. Borg вміє стискати, тому результати очікувані.

Резервне копіювання
Розмір

Borg
562Gb

Рестик
628Gb

• По CPU
  Сам по собі borg витрачає мало, з дефолтним стиском, але оцінювати треба разом із процесом goofys. У сумі вони можна порівняти і утилізують близько 1,2 ядра на одній і тій же тестовій віртуалці.
• Пам'ять. Restic приблизно 0,5 Гб, Borg близько 200 Мб. Але це все трохи порівняно з файловим кешем системи. Тому пам'яті бажано виділяти побільше.
• Різниця у розмірі блобів виявилася разючою.

Резервне копіювання
Розмір

Borg
близько 500Мб

Рестик
близько 5Мб

• Робота з S3 від Restic відмінна. Робота Borg через goofys питань не викликає, але помічено, що бажано після закінчення бекапу робити umount щоб повністю скинути кеш. Особливість роботи S3 у тому, що недокачані чанки ніколи не будуть відправлені в бакет, а отже, не повністю залиті дані призводять до великих пошкоджень.
• Перевірка цілісності працює добре в обох випадках, але швидкість значно відрізняється.
  Restic - 3,5 години.
  Borg, з файловим кешем у 100Гб SSD – 5 годин.Приблизно такий самий результат за швидкістю якщо дані лежать на локальному диску.
  Borg читає прямо з S3 без кешу 33 години. Жахливо довго.

У сухому залишку Borg вміє стискати і має великі блоби — що робить дешевшим зберігання та операції GET/PUT у S3. Але за це доводиться платити складнішою та повільнішою перевіркою. Щодо швидкості відновлення — то ми різниці не помітили. Наступні бекапи (після першого) restic робить трохи довше, але не суттєво.

Не на останньому місці у виборі стояв розмір ком'юніті.

І ми вибрали borg.

Пару слів про стиснення

Borg'а має в арсеналі прекрасний новий алгоритм стиснення — zstd. За якістю стиснення не гірше за gzip, але значно швидше. І порівняємо за швидкістю з дефотним lz4.

Наприклад дамп MySQL бази стискається в два рази краще lz4 при тій же швидкості. Однак, досвід реальних даних показує, що дуже невелику різницю в ступеня стиснення ноди Nextcloud .

У Borg є досить бонусний режим стиснення - якщо файл має велику ентропію, то стиснення взагалі не застосовується, що збільшує швидкість роботи. Вмикається опцією під час створення
-C auto,zstd
для алгоритму zstd
Так ось з цією опцією в порівнянні зі стисненням за замовчуванням ми отримали
560Gb та 562Gb відповідно. Дані з прикладу вище, нагадаю, без стиснення результату 628Gb. Результат у 2Гб різниці трохи нас здивував, але ми порахували що виберемо все-таки auto,zstd.

Методика перевірки бекапу

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

goofys --cache "--free:5%:/mnt/cache" -o allow_other --endpoint https://storage.yandexcloud.net --file-mode=0666 --dir-mode=0777 xxxxxxx.com /mnt/goofys
export BORG_PASSCOMMAND="cat /home/borg/.borg-passphrase"
borg list /mnt/goofys/borg1/
borg check --debug -p --verify-data /mnt/goofys/borg1/

За цією ж схемою ми перевіряємо файли антивірусом (постфактум). Адже користувачі заливають різне в Nextcloud і не всі мають антивірус. Проводити перевірку в момент заливки займає надто багато часу і заважає бізнесу.

Масштабованість досягається запуском раннерів на різних нодах із різними тегами.
У моніторингу збираються статуси бекапів через API GitLab в одному вікні, при необхідності проблеми легко помічаються, і так само легко локалізуються.

Висновок

Як підсумок ми точно знаємо, що бекапи ми робимо, що наші бекапи валідні, проблеми, які з ними виникають, займають мало часу і вирішуються на рівні чергового адміністратора. Бекапи займають мало місця в порівнянні з tar.gz або Bacula.

Джерело: habr.com