🥇Com us ajuda GitLab a fer còpies de seguretat d'emmagatzematges grans de NextCloud

Hola Habr!

Avui vull parlar de la nostra experiència en l'automatització de la còpia de seguretat de big data des d'emmagatzematge Nextcloud en diferents configuracions. Treballo com a estació de servei a Molniya AK, on fem la gestió de la configuració dels sistemes informàtics, s'utilitza Nextcloud per a l'emmagatzematge de dades. Incloent, amb una estructura distribuïda, amb redundància.

Els problemes derivats de les característiques de les instal·lacions són que hi ha moltes dades. El control de versions proporcionat per Nextcloud, la redundància, els motius subjectius i molt més crea molts duplicats.

prehistòria

En administrar Nextcloud sorgeix el problema d'organitzar una còpia de seguretat efectiva, que s'ha de xifrar, ja que les dades són valuoses.

Oferim opcions per emmagatzemar còpies de seguretat al nostre lloc o al client en màquines separades de Nextcloud, cosa que requereix un enfocament automatitzat flexible de l'administració.

Hi ha molts clients, tots amb configuracions diferents, i tots en els seus propis llocs i amb les seves pròpies característiques. Aquesta és una tècnica estàndard quan tot el lloc us pertany i les còpies de seguretat es fan amb corones, no encaixa bé.

Primer, mirem les dades d'entrada. Necessitem:

Escalabilitat en termes d'un o diversos nodes. Per a grans instal·lacions utilitzem minio com a emmagatzematge.
Esbrineu els problemes relacionats amb la realització de còpies de seguretat.
Necessites mantenir una còpia de seguretat amb els teus clients i/o amb nosaltres.
Fer front als problemes de manera ràpida i senzilla.
Els clients i les instal·lacions són molt diferents entre si, no es pot aconseguir la uniformitat.
La velocitat de recuperació hauria de ser mínima en dos escenaris: recuperació completa (desastre), una carpeta esborrada per error.
La funció de deduplicació és necessària.

Per resoldre el problema de la gestió de còpies de seguretat, hem instal·lat GitLab. Més detalls per abordatge.

Per descomptat, no som els primers a resoldre un problema d'aquest tipus, però ens sembla que la nostra experiència pràctica, molt guanyada, pot ser interessant i estem disposats a compartir-la.

Com que la nostra empresa té una política de codi obert, estàvem buscant una solució de codi obert. Al seu torn, compartim els nostres desenvolupaments i els publiquem. Per exemple, a GitHub hi ha el nostre connector per a Nextcloud, que oferim als clients, millorant la seguretat de les dades en cas d'eliminació accidental o intencionada.

Eines de còpia de seguretat

Vam començar la nostra recerca de mètodes de solució escollint una eina de creació de còpies de seguretat.

Tar + gzip normal no funciona bé: les dades estan duplicades. Un increment sovint conté molt pocs canvis reals i moltes de les dades d'un sol fitxer es repeteixen.
Hi ha un altre problema: la redundància de l'emmagatzematge de dades distribuïts. Utilitzem minio i les seves dades són bàsicament redundants. O havíeu de fer una còpia de seguretat a través del mateix minio: carregueu-la i utilitzeu tots els espaiadors entre el sistema de fitxers i, no menys important, hi ha el risc d'oblidar-vos d'alguns cubs i metainformació. O utilitzeu la deduplicació.

Les eines de còpia de seguretat amb duplicació estan disponibles en codi obert (a Habré hi havia Article sobre aquest tema) i els nostres finalistes van ser Borg и Rústic. La nostra comparació de les dues aplicacions es mostra a continuació, però de moment us explicarem com hem organitzat tot l'esquema.

Gestió de còpies de seguretat

Borg i Restic són bons, però cap dels dos productes té un mecanisme de control centralitzat. A efectes de gestió i control, hem escollit una eina que ja tenim implementada, sense la qual no podem imaginar la nostra feina, inclosa l'automatització -és el conegut CI/CD - GitLab.

La idea és la següent: gitlab-runner s'instal·la a cada node que emmagatzema dades de Nextcloud. El corredor executa un script amb una programació que supervisa el procés de còpia de seguretat i llança Borg o Restic.

Què hem aconseguit? Retroalimentació de l'execució, control convenient sobre els canvis, detalls en cas d'error.

aquí està aquí a GitHub vam publicar exemples de l'script per a diverses tasques i vam acabar adjuntant-lo a la còpia de seguretat no només de Nextcloud, sinó també de molts altres serveis. També hi ha un programador si no el voleu configurar manualment (i no volem) i .gitlab-ci.yml

Encara no hi ha manera de canviar el temps d'espera CI/CD a l'API de Gitlab, però és petit. Cal augmentar-lo, diguem 1d.

GitLab, afortunadament, es pot llançar no només segons un compromís, sinó només segons un calendari, això és exactament el que necessitem.

Ara sobre el guió de l'embolcall.

Hem establert les condicions següents per a aquest script:

