Hogyan segít a GitLab a nagy NextCloud tárhelyek biztonsági mentésében

Szia Habr!

Ma azokról a tapasztalatainkról szeretnék beszélni, amelyek a Nextcloud tárolókból származó nagy adatok biztonsági mentésének automatizálásával kapcsolatosak különböző konfigurációkban. Szervizben dolgozom a Molniya AK-nál, ahol informatikai rendszerek konfigurációkezelését végzem, adattárolásra a Nextcloud szolgál. Beleértve, elosztott szerkezettel, redundanciával.

A telepítések sajátosságaiból adódó probléma, hogy sok az adat. A Nextcloud által biztosított verziószám, a redundancia, a szubjektív okok és egyebek sok ismétlődést hoz létre.

őstörténet

A Nextcloud adminisztrációja során felmerül a hatékony biztonsági mentés megszervezésének problémája, amelyet titkosítani kell, mivel az adatok értékesek.

Lehetőségeket kínálunk a biztonsági mentések tárolására nálunk vagy az ügyfélnél a Nextcloudtól különálló gépeken, ami rugalmas automatizált ügyintézést igényel.

Sok ügyfél van, mindegyik különböző konfigurációval, és mindegyik a saját webhelyén és saját jellemzőivel rendelkezik. Ez egy szabványos technika, amikor az egész webhely az Öné, és a biztonsági mentések koronákból készülnek; nem illeszkedik jól.

Először nézzük meg a bemeneti adatokat. Szükségünk van:

• Skálázhatóság egy vagy több csomópont tekintetében. Nagy telepítésekhez minio-t használunk tárolóként.
• Ismerje meg a biztonsági mentések végrehajtásával kapcsolatos problémákat.
• Biztonsági másolatot kell készítenie ügyfeleivel és/vagy velünk.
• Gyorsan és egyszerűen kezelje a problémákat.
• Az ügyfelek és az installációk nagyon különböznek egymástól – az egységesség nem érhető el.
• A helyreállítási sebességnek két esetben minimálisnak kell lennie: teljes helyreállítás (katasztrófa), egy mappa véletlenül törölve.
• Deduplikációs funkció szükséges.

A biztonsági mentések kezelésével kapcsolatos probléma megoldására telepítettük a GitLabot. További részletek tackle szerint.

Természetesen nem mi vagyunk az elsők, akik ilyen problémát oldanak meg, de úgy tűnik számunkra, hogy gyakorlati, nehezen megszerzett tapasztalataink érdekesek lehetnek, és készek vagyunk megosztani azokat.

Mivel cégünk nyílt forráskóddal rendelkezik, ezért nyílt forráskódú megoldást kerestünk. Mi viszont megosztjuk fejlesztéseinket és közzétesszük. Például a GitHubon van a Nextcloud bővítményünk, amelyet ügyfeleink számára biztosítunk, fokozva az adatbiztonságot véletlen vagy szándékos törlés esetén.

Biztonsági mentési eszközök

A megoldási módszerek keresését egy biztonsági mentés készítő eszköz kiválasztásával kezdtük.

A normál tar + gzip nem működik jól - az adatok duplikálva vannak. Egy növekmény gyakran nagyon kevés tényleges változást tartalmaz, és az egyetlen fájlon belüli adatok nagy része megismétlődik.
Van egy másik probléma - az elosztott adattárolás redundanciája. Minio-t használunk, és az adatai alapvetően redundánsak. Vagy magán a minion keresztül kellett biztonsági másolatot készítenie – töltse be, és használja az összes távtartót a fájlrendszer között, és ami nem kevésbé fontos, fennáll annak a veszélye, hogy elfelejti néhány tárolót és metainformációt. Vagy használjon deduplikációt.

A duplikált biztonsági mentési eszközök nyílt forráskódban érhetők el (a Habré-n voltak Cikk ebben a témában) és a döntőseink voltak Borg и Resztikus. A két pályázat összehasonlítása alább látható, de most elmondjuk, hogyan szerveztük meg a teljes programot.

Biztonsági mentések kezelése

A Borg és a Restic jó, de egyik terméknek sincs központosított vezérlése. A menedzsment és irányítás céljára egy olyan eszközt választottunk, amelyet már megvalósítottunk, amely nélkül nem tudjuk elképzelni munkánkat, beleértve az automatizálást is - ez a jól ismert CI/CD - GitLab.

