Как GitLab ви помага да архивирате големи хранилища в NextCloud

Хей Хабр!

Днес искам да говоря за нашия опит в автоматизирането на архивирането на големи данни от хранилищата на Nextcloud в различни конфигурации. Работя като сервиз в Молния АК, където правим управление на конфигурацията на ИТ системи, Nextcloud се използва за съхранение на данни. Включително с разпределена структура, с резервиране.

Проблемите, произтичащи от характеристиките на инсталациите, са, че има много данни. Версионирането, предоставено от Nextcloud, излишъкът, субективните причини и много други създават много дубликати.

праистория

При администрирането на Nextcloud възниква проблемът с организирането на ефективен бекъп, който трябва да бъде криптиран, тъй като данните са ценни.

Предлагаме опции за съхранение на резервни копия у нас или при клиента на отделни машини от Nextcloud, което изисква гъвкав автоматизиран подход при администриране.

Има много клиенти, всички с различни конфигурации и всички на собствени сайтове и със собствени характеристики. Това е стандартна техника, когато целият сайт принадлежи на вас и архивите се правят от корони; не пасва добре.

Първо, нека да разгледаме входните данни. Имаме нужда от:

• Мащабируемост по отношение на един възел или няколко. За големи инсталации използваме minio като хранилище.
• Научете за проблеми с извършването на архивиране.
• Трябва да поддържате резервно копие с вашите клиенти и/или с нас.
• Справете се с проблемите бързо и лесно.
• Клиентите и инсталациите са много различни един от друг - не може да се постигне еднаквост.
• Скоростта на възстановяване трябва да бъде минимална при два сценария: пълно възстановяване (катастрофа), една папка е изтрита по погрешка.
• Необходима е функция за дедупликация.

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

Разбира се, ние не сме първите, които решават подобен проблем, но ни се струва, че нашият практически, трудно натрупан опит може да бъде интересен и сме готови да го споделим.

Тъй като нашата компания има политика с отворен код, ние търсихме решение с отворен код. Ние на свой ред споделяме нашите разработки и ги публикуваме. Например в GitHub има нашия плъгин за Nextcloud, които предоставяме на клиентите, като повишаваме сигурността на данните в случай на случайно или умишлено изтриване.

Инструменти за архивиране

Започнахме търсенето на методи за решение, като избрахме инструмент за създаване на резервно копие.

Обикновеният tar + gzip не работи добре - данните се дублират. Едно увеличение често съдържа много малко действителни промени и голяма част от данните в рамките на един файл се повтарят.
Има и друг проблем - излишък на разпределено съхранение на данни. Ние използваме minio и неговите данни са основно излишни. Или трябваше да направите резервно копие през самия minio - да го заредите и да използвате всички разделители между файловата система и, не по-малко важно, има риск да забравите някои от кофите и мета-информацията. Или използвайте дедупликация.

Инструментите за архивиране с дублиране са налични в отворен код (на Habré имаше статии по тази тема) и нашите финалисти бяха Борг и Рестик. Нашето сравнение на двете приложения е по-долу, но засега ще ви кажем как сме организирали цялата схема.

Управление на резервни копия

Borg и Restic са добри, но нито един продукт няма централизиран контролен механизъм. За целите на управлението и контрола избрахме инструмент, който вече имаме внедрен, без който не можем да си представим нашата работа, включително автоматизация - това е добре познатият CI/CD - GitLab.

Идеята е следната: gitlab-runner се инсталира на всеки възел, съхраняващ данни от Nextcloud. Изпълнителят изпълнява скрипт по график, който следи процеса на архивиране и стартира Borg или Restic.

Какво получихме? Обратна връзка от изпълнението, удобен контрол върху промените, подробности в случай на грешка.

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

Все още няма начин да промените времето за изчакване на CI/CD в API на Gitlab, но е малко. Трябва да се увеличи, да речем 1d.

GitLab, за щастие, може да стартира не само според ангажимент, но само според график, точно това ни трябва.

Сега относно скрипта за обвивка.

Задаваме следните условия за този скрипт:

• Трябва да се стартира както от бегача, така и ръчно от конзолата със същата функционалност.
• Трябва да има манипулатори на грешки:
• код за връщане.
• търсене на низ в дневника. Например, за нас грешка може да бъде съобщение, което програмата не счита за фатално.
• Изчакване на обработката. Времето за изпълнение трябва да е разумно.
• Имаме нужда от много подробен дневник. Но само в случай на грешка.
• Извършват се и редица тестове преди стартиране.
• Малки бонуси за удобство, които намерихме за полезни по време на процеса на поддръжка:
• Началото и краят се записват в syslog на локалната машина. Това помага за свързване на системни грешки и операция за архивиране.
• Част от регистъра на грешките, ако има такъв, се извежда в stdout, целият регистър се записва в отделен файл. Удобно е веднага да погледнете CI и да оцените грешката, ако е тривиална.
• Режими за отстраняване на грешки.

Пълният дневник се запазва като артефакт в GitLab; ако няма грешка, дневникът се изтрива. Ние пишем скрипта в bash.

Ще се радваме да разгледаме всички предложения и коментари относно отворен код - добре дошли.

Как работи

Изпълнител с Bash изпълнител се стартира на резервния възел. Според планировчика заданието CI/CD се стартира в специална ряпа. Runner стартира универсален скрипт за обвивка за такива задачи, той проверява валидността на резервното хранилище, точките за монтиране и всичко, което искаме, след което архивира и изчиства старото. Самото готово архивиране се изпраща до S3.

Ние работим по тази схема - това е външен доставчик на AWS или руски еквивалент (по-бързо е и данните не напускат Руската федерация). Или инсталираме отделен мини клъстер за клиента на неговия сайт за тези цели. Обикновено правим това от съображения за сигурност, когато клиентът изобщо не иска данните да напуснат неговата верига.

Не използвахме функцията за изпращане на резервно копие чрез ssh. Това не добавя сигурност и мрежовите възможности на доставчика на S3 са много по-високи от нашата една ssh машина.

За да защитите вашата локална машина от хакер, тъй като той може да изтрие данни на S3, трябва да активирате версията.
Резервното копие винаги криптира архива.

Borg има некриптиран режим none, но силно не препоръчваме да го включвате. В този режим не само няма да има криптиране, но и контролната сума на това, което се записва, не се изчислява, което означава, че целостта може да бъде проверена само индиректно, с помощта на индекси.

Отделен планировчик проверява резервните копия за целостта на индексите и съдържанието. Проверката е бавна и дълга, затова я провеждаме отделно веднъж месечно. Може да отнеме няколко дни.

Readme на руски

Основни функции

• prepare обучение
• testcheck проверка на готовността
• maincommand основен екип
• forcepostscript функция, която се изпълнява накрая или по грешка. Използваме го, за да демонтираме дяла.

Сервизни функции

• cleanup Ние записваме грешки или изтриваме лог файла.
• checklog анализирайте дневника за появата на ред с грешка.
• ret манипулатор за изход.
• checktimeout проверете за таймаут.

Заобикаляща среда

• VERBOSE=1 Ние показваме грешките на екрана веднага (stdout).
• SAVELOGSONSUCCES=1 запишете дневника при успех.
• INIT_REPO_IF_NOT_EXIST=1 Създайте хранилище, ако не съществува. Деактивирано по подразбиране.
• TIMEOUT максимално време за основната операция. Можете да го зададете като "m", "h" или "d" в края.

Режим за съхранение на стари копия. По подразбиране:

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

Променливи в скрипта

• ERROR_STRING — низ за регистъра за регистрация за грешка.
• EXTRACT_ERROR_STRING — израз за показване на низ при грешка.
• KILL_TIMEOUT_SIGNAL — сигнал за убиване при изчакване.
• TAIL — колко низове с грешки на екрана.
• COLORMSG — цвят на съобщението (жълто по подразбиране).

Този скрипт, който се нарича wordpress, има условно име, трикът му е, че архивира и базата данни mysql. Това означава, че може да се използва за инсталации на Nexcloud с един възел, където можете също да архивирате базата данни. Удобството е не само, че всичко е на едно място, но и съдържанието на базата данни е близко до съдържанието на файловете, тъй като времевата разлика е минимална.