Hauria de ser llançat tant pel corredor com a mà des de la consola amb la mateixa funcionalitat.
Hi ha d'haver gestors d'errors:
codi de retorn.
cerqueu una cadena al registre. Per exemple, per a nosaltres un error pot ser un missatge que el programa no considera fatal.
Temps d'espera de processament. El termini de lliurament ha de ser raonable.
Necessitem un registre molt detallat. Però només en cas d'error.
També es fan diverses proves abans de començar.
Petites bonificacions per comoditat que hem trobat útils durant el procés de suport:
L'inici i el final es registren al syslog de la màquina local. Això ajuda a connectar errors del sistema i operacions de còpia de seguretat.
Una part del registre d'errors, si n'hi ha, s'envia a stdout, tot el registre s'escriu en un fitxer separat. És convenient mirar immediatament CI i avaluar l'error si és trivial.
Modes de depuració.

El registre complet es desa com a artefacte a GitLab si no hi ha cap error, el registre s'elimina. Escrivim l'script en bash.

Estarem encantats de considerar qualsevol suggeriment i comentari sobre el codi obert: benvinguts.

Com funciona això

S'inicia un corredor amb un executor Bash al node de còpia de seguretat. Segons el planificador, el treball CI/CD es llança en un nap especial. El corredor llança un script d'embolcall universal per a aquestes tasques, comprova la validesa del dipòsit de còpia de seguretat, els punts de muntatge i tot el que volem, després fa una còpia de seguretat i neteja l'antic. La còpia de seguretat acabada s'envia a S3.

Treballem segons aquest esquema: és un proveïdor extern d'AWS o un equivalent rus (és més ràpid i les dades no surten de la Federació Russa). O instal·lem un clúster minio separat per al client al seu lloc amb aquests propòsits. Normalment ho fem per motius de seguretat, quan el client no vol que les dades surtin del seu circuit.

No hem utilitzat la funció d'enviar còpies de seguretat mitjançant ssh. Això no afegeix seguretat i les capacitats de xarxa del proveïdor S3 són molt superiors a les de la nostra única màquina ssh.

Per protegir la vostra màquina local d'un pirata informàtic, ja que pot esborrar dades a S3, heu d'habilitar el control de versions.
La còpia de seguretat sempre xifra la còpia de seguretat.

Borg té un mode sense xifrar none, però no us recomanem que l'activeu. En aquest mode, no només no hi haurà xifratge, sinó que no es calcula la suma de comprovació del que s'està escrivint, la qual cosa significa que la integritat només es pot comprovar indirectament, mitjançant índexs.

Un programador independent comprova les còpies de seguretat per a la integritat dels índexs i del contingut. La comprovació és lenta i llarga, de manera que l'executem per separat un cop al mes. Pot trigar diversos dies.

Llegiu-me en rus

Funcions principals

prepare formació
testcheck control de preparació
maincommand equip central
forcepostscript una funció que s'executa al final o per error. El fem servir per desmuntar la partició.

Funcions de servei

cleanup Enregistrem errors o esborram el fitxer de registre.
checklog analitzeu el registre per a l'aparició d'una línia amb un error.
ret gestor de sortida.
checktimeout comproveu el temps d'espera.

Mediambient

VERBOSE=1 Mostrem errors a la pantalla immediatament (stdout).
SAVELOGSONSUCCES=1 deseu el registre en cas d'èxit.
INIT_REPO_IF_NOT_EXIST=1 Creeu un repositori si no existeix. Desactivat per defecte.
TIMEOUT temps màxim per a l'operació principal. Podeu definir-lo com a "m", "h" o "d" al final.

Mode d'emmagatzematge per a còpies antigues. Per defecte:

KEEP_DAILY=7
KEEP_WEEKLY=4
KEEP_MONTHLY=6

Variables dins del guió

ERROR_STRING — cadena per al registre de registre d'error.
EXTRACT_ERROR_STRING — expressió per mostrar la cadena en cas d'error.
KILL_TIMEOUT_SIGNAL - senyal per matar si es va expirar el temps.
TAIL — quantes cadenes amb errors a la pantalla.
COLORMSG — color del missatge (groc per defecte).

Aquest script, que es diu wordpress, té un nom condicional, el seu truc és que també fa una còpia de seguretat de la base de dades mysql. Això significa que es pot utilitzar per a instal·lacions de Nexcloud d'un sol node, on també podeu fer una còpia de seguretat de la base de dades. La comoditat no és només que tot estigui en un sol lloc, sinó que també el contingut de la base de dades està a prop del contingut dels fitxers, ja que la diferència horària és mínima.

Restic vs Borg

També hi ha comparacions entre Borg i Restic aquí a Habré, i no teníem la tasca de fer-ne només una altra, sinó la nostra. Era important per a nosaltres com es veuria a les nostres dades, amb les nostres especificitats. Els portem.

Els nostres criteris de selecció, a més dels ja esmentats (desduplicació, recuperació ràpida, etc.):

Resistència a treballs inacabats. Comprova si hi ha kill -9.
Mida al disc.
Necessitat de recursos (CPU, memòria).
Mida de les taques emmagatzemades.
Treballant amb S3.
Comprovació d'integritat.

Per a la prova, vam agafar un client amb dades reals i una mida total d'1,6 TB.
Condicions

