Hogyan segít a GitLab a nagy NextCloud tárolók biztonsági mentésében

Helló, Habr!

Ma ma szeretném bemutatni a Nextcloud nagy adatok biztonsági mentésének automatizálásában szerzett tapasztalatainkat különböző konfigurációkban. Én a „Molnya AK” vállalat CTO-ja vagyok, ahol IT rendszerek konfigurációs kezelésével foglalkozunk, és az adatok tárolására a Nextcloud-ot használjuk. Ideértve a szétosztott struktúrát, biztonsági mentéssel.

A telepítések sajátosságaiból adódó problémák, hogy sok adat van. A Nextcloud által biztosított verzionálás, a biztonsági mentések, szubjektív okok és más tényezők sok duplikációt eredményeznek.

Háttér

A Nextcloud adminisztrálása során égető probléma az effektív biztonsági mentés megszervezése, amelyet kötelező titkosítani, mivel az adatok értékesek.

Olyan tárolási lehetőségeket kínálunk, amelyek lehetővé teszik a biztonsági mentések tárolását nálunk vagy a megrendelő különálló, a Nextcloud-tól független gépein, ami rugalmas automatizált adminisztrációs megközelítést igényel.

Sok ügyfél van, mind különböző konfigurációkkal, és mindenki a saját helyszínén a saját sajátosságaival. Itt a standard módszer, amikor az egész platform a tiéd, és a biztonsági mentések a cron-ból készülnek, nem igazán hatékony.

Kezdjük az alapadatokkal. Szükségünk van:

• Skálázhatóságra, egy vagy több node-ra. Nagyobb telepítések esetén a minio-t használjuk tárolóként.
• Értesülni a biztonsági mentések végrehajtásával kapcsolatos problémákról.
• A biztonsági mentést ügyfeleknél és/vagy nálunk kell tárolni.
• Gyorsan és egyszerűen megoldani a problémákat.
• Az ügyfelek és a telepítések erősen eltérnek egymástól — az egységességet nem sikerült elérni.
• A helyreállítási sebességnek minimalizáltnak kell lennie két forgatókönyv esetén: teljes helyreállítás (katasztrófa), egy mappa — véletlen törlés.
• A deduplikációs funkció kötelező.

A biztonsági mentések kezelésének megoldásához GitLab-ot alkalmaztunk. Részletek lent.

Természetesen nem mi vagyunk az elsők, akik ilyen feladatot oldanak meg, de úgy gondoljuk, hogy a mi gyakorlati, megélt tapasztalatunk érdekes lehet, és szívesen megosztjuk.

Mivel a vállalatunknál nyílt forráskódú politika van érvényben, éppen ezért olyan megoldást kerestünk, amely nyílt forráskódú. Cserébe megosztjuk fejlesztéseinket, és közzétesszük őket. Például a GitHub-on van a Nextcloudhoz készült pluginunk, amelyet ügyfeleink telepítenek, megerősítve az adatvédelmet véletlen vagy szándékos törlés esetére.

Biztonsági mentési eszközök

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

A szokásos tar + gzip nem működik jól - az adatok megismétlődnek. Az inkrementális mentés gyakran nagyon kis változtatásokat tartalmaz, és a legtöbb adat egy fájlon belül ismétlődik.
Van még egy probléma - a felosztott adatraktározás redundanciája. Mi a miniot használunk, és az adatai alapvetően redundánsak. Vagy a mentést közvetlenül a minio segítségével kellett volna végezni – ez megterhelné, és használni kellene az összes réteget a fájlrendszeren keresztül, és ami nem kevésbé fontos, fennáll a rizikó, hogy elfelejtsük a részben lévő tárolókat és a meta-információkat. Vagy deduplikációt kellene alkalmazni.

A deduplikáló mentési eszközök léteznek nyílt forráskódú formában (a Habr-nál voltak cikkből származnak erről a témáról) és a végső döntésünket az alábbi két alkalmazásra bocsátottuk. Borg és Restic. Az alábbiakban összehasonlítjuk a két alkalmazást, de először bemutatjuk, hogyan szerveztük meg az egész rendszert.

A biztonsági mentések létrehozásának kezelése

A Borg és a Restic jó, de egyik termék sem rendelkezik központosított kezelési mechanizmussal. A kezelés és a felügyelet céljából kiválasztottunk egy olyan eszközt, amely már telepítve van nálunk, és nélkülözhetetlen a munkánkhoz, beleértve az automatizálást is - ez a jól ismert CI/CD - GitLab.

