Ez a megjegyzés befejezi a biztonsági mentéssel kapcsolatos ciklust. Meg fogja tárgyalni a dedikált szerver (vagy VPS) logikai felépítését, amely kényelmes a biztonsági mentéshez, és lehetőséget kínál arra, hogy katasztrófa esetén gyorsan visszaállítsa a szervert a biztonsági másolatból, anélkül, hogy sok leállást okozna.
Nyers adatok
Egy dedikált szerver leggyakrabban legalább két merevlemezzel rendelkezik, amelyek egy első szintű RAID-tömb (tükör) szervezésére szolgálnak. Ez azért szükséges, hogy a kiszolgáló továbbra is működhessen, ha az egyik lemez meghibásodik. Ha ez egy szokásos dedikált szerver, akkor lehet, hogy az SSD-n külön hardveres RAID vezérlő található aktív gyorsítótárazási technológiával, így a szokásos merevlemezek mellett egy vagy több SSD is csatlakoztatható. Néha dedikált szervereket kínálnak, amelyekben az egyetlen helyi lemez a SATADOM (kis lemezek, szerkezetileg egy SATA portra csatlakoztatott flash meghajtó), vagy akár egy közönséges kis (8-16 GB) flash meghajtó egy speciális belső portra csatlakoztatva, és a az adatokat a tárolórendszerből veszik, dedikált tárolóhálózaton (Ethernet 10G, FC stb.) keresztül kapcsolják össze, és vannak dedikált szerverek, amelyek közvetlenül a tárolórendszerből töltődnek be. Nem fogok ilyen lehetőségeket fontolóra venni, mivel ilyen esetekben a szerver biztonsági mentésének feladata zökkenőmentesen átszáll a tárolórendszert karbantartó szakemberre; általában léteznek különféle szabadalmaztatott technológiák a pillanatképek készítésére, a beépített deduplikációra és a rendszergazda egyéb örömeire. , amelyet a sorozat előző részeiben tárgyaltunk. Egy dedikált szerver lemeztömbjének térfogata több tíz terabájtot is elérhet, a szerverhez csatlakoztatott lemezek számától és méretétől függően. A VPS esetében a kötetek szerényebbek: általában nem több 100 GB-nál (de van több is), és az ilyen VPS-ek tarifái könnyen drágábbak lehetnek, mint a legolcsóbb dedikált szerverek ugyanattól a hostertől. A VPS-nek leggyakrabban egy lemeze van, mert alatta tárolórendszer (vagy valami hiperkonvergált) lesz. Néha egy VPS-nek több különböző jellemzőkkel rendelkező lemeze van, különböző célokra:
- kis rendszer - az operációs rendszer telepítéséhez;
- nagy - felhasználói adatok tárolása.
Amikor újratelepíti a rendszert a vezérlőpult segítségével, a felhasználói adatokat tartalmazó lemez nem kerül felülírásra, hanem a rendszerlemez teljesen újratöltődik. Ezenkívül VPS esetén a tárhely felajánlhat egy gombot, amely pillanatképet készít a VPS (vagy lemez) állapotáról, de ha saját operációs rendszert telepít, vagy elfelejti aktiválni a kívánt szolgáltatást a VPS-en belül, néhány az adatok továbbra is elveszhetnek. A gomb mellett általában adattárolási szolgáltatást is kínálnak, legtöbbször nagyon korlátozottan. Általában ez egy FTP-n vagy SFTP-n keresztüli hozzáféréssel rendelkező fiók, néha SSH-val együtt, lecsupaszított shell-el (például rbash), vagy korlátozza a parancsok futtatását az authorizált_kulcsokon keresztül (a ForcedCommand-on keresztül).
Egy dedikált szerver két 1 Gbps sebességű porton keresztül csatlakozik a hálózathoz, néha 10 Gbps sebességű kártyák is lehetnek. A VPS leggyakrabban egy hálózati interfésszel rendelkezik. Az adatközpontok leggyakrabban nem korlátozzák a hálózat sebességét az adatközponton belül, de korlátozzák az internetelérés sebességét.
Az ilyen dedikált szerver vagy VPS tipikus terhelése egy webszerver, egy adatbázis és egy alkalmazásszerver. Néha különféle kiegészítő kiegészítő szolgáltatások is telepíthetők, beleértve a webszervert vagy adatbázist: keresőmotor, levelezőrendszer stb.
A biztonsági másolatok tárolására egy speciálisan előkészített szerver szolgál, erről a későbbiekben írunk részletesebben.
A lemezrendszer logikai felépítése
Ha RAID vezérlővel vagy egy lemezes VPS-sel rendelkezik, és a lemezalrendszer működéséhez nincsenek speciális beállítások (például külön gyorslemez az adatbázishoz), akkor az összes szabad terület a következőképpen van felosztva: egy partíció jön létre, és egy LVM kötetcsoport jön létre rajta, több kötet jön létre benne: 2 kisebb, azonos méretű, gyökér fájlrendszerként használt (frissítések során egyenként változtatva a gyors visszaállítás érdekében, az ötletet a Calculate Linux disztribúcióból vettük át), egy másik a swap partícióhoz, a többi szabad terület kis kötetekre van osztva, gyökér fájlrendszerként használják teljes értékű konténerekhez, lemezekhez virtuális gépekhez, fájlokhoz rendszerek a /home fiókokhoz (minden fióknak saját fájlrendszere van), fájlrendszerek alkalmazástárolókhoz.
Fontos megjegyzés: a köteteknek teljesen önállónak kell lenniük, pl. nem függhetnek egymástól vagy a gyökér fájlrendszertől. Virtuális gépek vagy tárolók esetében ez a pont automatikusan megfigyelésre kerül. Ha ezek alkalmazástárolók vagy saját könyvtárak, akkor érdemes megfontolni a webszerver és más szolgáltatások konfigurációs fájljainak szétválasztását oly módon, hogy a lehető legnagyobb mértékben kiküszöböljük a kötetek közötti függőséget. Például minden webhely a saját felhasználójától fut, a webhely konfigurációs fájlok a felhasználó kezdőkönyvtárában vannak, a webszerver beállításaiban a webhely konfigurációs fájlok nem szerepelnek az /etc/nginx/conf.d/ címen keresztül..conf és például /home//configs/nginx/*.conf
Több lemez esetén létrehozhatunk egy szoftveres RAID-tömböt (és ha van rá igény és lehetőség, annak gyorsítótárazását SSD-n konfigurálhatjuk), amelyre a fent javasolt szabályok szerint LVM-et építhetünk. Ebben az esetben is használhatod a ZFS-t vagy a BtrFS-t, de ezt kétszer is meg kell gondolnod: mindkettő sokkal komolyabb erőforrás-kezelést igényel, ráadásul a ZFS nincs benne a Linux kernelben.
Az alkalmazott sémától függetlenül mindig érdemes előre megbecsülni a lemezekre történő változtatások hozzávetőleges sebességét, majd kiszámolni a pillanatképek készítésére lefoglalt szabad terület mennyiségét. Például, ha a szerverünk 10 megabájt/másodperc sebességgel írja az adatokat, és a teljes adattömb mérete 10 terabájt - a szinkronizálási idő elérheti a napot (22 órát - ekkora kerül átadásra egy ilyen kötet hálózaton keresztül 1 Gbps) - érdemes körülbelül 800 GB-ot lefoglalni. A valóságban ez a szám kisebb lesz, nyugodtan oszthatja a logikai kötetek számával.
Biztonsági mentés tároló szerver eszköz
A biztonsági másolatok tárolására szolgáló szerverek közötti fő különbség a nagy, olcsó és viszonylag lassú lemezek. Mivel a modern HDD-k már átlépték a 10 TB-os sávot egy lemezen, ezért fájlrendszereket vagy RAID-et kell használni ellenőrző összegekkel, mert a tömb újraépítése vagy a fájlrendszer helyreállítása során (több nap!) előfordulhat, hogy a második lemez meghibásodik. megnövekedett terhelésre. A legfeljebb 1 TB kapacitású lemezeken ez nem volt olyan érzékeny. A leírás egyszerűsége érdekében feltételezem, hogy a lemezterület két, megközelítőleg azonos méretű részre van osztva (ismét például LVM használatával):
- a felhasználói adatok tárolására használt szervereknek megfelelő kötetek (ellenőrzés céljából az utolsó biztonsági mentés kerül telepítésre);
- BorgBackup adattárként használt kötetek (a biztonsági mentések adatai közvetlenül ide kerülnek).
A működés elve az, hogy minden szerverhez külön kötetek készülnek a BorgBackup tárolókhoz, ahová a harci szerverek adatai kerülnek. A repozitóriumok csak hozzáfűzés módban működnek, ami kiküszöböli a szándékos adattörlés lehetőségét, valamint a duplikáció és a tárolók időnkénti tisztítása miatt a régi mentésekből (az éves másolatok maradnak meg, havonta az utolsó évről, hetente az utolsó hónapról, naponta a múlt héten, esetleg speciális esetekben - óránként az utolsó napon: összesen 24 + 7 + 4 + 12 + éves - körülbelül 50 példány szerverenként).
A BorgBackup adattárak nem engedélyezik a csak hozzáfűzési módot; ehelyett a ForcedCommand az .ssh/authorized_keys fájlban a következőhöz hasonló:
from="адрес сервера",command="/usr/local/bin/borg serve --append-only --restrict-to-path /home/servername/borgbackup/",no-pty,no-agent-forwarding,no-port-forwarding,no-X11-forwarding,no-user-rc AAAAA.......A megadott elérési út egy burkoló szkriptet tartalmaz a borg tetején, amely amellett, hogy elindítja a paraméterekkel ellátott bináris fájlt, az adatok eltávolítása után elindítja a biztonsági másolat visszaállításának folyamatát. Ehhez a wrapper szkript létrehoz egy címkefájlt a megfelelő tárhely mellett. Az utolsó biztonsági mentés automatikusan visszaáll a megfelelő logikai kötetre az adatkitöltési folyamat befejezése után.
Ez a kialakítás lehetővé teszi a szükségtelen biztonsági mentések időszakos tisztítását, és megakadályozza, hogy a harci szerverek bármit is töröljenek a biztonsági mentési tárolókiszolgálóról.
Biztonsági mentési folyamat
A biztonsági mentés kezdeményezője maga a dedikált szerver vagy VPS, mivel ez a séma jobban irányítja a biztonsági mentési folyamatot a szerver részéről. Először egy pillanatfelvétel készül az aktív gyökérfájlrendszer állapotáról, amelyet a rendszer felcsatol és feltölt a BorgBackup segítségével a biztonsági mentési tárolókiszolgálóra. Az adatrögzítés befejezése után a pillanatfelvételt leválasztják és törlik.
Ha van egy kis adatbázis (legfeljebb 1 GB minden helyhez), akkor adatbázis dump készül, amelyet a megfelelő logikai kötetbe mentünk, ahol ugyanannak a webhelynek a többi adata található, de úgy, hogy a kiírat nem érhető el a webszerveren keresztül. Ha az adatbázisok nagyok, be kell állítania a „forró” adateltávolítást, például az xtrabackup for MySQL használatával, vagy a WAL-lal az archive_command paranccsal a PostgreSQL-ben. Ebben az esetben az adatbázis a helyadatoktól elkülönítve kerül visszaállításra.
Ha konténereket vagy virtuális gépeket használ, konfigurálja a qemu-guest-agent, CRIU vagy más szükséges technológiákat. Más esetekben további beállításokra leggyakrabban nincs szükség - egyszerűen csak pillanatfelvételeket készítünk a logikai kötetekről, amelyeket ezután ugyanúgy feldolgozunk, mint a gyökérfájlrendszer állapotáról készült pillanatképet. Az adatok rögzítése után a képek törlődnek.
A mentési tárolókiszolgálón további munka folyik:
- az egyes tárolókban készült utolsó biztonsági mentés ellenőrzése,
- az adatgyűjtési folyamat befejezését jelző jelölésfájl meglétét ellenőrzik,
- az adatok a megfelelő helyi kötetre bővülnek,
- a címkefájl törlődik
Szerver helyreállítási folyamat
Ha a fő szerver meghal, akkor egy hasonló dedikált szerver indul el, amely valamilyen szabványos lemezképről indul. A letöltés nagy valószínűséggel a hálózaton keresztül fog megtörténni, de a szervert beállító adatközponti technikus azonnal átmásolhatja ezt a szabványos képet az egyik lemezre. A letöltés a RAM-ba történik, majd elindul a helyreállítási folyamat:
- kérés érkezik egy blokkeszköz csatlakoztatására iscsinbd-n vagy más hasonló protokollon keresztül az elhunyt szerver gyökérfájlrendszerét tartalmazó logikai kötethez; Mivel a gyökér fájlrendszernek kicsinek kell lennie, ezt a lépést néhány percen belül be kell fejezni. A rendszerbetöltő is visszaáll;
- a helyi logikai kötetek szerkezete újra létrejön, a logikai kötetek a biztonsági mentési szerverről a dm_clone kernelmodul segítségével csatolva lesznek: megkezdődik az adatok helyreállítása, és a változtatások azonnal a helyi lemezekre íródnak.
- egy konténer indul az összes rendelkezésre álló fizikai lemezzel - a szerver funkcionalitása teljesen visszaáll, de csökkent a teljesítménnyel;
- az adatszinkronizálás befejezése után a rendszer leválasztja a logikai köteteket a biztonsági mentési szerverről, kikapcsolja a tárolót, és újraindítja a szervert;
Újraindítás után a szerver minden adattal rendelkezik, amely a biztonsági mentés létrehozásakor ott volt, és tartalmazza a visszaállítási folyamat során végrehajtott összes módosítást is.
A sorozat további cikkei
Biztonsági mentés 7. rész: Következtetések
Arra kérem Önt, hogy a javasolt lehetőséget kommentben vitassa meg, köszönöm a figyelmet!
Forrás: will.com