Az ötlet a következő: a gitlab-runner minden Nextcloud-adatokat tároló csomópontra telepítve van. A futó ütemterv szerint futtat egy szkriptet, amely figyeli a biztonsági mentési folyamatot, és elindítja a Borg vagy a Resticet.

Mit kaptunk? Visszajelzés a végrehajtásról, kényelmes ellenőrzés a változtatások felett, részletek hiba esetén.

Itt itt a GitHubon közzétettünk példákat a szkriptre különféle feladatokhoz, és végül nem csak a Nextcloud, hanem sok más szolgáltatás biztonsági másolatához is csatoltuk. Van egy ütemező is, ha nem akarja manuálisan konfigurálni (és nem akarjuk), és a .gitlab-ci.yml

A Gitlab API-ban még nincs mód a CI/CD időtúllépésének módosítására, de kicsi. Növelni kell, mondjuk 1d.

A GitLab szerencsére nem csak commit, hanem csak ütemezés szerint tud elindulni, pont erre van szükségünk.

Most a wrapper scriptről.

A következő feltételeket állítottuk be ehhez a szkripthez:

• Mind a futó által, mind pedig kézzel kell elindítani a konzolról, ugyanazzal a funkcióval.
• Hibakezelőknek kell lenniük:
• visszatérési kód.
• keressen egy karakterláncot a naplóban. Például számunkra egy hiba olyan üzenet lehet, amelyet a program nem tekint végzetesnek.
• Feldolgozás időtúllépése. Az átfutási időnek ésszerűnek kell lennie.
• Nagyon részletes naplóra van szükségünk. De csak hiba esetén.
• Az indítás előtt számos tesztet is végeznek.
• Kis bónuszok a kényelem érdekében, amelyeket hasznosnak találtunk a támogatási folyamat során:
• A kezdet és a vége a helyi gép rendszernaplójában rögzítve van. Ez segít a rendszerhibák és a biztonsági mentési műveletek összekapcsolásában.
• A hibanapló egy része, ha van, az stdout kimenetre kerül, a teljes napló egy külön fájlba kerül. Kényelmes azonnal megnézni a CI-t, és kiértékelni a hibát, ha az triviális.
• Hibakeresési módok.

A teljes napló műtermékként kerül mentésre a GitLabban; ha nincs hiba, a napló törlődik. A forgatókönyvet bash-ban írjuk.

Örömmel veszünk minden javaslatot és megjegyzést a nyílt forráskóddal kapcsolatban – szívesen látjuk.

Ez hogy működik

A tartalék csomóponton elindul egy Bash végrehajtóval rendelkező futó. Az ütemező szerint a CI/CD munka speciális fehérrépa formájában indul. A futtató elindít egy univerzális wrapper szkriptet az ilyen feladatokhoz, ellenőrzi a biztonsági mentési tároló érvényességét, a csatolási pontokat és mindent, amit akarunk, majd biztonsági másolatot készít és megtisztítja a régit. Maga a kész biztonsági másolat elküldésre kerül az S3-nak.

E séma szerint dolgozunk - ez egy külső AWS-szolgáltató vagy egy orosz megfelelője (gyorsabb, és az adatok nem hagyják el az Orosz Föderációt). Vagy külön minio klasztert telepítünk a kliens webhelyére erre a célra. Ezt általában biztonsági okokból tesszük, amikor az ügyfél egyáltalán nem akarja, hogy az adatok elhagyják az áramkörét.

Nem használtuk azt a funkciót, hogy biztonsági másolatot küldjünk ssh-n keresztül. Ez nem növeli a biztonságot, és az S3 szolgáltató hálózati képességei sokkal magasabbak, mint a mi egyetlen ssh-gépünké.

Annak érdekében, hogy megvédje helyi gépét egy hackertől, mivel az adatokat törölheti az S3-on, engedélyeznie kell a verziókezelést.
A biztonsági másolat mindig titkosítja a biztonsági másolatot.

A Borgnak titkosítatlan módja van none, de erősen nem javasoljuk a bekapcsolását. Ebben a módban nem csak titkosítás nem lesz, de a leírtak ellenőrző összege sem kerül kiszámításra, ami azt jelenti, hogy az integritást csak közvetetten, indexek segítségével lehet ellenőrizni.

Egy külön ütemező ellenőrzi a biztonsági mentéseket az indexek és a tartalom integritására. Az ellenőrzés lassú és hosszú, ezért havonta egyszer lefuttatjuk. Ez több napig is eltarthat.