A koncepció a következő: minden olyan Nextcloud adatot tároló csomópontba gitlab-runnert telepítünk. A runner ütemezett scriptet indít, amely figyelemmel kíséri a biztonsági mentési folyamatot, és ez indítja el a Borgot vagy a Resticot.

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

Íme itt a GitHub-on példákat tettünk közzé különböző feladatokhoz, mi pedig végül ezt a mentéshez csatlakoztattuk, nemcsak a Nextcloud, hanem sok más szolgáltatás számára is. Ott található az ütemező is, ha nem akarjuk manuálisan beállítani (de nekünk nem is akaródzik) és .gitlab-ci.yml

A GitLab API-jában egyelőre nincs lehetőség a CI/CD időtúllépésének megváltoztatására, és az ott elég kicsi. Azt meg kell növelni, mondjuk 1d.

Szerencsére a GitLab nemcsak a commitok után tud indítani, hanem ütemezés szerint is, ez pontosan azt jelenti, amire szükségünk van.

Most pedig a wrapper script-ről.

Az alábbi feltételeket állítottuk fel ennek a scriptnek:

• Futtathatónak kell lennie runner által és parancssorból is, azonos funkcionalitással.
• Kötelező hiba-kezelőkkel kell rendelkeznie:
• visszatérési kód.
• sor keresése a naplóban. Például számunkra hiba lehet olyan üzenet, amit a program nem tart fatálisnak.
• Időtúllépés kezelése. A végrehajtás idejének ésszerűnek kell lennie.
• Részletes naplóra van szükségünk. De csak hiba esetén.
• Egy sor tesztet is végrehajtunk a kezdés előtt.
• Kis kényelmi funkciók, amelyeket hasznosnak találtunk a támogatás során:
• A kezdést és befejezést a helyi gép syslog-ja rögzíti. Ez segít összekapcsolni a rendszerhibákat és a biztonsági mentést.
• A hiba naplójának egy része, ha létezik, stdout-ba kerül, az összes napló egy külön fájlba íródik. Kényelmes azonnal megnézni a CI-ben és értékelni a hibát, ha az triviális.
• Hibakeresési módok.

A teljes napló artefaktumként kerül mentésre a GitLabban, ha hiba nincs, akkor a napló törlődik. A szkript bash nyelven íródik.

Bármilyen javaslatot és észrevételt az open source-ról szívesen megfontolunk - welcome.

Hogyan működik ez

A biztonsági mentés alatt álló csomóponton egy futtató kerül indításra bash executorral. A tervezőben egy speciális repóba egy CI/CD feladat indul. A futtató univerzális burkoló szkriptet futtat az ilyen feladatokhoz, amelyben ellenőrzések zajlanak a biztonsági mentés repó érvényességére, a csatolt pontokra és mindenre, amit szeretnénk, majd végrehajtódik a biztonsági mentés és a régi adatok törlése. A kész biztonsági mentés az S3-ra kerül elküldésre.

Ilyen séma szerint dolgozunk - ez egy külső szolgáltató, mint az AWS, vagy orosz analóg (ez gyorsabb és az adatok nem hagyják el Oroszországot). Vagy külön minio klasztert telepítünk a kliens helyszínén ezekhez a célokra. Általában biztonsági megfontolásokból tesszük, amikor a kliens egyáltalán nem akarja, hogy az adatok elhagyják a környezetüket.

A biztonsági mentés ssh-n keresztüli küldésének funkcióját nem használtuk. Ez nem növeli a biztonságot, a S3 szolgáltató hálózati lehetőségei pedig sokkal magasabbak, mint a saját ssh gépünké.

A hacker ellen a helyi gépen történő védelem érdekében - hiszen letörölheti az adatokat az S3-ról, mindenképpen be kell kapcsolni a verziókezelést.
A biztonsági mentés mindig titkosítva van.

A Borg-nak van titkosítás nélküli üzemmódja, nincs, de ezt kategorikusan nem ajánljuk bekapcsolni. Ebben az üzemmódban nem lesz titkosítás, és a rögzített adatok ellenőrző összege sem kerül kiszámításra, így az integritást csak közvetetten, az indexek alapján lehet ellenőrizni.

