GitLab backup може да успее, а registry и клучевите сепак да недостигаат

Успешно завршена команда за резервна копија не гарантира дека може да се врати цела self-managed инсталација на GitLab. Документацијата на GitLab за резервни копии наведува дека конфигурациските датотеки, Redis и податоците од Container Registry во object storage остануваат надвор од основниот архив. За да се вратат и registry сликите и шифрираните вредности, зачувајте ги соодветното складиште и тајните одделно.

Проверлива копија затоа е поврзан сет: архив, конфигурација, потребни објекти и, ако е активна, база за registry метаподатоци. Запишете кога и како е создаден секој дел, па вратете го сетот во одвоена инсталација. Успешниот излез од командата потврдува дека таа ја завршила својата задача; пробното враќање покажува дали сите делови работат заедно.

Направете manifest според местото на чување

Попишете ги податоците на конкретната инсталација пред да ја закажете копијата. Во manifest внесете ги главната PostgreSQL база, Git репозиториумите, LFS објектите, артефактите, прикачените датотеки, пакетите и Container Registry. За секоја ставка запишете ја вистинската локација: локален датотечен систем или одреден bucket во object storage. Истата функција на GitLab може да бара различна постапка за копирање во различни инсталации.

Потоа додадете ги конфигурацијата и тајните, активниот начин на чување на registry метаподатоците, верзијата на GitLab и типот CE или EE. Ако registry користи база за метаподатоци, внесете ја како посебна ставка дури и кога е сместена на истиот PostgreSQL сервер. На секоја копија доделете идентификатор, време на почеток и крај, локација и постапка за враќање. Така ќе знаете кои снимки припаѓаат на истиот сет, наместо да ги спојувате според слични имиња на датотеки.

Во manifest означете и што намерно е прескокнато при создавањето на архивот. Параметар што исклучува база, репозиториуми или registry има оперативна смисла само ако постои друга копија од тие податоци. За bucket-ите запишете ја снимката или верзионираниот инвентар што ќе се користи при враќање; само името на bucket-от не кажува која состојба била зачувана.

Архивот и конфигурациските тајни се два дела

Кај инсталација со Linux пакет, извршете gitlab-backup create и потврдете дека е создаден очекуваниот архив. Одделно зачувајте ги /etc/gitlab/gitlab-secrets.json и /etc/gitlab/gitlab.rb. Кај Docker зачувајте го конфигурацискиот волумен, а кај Helm и тајните потребни за повторно поставување на инсталацијата. Копијата од тајните чувајте ја со ограничен пристап и поврзете ја во manifest со соодветниот архив.

GitLab ја користи датотеката со тајни за дешифрирање вредности во базата, меѓу нив и CI/CD променливи. Архив со исправна база, но без соодветните клучеви, може да се врати без апликацијата да може да ги прочита тие вредности. Зачувајте и сертификати или SSH клучеви што ѝ се потребни на вашата конфигурација; за нив наведете одделна локација и начин на враќање.

Redis бара посебна одлука. GitLab во него чува и задачи на Sidekiq, а основната команда не ги копира. За усогласена копија организирајте период без задачи што чекаат или се извршуваат; ако мора да ја зачувате и нивната состојба, вклучете посебна постапка за Redis и проверете ја при пробното враќање. Не означувајте го сетот како целосен само затоа што архивот успешно се создал.

Поврзете ги registry објектите со метаподатоците

Прво утврдете каде Container Registry ги чува сликите. Кога се на локален датотечен систем, стандардната копија може да ги вклучи; кога се во object storage, направете посебна копија од складиштето. Базата за registry метаподатоци, ако е активна, го опишува каталогот, но не ги заменува објектите со содржината на сликите.

Документацијата за registry метаподатоци бара активната база и складиштето да се копираат што е можно поблиску во време; од GitLab 18.10, алатките автоматски ја вклучуваат конфигурираната база за метаподатоци. Проверете дека пристапот до базата е поставен и дека таа навистина е присутна во добиената копија. Ако вашата постапка не ја вклучува автоматски, зачувајте ја одделно со PostgreSQL алатки.

Во manifest спарете ги идентификаторите и времињата на архивот, снимката од registry складиштето и копијата од базата за метаподатоци. Ако меѓу тие операции се додаваат слики или се бришат ознаки, каталогот и зачуваните објекти може да претставуваат различни состојби. Краток период без запишување го олеснува усогласувањето; ако тоа не е изводливо, запишете го временското растојание и проверете ги конкретните слики по враќањето.

Кај Helm проверете ги пристапите на Toolbox

Кај Helm инсталација, backup-utility работи преку Toolbox. Упатството за GitLab Helm опишува пристап до object storage, bucket за резервната копија, привремен bucket за враќање и акредитиви за registry базата. Затоа проверете ги пристапите што ѝ се потребни на алатката за целата операција, а не само дали се појавил архив во backup bucket-от.

Ако е активна базата за registry метаподатоци, Toolbox треба да има соодветни корисници и акредитиви за копирање и враќање. Во manifest внесете ги Helm вредностите и Kubernetes тајните што ја одредуваат таа врска, со заштитена копија од чувствителните вредности. При пробата проверете ги логовите и содржината на копијата: постоењето на архив само по себе не покажува дека registry базата била опфатена.

Потврдете го сетот со пробно враќање

Подгответе одвоена, празна GitLab инсталација со точно истата верзија и тип CE или EE како изворот. Вратете ги конфигурацијата и тајните, главниот архив и соодветните снимки од object storage. Ако registry користи база за метаподатоци, вратете ја копијата спарена со истото складиште. Пробната инсталација држете ја одвоена од продукциските клиенти додека траат проверките.

1. Пресметајте hash за архивот и за заштитените конфигурациски копии при создавање. Споредете ги вредностите по преносот и пред враќањето. За object storage зачувајте инвентар со идентификаторите на објектите или нивните верзии што ѝ припаѓаат на снимката.
2. Отворете избрани репозиториуми и проверете поврзани LFS објекти, артефакти и прикачени датотеки. За Container Registry проверете позната слика и ознака и преземете ја содржината на сликата; приказот на ознаката сам по себе не докажува дека слоевите се достапни.
3. Во контролирана проба проверете функција што користи шифрирана вредност, на пример постојна CI/CD променлива. Забележете го исходот без да ја внесувате тајната во записникот.

Зачувајте го записникот заедно со manifest: употребени идентификатори, времиња на снимките, hash вредности и исход за секоја проверка. Ако registry прикажува слика што не може да се преземе или шифрирана вредност не може да се прочита, поправете го недостасувачкиот дел и повторете го враќањето. Дури тогаш сетот има проверена постапка за употреба при прекин.

Прочитајте и:

• PDF може да изгледа чист, а сепак да носи скриени лични податоци
• GitHub backup без лажна сигурност: mirror clone не ги зачувува сите податоци
• WhatsApp ги брише пораките, но backup-от бара посебно шифрирање