Olvass engem oroszul

alapfunkciók

• prepare edzés
• testcheck készenléti ellenőrzés
• maincommand a csapat magja
• forcepostscript a végén vagy hibásan végrehajtott függvény. A partíció leválasztására használjuk.

Szerviz funkciók

• cleanup Rögzítjük a hibákat vagy töröljük a naplófájlt.
• checklog elemezze a naplót egy hibás sor előfordulására.
• ret kilépési kezelő.
• checktimeout ellenőrizze az időtúllépést.

Környezet

• VERBOSE=1 A hibákat azonnal megjelenítjük a képernyőn (stdout).
• SAVELOGSONSUCCES=1 siker esetén mentse el a naplót.
• INIT_REPO_IF_NOT_EXIST=1 Hozzon létre egy tárat, ha nem létezik. Alapértelmezés szerint letiltva.
• TIMEOUT a fő művelet maximális időtartama. Beállíthatja, hogy „m”, „h” vagy „d” legyen a végén.

Tárolási mód a régi másolatokhoz. Alapértelmezett:

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

Változók a szkripten belül

• ERROR_STRING — karakterlánc a hiba bejelentkezési naplójához.
• EXTRACT_ERROR_STRING — a show string if error kifejezése.
• KILL_TIMEOUT_SIGNAL — jelzés az ölésre, ha időtúllépés történik.
• TAIL — hány karakterlánc hibás a képernyőn.
• COLORMSG — az üzenet színe (alapértelmezett sárga).

Ennek a szkriptnek, amit wordpressnek hívnak, feltételes neve van, a trükkje az, hogy a mysql adatbázisról is biztonsági másolatot készít. Ez azt jelenti, hogy egy csomópontos Nexcloud-telepítésekhez használható, ahol biztonsági másolatot is készíthet az adatbázisról. A kényelem nem csak abban rejlik, hogy minden egy helyen van, hanem az adatbázis tartalma is közel áll a fájlok tartalmához, hiszen minimális az időeltolódás.

Restic vs Borg

Borg és Restic között is vannak összehasonlítások itt a Habrén, és nem az volt a feladatunk, hogy csak egyet készítsünk, hanem a sajátunkat. Számunkra fontos volt, hogyan fog kinézni az adatainkon, a mi sajátosságainkkal. elhozzuk őket.

Kiválasztási kritériumaink a már említetteken (deduplikáció, gyors helyreállítás stb.) kívül:

• Ellenállás a befejezetlen munkákkal szemben. Ellenőrizd a killt -9.
• Méret a lemezen.
• Erőforrásigény (CPU, memória).
• A tárolt blobok mérete.
• Munka az S3-mal.
• Integritás ellenőrzése.

A teszteléshez egy klienst vettünk valós adatokkal és összesen 1,6 TB-os mérettel.
Feltételeket.

Borg nem tudja, hogyan kell közvetlenül dolgozni az S3-mal, és a lemezt biztosítékként szereltük fel hülyék. Restic elküldte magának az S3-nak.

A Goofys nagyon gyorsan és jól működik, és vannak lemez gyorsítótár modul, ami még jobban felgyorsítja a munkát. Béta állapotban van, és őszintén szólva, a tesztek (egyéb) során adatvesztés miatt összeomlottunk. De a kényelem az, hogy maga a mentési eljárás nem igényel sok olvasást, hanem többnyire írást, így a gyorsítótárat csak az integritás ellenőrzésekor használjuk.

A hálózat befolyásának csökkentése érdekében helyi szolgáltatót - Yandex Cloud - használtunk.

Vizsgálati eredmények összehasonlítása.

• A Kill -9 egy újabb újraindítással mindketten sikeresek voltak.
• Méret a lemezen. Borg tud tömöríteni, így az eredmények a vártnak megfelelőek.

Biztonsági másolat
méret

Borg
562Gb

Resztikus
628Gb

• CPU által
  Maga a Borg keveset fogyaszt, alapértelmezett tömörítéssel, de a goofys folyamattal együtt kell értékelni. Összességében összehasonlíthatóak, és körülbelül 1,2 magot használnak ugyanazon a teszt virtuális gépen.
• Memória. A Restic körülbelül 0,5 GB, a Borg körülbelül 200 MB. De ez mind jelentéktelen a rendszerfájl gyorsítótárához képest. Ezért célszerű több memóriát lefoglalni.
• Feltűnő volt a különbség a foltok méretében.

