Ez a megjegyzés zárja le a biztonsági másolatokkal kapcsolatos ciklust. Arról fog szólni, hogy a dedikált szerver (vagy VPS) logikai szervezése hogyan legyen biztonsági másolat készítésére alkalmas, valamint javaslatot tesz egy gyors helyreállítási megoldásra biztonsági másolatból, amely nem okoz komoly leállásokat vészhelyzet esetén.
Forrásadatok
A dedikált szerverek többnyire legalább két merevlemezzel rendelkeznek, amelyek az első szintű RAID tömb (tükör) létrehozására szolgálnak. Ez lehetővé teszi a szerver működésének folytatását, ha az egyik lemez meghibásodik. Ha ez egy hagyományos dedikált szerver, lehet egy külön hardveres RAID-vezérlő, aktív SSD cache technológiával, így a hagyományos merevlemezek mellett csatlakoztatható egy vagy több SSD. Néha kínálnak olyan dedikált szervereket, ahol a helyi lemezek között csak SATADOM (kis lemezek, amelyek szerkezete egy USB flash meghajtó, amely SATA porthoz csatlakozik) található, vagy akár egy kis (8-16 GB) flash meghajtó is, amely külön belső porthoz csatlakozik, míg az adatok egy dedikált adat tároló hálózaton csatlakozott SAN-ból érkeznek (Ethernet 10G, FC stb.), és léteznek olyan dedikált szerverek, amelyek közvetlenül a SAN-ból bootolnak. Az ilyen lehetőségeket nem fogom tárgyalni, mivel ilyenkor a szerver biztonsági másolatának készítése általában a SAN-t kezelő szakember feladatává válik, ahol különböző gyártói technológiák rendelkezésre állnak az állapotképek létrehozására, beépített deduplikáció és egyéb előnyök, amelyeket a ciklus korábbi részeiben tárgyaltunk. A dedikált szerver lemezterülete elérheti a több tíz terabájtot is, a csatlakoztatott lemezek számától és méretétől függően. VPS esetén a méretek szerényebbek: általában nem haladják meg a 100 GB-ot (de vannak nagyobbak is), és az ilyen VPS-értékek könnyen lehetnek drágábbak, mint a legolcsóbb dedikált szervereknél ugyanattól a szolgáltatótól. A VPS-ek általában egy lemezzel rendelkeznek, mert mögötte SAN (vagy valami hiper-konvergencia) áll. Néha a VPS-nek több lemeze is van különféle teljesítménnyel, különböző célokra:
- kicsi rendszeres — az operációs rendszer telepítése céljából;
- nagy — felhasználói adatok tárolására.
A rendszer újratelepítése során a felhasználói adatokat tartalmazó lemez nem törlődik, azonban a rendszer teljesen újra van írva. VPS esetén a szolgáltató kínálhat egy gombot, amely a VPS (vagy lemez) állapotának képmásolatát készíti, de ha saját operációs rendszert telepítünk, vagy elfelejtjük aktiválni a szükséges szolgáltatást a VPS-en belül, egyes adatok akkor is elveszhetnek. Ezen gomb mellett általában adatmegőrző szolgáltatás is jár, amely legtöbbször jelentősen korlátozott. Általában egy FTP vagy SFTP protokollon keresztüli elérési fiók, néha SSH-val, korlátozott shellel (például rbash) vagy parancsok futtatásának korlátozásával az authorized_keys-en keresztül (ForcedCommand-nal).
A dedikált szerver két 1 Gbit/s sebességű porttal csatlakozik a hálózathoz, néha 10 Gbit/s sebességű kártyák is használatosak. VPS esetén a hálózati interfész általában egyetlen. A legtöbb adatközpont nem korlátozza a belső hálózat sebességét, de korlátozhatja az internet hozzáférés sebességét.
A tipikus terhelés egy ilyen dedikált szerver vagy VPS esetében egy webszerver, adatbázis és alkalmazás szerver. Néha különféle kiegészítő segédszolgáltatások is telepítve lehetnek, beleértve a webszerver vagy adatbázis számára: keresőmotor, levelezőrendszer stb.
A biztonsági mentések tárolására szolgáló terület egy külön erre a célra készített szerver, erről később részletesebben írunk.
A lemezrendszer logikai szervezése
Ha van RAID-vezérlő, vagy ez egy VPS egy lemezzel, és nincsenek különösebb preferenciák a lemezes rendszer működésével kapcsolatban (például külön gyors lemez az adatbázis számára), akkor a szabad helyet így osztjuk meg: létrejön egy partíció, amelyre létrehozunk egy LVM kötetcsoportot, amelyben több kötet keletkezik: 2 kis, azonos méretű kötet, amelyeket a gyökér fájlrendszerként használnak (frissítések során felváltva cserélve a gyors visszaállítás érdekében, az ötlet a Calculate Linux disztribúcióból származik), egy további kötet a swap partícióhoz, a maradék szabad hely pedig kis kötetekre oszlik, amelyeket a teljes tartályok gyökér fájlrendszereként, virtuális gépek számára készült lemezekként, a felhasználók számára a /home könyvtár fájlrendszereiként (minden felhasználónak saját fájlrendszere) és alkalmazás konténereként használnak.
Fontos megjegyzés: a köteteknek teljesen önállónak kell lenniük, azaz nem szabad, hogy egymástól, vagy a gyökér fájlrendszertől függjenek. Virtuális gépek vagy tartályok esetén ez automatikusan biztosított. Ha azonban ezek alkalmazás konténerek vagy otthoni könyvtárak, érdemes elgondolkodni a webszerver és más szolgáltatások konfigurációs fájljainak úgy való szétválasztásáról, hogy minimálisra csökkentsük a kötetek közötti függőségeket. Például minden weboldal a saját felhasználójától működik, a weboldal konfigurációs fájljai a felhasználó otthoni könyvtárában vannak, a webszerver beállításaiban a weboldalak konfigurációs fájljait nem a /etc/nginx/conf.d/.conf útvonalon keresztül kapcsolják be, hanem például a /home/útvonalon..conf, hanem például /home//configs/nginx/*.conf
Ha azonban több lemez van, programozott RAID tömböt lehet létrehozni (és beállítani a gyorsítást SSD-n, ha szükséges és lehetséges), a fenti szabályok szerint LVM-et létrehozva a RAID fölött. Ezen a ponton a ZFS vagy a BtrFS is használható, de érdemes többször is átgondolni: mindkettő sokkal komolyabb forráskezelést igényel, ráadásul a ZFS nem része a Linux kernelnek.
Függetlenül attól, hogy milyen rendszert használunk, mindig érdemes előre megbecsülni a változásoknak a lemezekre írási sebességét, majd kiszámítani a szabad hely méretét, amelyet a pillanatfelvételek készítésére fognak fenntartani. Például, ha a szerverünk 10 megabájt/másodperc sebességgel írja az adatokat, és az adathalmaz teljes mérete 10 terabájt — a szinkronizálási idő akár egy napot (22 órát — ennyi idő alatt kerül átvitelre ez a mennyiség 1 Gbit/s sebességgel) is igénybe vehet — érdemes körülbelül 800 GB-ot fenntartani. A valóságban a szám alacsonyabb lesz, nyugodtan eloszthatjuk a logikai kötetek számával.
Biztonsági mentések tárolására szolgáló szerver
A biztonsági mentések tárolására szolgáló szerver legfőbb jellemzője a nagy, olcsó és viszonylag lassú lemezek használata. Mivel a modern HDD-k már átlépték a 10 TB-os határt egyetlen lemezen — elengedhetetlen a fájlrendszerek vagy a RAID hibajavító kódok alkalmazása, mivel a tömb átalakítása vagy a fájlrendszer helyreállítása közben (több nap!) a második lemez meghibásodhat a fokozott terhelés miatt. 1 TB kapacitású lemezek esetén ez nem volt annyira érzékeny. Az egyszerűség kedvéért feltételezem, hogy a lemezterület körülbelül azonos méretű két részre van osztva (például LVM segítségével):
- következő kötetek, amelyek a felhasználói adatok tárolására szolgálnak a szervereken (itt fog megjelenni az utolsó mentés ellenőrzése);
- következő kötetek, amelyek BorgBackup tárolóként működnek (ide kerülnek beillesztésre közvetlenül a mentési adatok).
A működési elv az, hogy külön kötetek jönnek létre minden szerver számára BorgBackup tárolók alatt, ahová a termelési szerverek adatai kerülnek. A tárolók kizárólag adatbeviteli üzemmódban működnek, ami lehetetlenné teszi az adatok szándékos törlését, és a deduplikációnak és a régi biztonsági mentések időszakos tisztításának köszönhetően (megmarad az éves másolat, az utolsó év havi másolatai, az utolsó hónap heti, a legutolsó hét napi, különleges esetekben — az utolsó nap óránkénti: összesen 24 + 7 + 4 + 12 + éves — körülbelül 50 másolat minden szerverhez).
A BorgBackup tárolókban nem aktiválható a csak hozzáadási mód, helyette a ForcedCommand használatos a .ssh/authorized_keys-ben, körülbelül ilyen formában:
from="szerver címe",command="/usr/local/bin/borg serve --append-only --restrict-to-path /home/szervernév/borgbackup/",no-pty,no-agent-forwarding,no-port-forwarding,no-X11-forwarding,no-user-rc AAAAA.......A megadott útvonalon egy wrapper script található, amely a bináris futtatása mellett további folyamatot indít a biztonsági mentés visszaállítására az adatok lehúzása után. Ehhez a wrapper script egy jelzőfájlt hoz létre a megfelelő tároló mellett. Az utolsó biztonsági mentés automatikusan helyreállításra kerül a megfelelő logikai kötetre az adatok feltöltési folyamatának befejezése után.
Ez a konstrukció lehetővé teszi a felesleges biztonsági mentések periódikus tisztítását, valamint megakadályozza, hogy a termelési szerverek bármit is töröljenek a biztonsági mentések tároló szerverén.
Biztonsági mentési folyamat
A biztonsági mentés kezdeményezője magával a dedikált szerverrel vagy VPS-sel történik, mivel ez a séma nagyobb ellenőrzést biztosít a biztonsági mentési folyamat felett. Először az aktív gyökér fájlrendszer állapotának pillanatképét készítjük, amelyet a BorgBackup segítségével feltöltünk a biztonsági mentési tároló szerverre. Az adatok lehúzása után a pillanatképet leválasztjuk és töröljük.
Ha van egy kis adatbázis (legfeljebb 1 GB minden webhelyhez), adatbázis dump készül, amelyet a megfelelő logikai kötetben tárolnak, ott, ahol a webhely többi adatát is elhelyezték, de úgy, hogy a dump ne legyen elérhető a web szerver által. Ha pedig nagyobb adatbázisok vannak – ajánlott a 'forró' adathúzással dolgozni, például az xtrabackup segítségével a MySQL számára, vagy a WAL működésbe állítása az archive_command alatt a PostgreSQL-ben. Ebben az esetben az adatbázist külön kell helyreállítani a webhelyek adataitól.
Ha tartályokat vagy virtuális gépeket használnak – be kell állítani a qemu-guest-agent, CRIU, vagy más szükséges technológiákat. A többi esetben általában nincs szükség további beállításokra – egyszerűen pillanatképeket készítünk a logikai kötetekről, amelyek aztán úgy kerülnek feldolgozásra, mint a gyökér fájlrendszer állapotának pillanatképe. Az adatok lehúzása után a pillanatképeket töröljük.
A további munka a biztonsági mentések tároló szerverén folytatódik:
- ellenőrizzük az utoljára készített biztonsági másolatot minden tárolóban,
- ellenőrizzük a meglétét a zárjegy fájlnak, amely jelzi, hogy az adatok leválasztása befejeződött,
- az adatok kicsomagolása a megfelelő helyi kötetre történik,
- a zárjegy fájl törlésre kerül
A szerver működésének helyreállítási folyamata
Ha a fő szerver meghal, egy hasonló dedikált szerver indul el, amely egy bizonyos standard képből töltődik be. Valószínűleg a betöltés hálózaton keresztül fog történni, azonban a szerver beállítását végző adatközpont technikus azonnal átmásolhatja ezt a standard képet az egyik lemezre. A betöltés a memóriába történik, majd elkezdődik a helyreállítás folyamata:
- lekérdezés készül a blokkeszköz csatlakoztatására az iscsinbd-n vagy egy másik hasonló logikai kötet protokollon keresztül, amely a meghalt szerver gyökeres fájlrendszerét tartalmazza; mivel a gyökeres fájlrendszernek kicsi kell lennie – ezt a lépést néhány percen belül be kell fejezni. A bootloader helyreállítása is megtörténik;
- a helyi logikai kötetek struktúrája újra létrejön, a biztonsági mentési szerver logikai követei a dm_clone kernel modul segítségével csatlakoznak: megkezdődik az adatok helyreállítása, és a módosítások azonnal rögzítésre kerülnek a helyi lemezeken
- elindul egy tartály az összes elérhető fizikai lemezzel - a szerver teljes működésének helyreállítása történik, de csökkentett teljesítménnyel;
- az adatok szinkronizálásának befejezése után a biztonsági mentési szerver logikai követei leválasztásra kerülnek, a tartály leáll, a szerver újraindul;
A szerver újraindítása után meglesznek az összes adatok, amelyek a biztonsági másolat készítésekor voltak, valamint tartalmazni fogja azokat a módosításokat, amelyek a helyreállítás folyamata során történtek.
További ciklus cikkek
Biztonsági mentés, 7. rész: Következtetések
Kérem, hogy a javasolt verziót beszéljük meg a megjegyzésekben, köszönöm a figyelmet!
Forrás: habr.com