Külön ütemező segítségével ellenőrizni kell a biztonsági mentéseket az indexek és a tartalom integritására. Az ellenőrzés lassan és hosszan történik, ezért havi egyszer indítjuk el. Napokig is eltarthat.

README oroszul

Főbb funkciók

• – a tesztelendő playbook futtatása, elősegítés
• testcheck készültségi ellenőrzés
• maincommand fő parancs
• forcepostscript a funkció, amely a végén vagy hiba esetén hajtódik végre. Használjuk az partíció leválasztásához.

Szolgáltatási funkciók

• tisztítási folyamatban hibákat rögzítünk, vagy töröljük a naplófájlt.
• checklog a naplót elemezzük hibás sorokkal.
• ret kilépési kezelő.
• checktimeout időkorlát ellenőrzése.

Environment

• VERBOSE=1 azonnal megjelenítjük a hibákat a képernyőn (stdout).
• SAVELOGSONSUCCES=1 napló tárolása siker esetén.
• INIT_REPO_IF_NOT_EXIST=1 Létrehozzuk a tárolót, ha még nem létezett. Alapértelmezés szerint ki van kapcsolva.
• TIMEOUT maximum idő az alapművelethez. A végén ‘m’, ‘h’ vagy ‘d’ értéket adhatsz meg.

Régi másolatok tárolási módja. Alapértelmezés:

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

változók a scriptben

• ERROR_STRING — karakterlánc a naplóban lévő hiba ellenőrzéséhez.
• EXTRACT_ERROR_STRING — kifejezés a hiba esetén megjelenítendő szöveghez.
• KILL_TIMEOUT_SIGNAL — jel a késlekedés megölésére.
• TAIL — hány sor hibát mutat a képernyőn.
• COLORMSG — az üzenet színe (alapértelmezett sárga).

Ez a script, amit wordpress-nek hívunk, fiktíven nevezik, az az előnye, hogy biztonsági másolatot készít a mysql adatbázisról. Tehát használható egyedi Nextcloud telepítésekhez is, ahol az adatbázist is menthetjük. Az előny nemcsak az, hogy minden egy helyen van, de az adatbázis tartalma közel áll a fájlok tartalmához, mivel az időbeli eltérés minimális.

Restic vs Borg

Borg és Restic összehasonlítása is van itt a Habrén, és nem volt célunk, hogy csak egy újabbat készítsünk, hanem a sajátunkat. Fontos volt számunkra, hogy ez hogyan fog kinézni a mi adatainkon, a mi sajátosságainkkal. Ezeket bemutatjuk.

Választási kritériumaink, a már említetteken túl (deduplikálás, gyors helyreállítás stb.):

• Ellenállóság a befejezetlen munkával szemben. Ellenőrzés kill -9-re.
• Lemezméret.
• Erőforrásigény (CPU, memória).
• Tartott blobok mérete.
• Működés S3-mal.
• Integritásellenőrzés.

A teszteléshez egy ügyfelet választottunk valós adatokkal és összesen 1,6TB mérettel.
Körülmények.

A Borg nem tud közvetlenül S3-mal dolgozni, ezért FUSE lemezként csatlakoztuk, a goofys. A Restic önállóan küldte az S3-ra.

A Goofys nagyon gyorsan és jól működik, és van hozzá lemezgyorsító modul, ami még inkább felgyorsítja a működést. Jelenleg bétában van, és be kell vallanunk, hogy tesztelés során (másokkal) adatvesztés miatt összeomlott. De az előny az, hogy a biztonsági másolat készítése nem igényel nagy olvasást, hanem főleg írást, ezért a gyorsítótárat csak az integritás ellenőrzése során használjuk.

A hálózati hatások csökkentésére helyi szolgáltatót használtunk - Yandex Felhő.

A tesztelési eredmények összehasonlítása.

• Kill -9 és az újraindítás mindkettő sikeresen megtörtént.
• Lemezméret. A Borg képes tömöríteni, ezért az eredmények várhatóak.

Backuper
Méret

Borg
562Gb

Restic
628Gb

• CPU szerint
  A Borg önmagában kevés erőforrást használ, az alapértelmezett tömörítéssel, de értékelni kell a goofys folyamattal együtt. Összességében összehasonlíthatók, és körülbelül 1,2 magot használnak egy és ugyanazon teszt virtuális gépen.