Biztonsági másolat
méret

Borg
körülbelül 500 MB

Resztikus
körülbelül 5 MB

• A Restic S3 tapasztalata kiváló. A Borggal való munka a goofys-on keresztül nem vet fel kérdéseket, de megjegyezték, hogy a gyorsítótár teljes alaphelyzetbe állítása érdekében tanácsos elvégezni az umount-ot a biztonsági mentés befejezése után. Az S3 sajátossága, hogy az alulpumpált darabok soha nem kerülnek a vödörbe, ami azt jelenti, hogy a hiányosan kitöltött adatok komoly károkat okoznak.
• Az integritás-ellenőrzés mindkét esetben jól működik, de a sebesség jelentősen eltér.
  Restic 3,5 óra.
  Borg, 100 GB-os SSD fájl gyorsítótárral – 5 óra.Körülbelül azonos sebességű eredmény, ha az adatok helyi lemezen vannak.
  A Borg közvetlenül az S3-ból olvas gyorsítótár nélkül 33 óra. Szörnyen hosszú.

A lényeg az, hogy a Borg képes tömöríteni, és nagyobb blobokkal rendelkezik – ami olcsóbbá teszi a tárolást és a GET/PUT műveleteket az S3-ban. Ennek azonban bonyolultabb és lassabb ellenőrzés az ára. Ami a helyreállítási sebességet illeti, nem észleltünk különbséget. A Restic egy kicsit tovább tart a további biztonsági mentések (az első után), de nem jelentős mértékben.

Végül, de nem utolsósorban a közösség nagysága volt a választásban.

És mi a borgot választottuk.

Néhány szó a tömörítésről

A Borg arzenáljában van egy kiváló új tömörítési algoritmus - zstd. A tömörítés minősége nem rosszabb, mint a gzip, de sokkal gyorsabb. És sebessége az alapértelmezett lz4-hez hasonlítható.

Például egy MySQL adatbázis-kiíratást kétszer jobban tömörít, mint az lz4-et azonos sebesség mellett. A valós adatokkal kapcsolatos tapasztalatok azonban azt mutatják, hogy a Nextcloud csomópont tömörítési arányában nagyon kicsi a különbség.

A Borgnak meglehetősen bónusz tömörítési módja van - ha a fájl nagy entrópiával rendelkezik, akkor a tömörítés egyáltalán nem kerül alkalmazásra, ami növeli a sebességet. Az opció engedélyezve van a létrehozáskor
-C auto,zstd
a zstd algoritmushoz
Tehát ezzel az opcióval az alapértelmezett tömörítéshez képest megkaptuk
560 Gb és 562 Gb. A fenti példa adatai, hadd emlékeztessem önöket, tömörítés nélkül 628Gb az eredmény. A 2 GB-os különbség eredménye némileg meglepett minket, de úgy gondoltuk, hogy mégis ezt választjuk. auto,zstd.

Biztonsági másolat ellenőrzési módszere

Az ütemező szerint a virtuális gép közvetlenül a szolgáltatótól vagy a klienstől indul el, ami nagymértékben csökkenti a hálózati terhelést. Legalább olcsóbb, mint saját kezűleg felnevelni és forgalmat vezetni.

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/

Ugyanezzel a sémával ellenőrizzük a fájlokat egy víruskeresővel (utólag). Végül is a felhasználók különböző dolgokat töltenek fel a Nextcloudba, és nem mindenkinek van víruskeresője. A kiöntéskor végzett ellenőrzések túl sok időt vesznek igénybe és zavarják az üzletmenetet.

A méretezhetőség úgy érhető el, hogy futókat futtatnak különböző csomópontokon, különböző címkékkel.
Felügyeletünk a GitLab API-n keresztül egyetlen ablakban gyűjti össze a biztonsági mentési állapotokat, szükség esetén a problémák könnyen észrevehetők és ugyanolyan könnyen lokalizálhatók.

Következtetés

Ennek eredményeként biztosan tudjuk, hogy készítünk biztonsági mentéseket, hogy a mentéseink érvényesek, a velük felmerülő problémák kevés időt vesznek igénybe, és az ügyeleti adminisztrátor szintjén oldódnak meg. A biztonsági mentések nagyon kevés helyet foglalnak el a tar.gz-hez vagy a Baculához képest.

Forrás: will.com