Borg no sap com treballar directament amb S3, i vam muntar el disc com a fusible, via ximples. Restic l'ha enviat al mateix S3.

Goofys funciona molt ràpid i bé, i n'hi ha mòdul de memòria cau de disc, que accelera encara més la feina. Està en fase beta i, francament, ens vam estavellar amb la pèrdua de dades durant les proves (altres). Però la comoditat és que el procediment de còpia de seguretat en si no requereix molta lectura, sinó sobretot escriptura, de manera que utilitzem la memòria cau només durant les comprovacions d'integritat.

Per reduir la influència de la xarxa, hem utilitzat un proveïdor local: Yandex Cloud.

Resultats de les proves comparatives.

Kill -9 amb un nou reinici van tenir èxit.
Mida al disc. Borg pot comprimir-se, de manera que els resultats són els esperats.

Còpia de seguretat
mida

Borg
562Gb

Rústic
628Gb

Per CPU
Borg en si consumeix poc, amb compressió per defecte, però s'ha d'avaluar juntament amb el procés goofys. En total, són comparables i utilitzen uns 1,2 nuclis a la mateixa màquina virtual de prova.
Memòria. Restic és d'aproximadament 0,5 GB, Borg és d'aproximadament 200 MB. Però tot això és insignificant en comparació amb la memòria cau dels fitxers del sistema. Per tant, és recomanable destinar més memòria.
La diferència de mida de la gota va ser sorprenent.

Còpia de seguretat
mida

Borg
uns 500 MB

Rústic
uns 5 MB

L'experiència amb Restic's S3 és excel·lent. Treballar amb Borg a través de goofys no planteja cap dubte, però s'ha observat que és aconsellable fer desmuntar un cop finalitzada la còpia de seguretat per restablir completament la memòria cau. La peculiaritat de l'S3 és que els trossos poc bombejats mai s'enviaran a la galleda, la qual cosa significa que les dades incompletes provoquen danys importants.
La comprovació d'integritat funciona bé en ambdós casos, però la velocitat difereix significativament.
Restic 3,5 hores.
Borg, amb una memòria cau de fitxers SSD de 100 GB: 5 hores.Aproximadament la mateixa velocitat resulta si les dades es troben en un disc local.
Borg llegeix directament des de l'S3 sense memòria cau 33 hores. Monstruosament llarg.

La conclusió és que Borg pot comprimir i té taques més grans, cosa que fa que les operacions d'emmagatzematge i GET/PUT a S3 siguin més barates. Però això suposa una verificació més complexa i lenta. Pel que fa a la velocitat de recuperació, no hem notat cap diferència. Restic pren les còpies de seguretat posteriors (després de la primera) una mica més, però no de manera significativa.

Finalment, però no menys important, en l'elecció va ser la mida de la comunitat.

I vam triar borg.

Unes paraules sobre compressió

Borg té un nou algorisme de compressió excel·lent al seu arsenal: zstd. La qualitat de compressió no és pitjor que gzip, però molt més ràpida. I comparable en velocitat a l'lz4 predeterminat.

Per exemple, un bolcat de base de dades MySQL es comprimeix dues vegades millor que lz4 a la mateixa velocitat. Tanmateix, l'experiència amb dades reals mostra que hi ha molt poca diferència en la relació de compressió del node Nextcloud.

Borg té un mode de compressió força bo: si el fitxer té una alta entropia, no s'aplica cap compressió, la qual cosa augmenta la velocitat. Activat per opció en crear
-C auto,zstd
per a l'algorisme zstd
Així que amb aquesta opció, en comparació amb la compressió predeterminada, tenim
560 Gb i 562 Gb respectivament. Les dades de l'exemple anterior, us recordo que sense compressió el resultat és de 628 Gb. El resultat d'una diferència de 2 GB ens va sorprendre una mica, però vam pensar que després de tot l'escolliríem. auto,zstd.

Mètode de verificació de còpia de seguretat

Segons el planificador, la màquina virtual s'inicia directament des del proveïdor o des del client, la qual cosa redueix molt la càrrega de la xarxa. Almenys és més barat que augmentar-lo tu mateix i conduir trànsit.

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/

Utilitzant el mateix esquema, comprovem els fitxers amb un antivirus (després del fet). Després de tot, els usuaris pengen coses diferents a Nextcloud i no tothom té un antivirus. La realització d'inspeccions en el moment de l'abocament requereix massa temps i interfereix amb el negoci.

L'escalabilitat s'aconsegueix executant corredors en diferents nodes amb diferents etiquetes.
El nostre monitoratge recull els estats de còpia de seguretat mitjançant l'API de GitLab en una finestra, si cal, els problemes es noten fàcilment i es localitzen amb la mateixa facilitat.

Conclusió

Com a resultat, sabem del cert que fem còpies de seguretat, que les nostres còpies de seguretat són vàlides, els problemes que sorgeixen amb elles triguen poc temps i es resolen a nivell de l'administrador de servei. Les còpies de seguretat ocupen molt poc espai en comparació amb tar.gz o Bacula.

Font: www.habr.com