• Memória. A Restic körülbelül 0,5Gb, a Borg körülbelül 200Mb. De ez minden lényegesen elhanyagolható a rendszer fájlgyorsítótárával összehasonlítva. Tehát érdemes több memóriát biztosítani.
• A blobok méretbeli eltérése figyelemre méltó volt.

Backuper
Méret

Borg
körülbelül 500Mb

Restic
körülbelül 5Mb

• Az S3-mal való együttműködés Restic-kel kiváló. A Borg működése goofys-on keresztül nem okoz problémát, de észlelte, hogy a mentés befejezése után érdemes umount-ot végezni a cache teljes törléséhez. Az S3 működésének sajátossága, hogy a befejezetlen chankok soha nem kerülnek elküldésre a vödörbe, ami azt jelenti, hogy a nem teljesen feltöltött adatok nagy sérülésekhez vezetnek.
• Az integritás ellenőrzése mindkét esetben jól működik, de a sebesség jelentősen eltér.
  Restic – 3,5 óra.
  Borg, 100Gb SSD fájlgyorsítótárral – 5 óráig. Körülbelül hasonló sebességű eredmény, ha az adatok helyi lemezen találhatók.
  A Borg közvetlenül olvas az S3-ról cache nélkül 33 óra. Szörnyen hosszú.

Összességében 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-on. De ezért a bonyolultabb és lassabb ellenőrzésért kell fizetni. A helyreállítás sebességében nem észleltünk különbséget. A következő biztonsági mentések (az első után) a restic-nél kicsit hosszabb időt vesznek igénybe, de nem lényegesen.

A választás során nem utolsó helyen állt a közösség mérete.

És mi a borgot választottuk.

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

A Borg-nak van egy kiváló új tömörítési algoritmus a tarsolyában - zstd. A tömörítési minőség nem rosszabb, mint a gzip, de jelentősen gyorsabb. Ráadásul sebességben összehasonlítható az alapértelmezett lz4-gyel.

Például a MySQL adatbázis dump-ja kétszer jobban tömöríthető lz4-nél azonos sebesség mellett. Ugyanakkor a valós adatokkal végzett tapasztalatok szerint nagyon kis különbség van a Nextcloud csomópont tömörítési arányában.

A Borg-nál van egy viszonylag bónusz tömörítési mód - ha a fájl nagyobb entrópiával rendelkezik, a tömörítést egyáltalán nem alkalmazzák, ami fokozza a munka sebességét. A létrehozásnál egy opcióval kapcsolható be.
-C auto,zstd
a zstd algoritmushoz
Ezért ezzel az opcióval az alapértelmezett tömörítéshez képest
560 Gb és 562 Gb összesen. Az előző példa adatait, emlékeztetek, tömörítés nélkül az eredmény 628 Gb. A 2 Gb-os eltérés meglepett minket, de úgy döntöttünk, hogy végül mindenki ezt választja. auto,zstd.

A biztonsági mentés ellenőrzési módszere

A virtuális gép a szolgáltatónál vagy az ügyfélnél indul a tervező alapján, ami jelentősen csökkenti a hálózati terhelést. Legalábbis olcsóbb, mint nálunk felállítani és mozgásba hozni a forgalmat.

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}\/\nborg check --debug -p --verify-data \/mnt\/goofys\/{borg1}\/

Ugyanezen séma szerint ellenőrizzük a fájlokat antivírussal (utólagosan). Végül is a felhasználók különböző adatokat töltenek fel a Nextcloudba, és nem mindenkinek van antivírusa. Az ellenőrzés a feltöltés pillanatában túl sok időt igényel, és akadályozza az üzletmenetet.

A skálázhatóság különböző címkékkel rendelkező node-okon történő futtatással érhető el.
Monitorozásunk során a GitLab API-ján keresztül egy helyen gyűjtjük a biztonsági mentések státuszait, a problémák szükség esetén könnyen észlelhetők és könnyen lokalizálhatók.

Zárás

Ennek eredményeként pontosan tudjuk, hogy biztonsági mentéseket készítünk, hogy a biztonsági mentéseink érvényesek, a problémák, amelyek felmerülnek, kevés időt igényelnek, és a rendszergazda szintjén megoldhatók. A biztonsági mentések valójában nagyon kevés helyet foglalnak el a tar.gz vagy Bacula-hoz képest.

Forrás: habr.com