Рестич срещу Борг

Има и сравнения между Борг и Рестич тук на Хабре, и нямахме задачата да направим още един, а наш собствен. За нас беше важно как ще изглежда на нашите данни, с нашите специфики. Ние ги носим.

Нашите критерии за подбор, в допълнение към вече споменатите (дедупликация, бързо възстановяване и т.н.):

• Съпротива срещу недовършена работа. Проверка за убийство -9.
• Размер на диска.
• Изискване за ресурси (CPU, памет).
• Размер на съхранените петна.
• Работа с S3.
• Проверка на целостта.

За тестване взехме един клиент с реални данни и общ размер от 1,6 TB.
Условия.

Borg не знае как да работи директно със S3, а ние монтирахме диска като предпазител, през шантаво. Restic го изпрати на самия S3.

Goofys работи много бързо и добре и има такива дисков кеш модул, което още повече ускорява работата. Той е в бета етап и, честно казано, се сринахме със загуба на данни по време на тестове (други). Но удобството е, че самата процедура за архивиране не изисква много четене, а предимно писане, така че използваме кеша само по време на проверки на целостта.

За да намалим влиянието на мрежата, използвахме местен доставчик - Yandex Cloud.

Резултати от сравнителни тестове.

• Убий -9 с допълнителен рестарт и двете бяха успешни.
• Размер на диска. Borg може да компресира, така че резултатите са очакваните.

Backuper
размер

Борг
562Gb

Рестик
628Gb

• Чрез процесора
  Самият Borg консумира малко, с компресия по подразбиране, но трябва да се оцени заедно с goofys процеса. Като цяло те са сравними и използват около 1,2 ядра на една и съща тестова виртуална машина.
• памет. Restic е приблизително 0,5 GB, Borg е приблизително 200 MB. Но всичко това е незначително в сравнение със системния файлов кеш. Затова е препоръчително да разпределите повече памет.
• Разликата в размера на петната беше поразителна.

Backuper
размер

Борг
около 500MB

Рестик
около 5MB

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

Основното е, че Borg може да компресира и има по-големи петна - което прави операциите за съхранение и GET/PUT в S3 по-евтини. Но това става с цената на по-сложна и по-бавна проверка. Що се отнася до скоростта на възстановяване, не забелязахме никаква разлика. Restic отнема последващи архиви (след първото) малко по-дълго, но не значително.

Не на последно място при избора беше големината на общността.

И избрахме Борг.

Няколко думи за компресията

Borg има отличен нов алгоритъм за компресиране в своя арсенал - zstd. Качеството на компресия не е по-лошо от gzip, но много по-бързо. И сравнима по скорост с lz4 по подразбиране.

Например дъмп на MySQL база данни се компресира два пъти по-добре от lz4 при същата скорост. Опитът с реални данни обаче показва, че има много малка разлика в съотношението на компресия на възела Nextcloud.

Borg има доста бонус режим на компресия - ако файлът има висока ентропия, тогава компресията изобщо не се прилага, което увеличава скоростта. Активирано от опция при създаване
-C auto,zstd
за алгоритъма zstd
Така че с тази опция, в сравнение с компресията по подразбиране, имаме
560Gb и 562Gb съответно. Данните от примера по-горе, напомням, без компресия резултатът е 628Gb. Резултатът от 2GB разлика донякъде ни изненада, но решихме, че все пак ще го изберем. 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 и не всеки има антивирусна програма. Провеждането на проверки по време на наливане отнема твърде много време и пречи на бизнеса.

Мащабируемостта се постига чрез стартиране на бегачи на различни възли с различни тагове.
Нашият мониторинг събира резервни статуси чрез GitLab API в един прозорец; ако е необходимо, проблемите се забелязват лесно и също толкова лесно се локализират.

Заключение

В резултат на това знаем със сигурност, че правим резервни копия, че нашите архиви са валидни, проблемите, които възникват с тях, отнемат малко време и се решават на ниво дежурен администратор. Архивирането заема много малко място в сравнение с tar.gz или Bacula.

Източник: www.habr.com