Zálohovanie Časť 7: Závery

Zálohovanie Časť 7: Závery

Táto poznámka uzatvára cyklus zálohovania. Bude diskutovať o logickej organizácii dedikovaného servera (alebo VPS), vhodnom na zálohovanie, a tiež ponúkne možnosť rýchleho obnovenia servera zo zálohy bez veľkých prestojov v prípade katastrofy.

Surové údaje

Dedikovaný server má najčastejšie aspoň dva pevné disky, ktoré slúžia na usporiadanie poľa RAID prvej úrovne (mirror). Je to potrebné, aby ste mohli pokračovať v prevádzke servera, ak jeden disk zlyhá. Ak ide o bežný dedikovaný server, na SSD môže byť samostatný hardvérový radič RAID s technológiou aktívneho ukladania do vyrovnávacej pamäte, takže okrem bežných pevných diskov je možné pripojiť jeden alebo viacero SSD. Niekedy sa ponúkajú dedikované servery, v ktorých sú jedinými lokálnymi diskami SATADOM (malé disky, konštrukčne flash disk pripojený k portu SATA), alebo aj obyčajný malý (8-16GB) flash disk pripojený na špeciálny interný port a dáta sa berú z úložného systému, ktorý je pripojený prostredníctvom vyhradenej úložnej siete (Ethernet 10G, FC atď.) a existujú dedikované servery, ktoré sa načítavajú priamo z úložného systému. O takýchto možnostiach nebudem uvažovať, pretože v takýchto prípadoch úloha zálohovania servera plynule prechádza na špecialistu, ktorý spravuje úložný systém; zvyčajne existujú rôzne proprietárne technológie na vytváranie snímok, vstavanú deduplikáciu a ďalšie radosti správcu systému. , o ktorom sa hovorilo v predchádzajúcich častiach tejto série. Objem diskového poľa dedikovaného servera môže dosiahnuť niekoľko desiatok terabajtov v závislosti od počtu a veľkosti diskov pripojených k serveru. V prípade VPS sú objemy skromnejšie: zvyčajne nie viac ako 100 GB (ale je ich aj viac) a tarify za takéto VPS môžu byť jednoducho drahšie ako najlacnejšie dedikované servery od toho istého hostiteľa. VPS má najčastejšie jeden disk, pretože pod ním bude úložný systém (alebo niečo hyperkonvergované). Niekedy má VPS niekoľko diskov s rôznymi charakteristikami na rôzne účely:

  • malý systém - na inštaláciu operačného systému;
  • veľké - ukladanie užívateľských dát.

Pri preinštalovaní systému pomocou ovládacieho panela sa disk s používateľskými údajmi neprepíše, ale systémový disk sa úplne zaplní. Aj v prípade VPS môže hostiteľ ponúkať tlačidlo, ktoré urobí snímku stavu VPS (alebo disku), ale ak si nainštalujete vlastný operačný systém alebo zabudnete aktivovať požadovanú službu vo vnútri VPS, niektoré údajov sa stále môže stratiť. Okrem tlačidla sa zvyčajne ponúka služba ukladania dát, najčastejšie veľmi obmedzená. Typicky ide o účet s prístupom cez FTP alebo SFTP, niekedy spolu s SSH, s odstráneným shellom (napríklad rbash) alebo obmedzením spúšťania príkazov cez autorizované kľúče (cez ForcedCommand).

Dedikovaný server je pripojený k sieti dvoma portami s rýchlosťou 1 Gbps, niekedy to môžu byť karty s rýchlosťou 10 Gbps. VPS má najčastejšie jedno sieťové rozhranie. Dátové centrá najčastejšie neobmedzujú rýchlosť siete v rámci dátového centra, ale obmedzujú rýchlosť prístupu na internet.

Typickou záťažou takéhoto dedikovaného servera alebo VPS je webový server, databáza a aplikačný server. Niekedy môžu byť nainštalované rôzne dodatočné pomocné služby, vrátane pre webový server alebo databázu: vyhľadávač, poštový systém atď.

Špeciálne pripravený server slúži ako priestor na ukladanie záložných kópií, podrobnejšie o ňom napíšeme neskôr.

Logická organizácia diskového systému

Ak máte radič RAID alebo VPS s jedným diskom a neexistujú žiadne špeciálne preferencie pre prevádzku diskového subsystému (napríklad samostatný rýchly disk pre databázu), všetok voľný priestor je rozdelený nasledovne: jeden oddiel je vytvorená a nad ňou je vytvorená skupina zväzkov LVM , v nej je vytvorených niekoľko zväzkov: 2 malé zväzky rovnakej veľkosti, používané ako koreňový súborový systém (zmenené jeden po druhom počas aktualizácií pre možnosť rýchleho návratu späť, nápad bol prevzatý z distribúcie Calculate Linux), ďalší je pre swapovací oddiel, zvyšok voľného miesta je rozdelený na malé zväzky, používa sa ako koreňový súborový systém pre plnohodnotné kontajnery, disky pre virtuálne stroje, súbor systémy pre účty v /home (každý účet má svoj vlastný súborový systém), súborové systémy pre kontajnery aplikácií.

Dôležité upozornenie: zväzky musia byť úplne samostatné, t.j. by nemali závisieť od seba alebo od koreňového súborového systému. V prípade virtuálnych strojov alebo kontajnerov sa tento bod sleduje automaticky. Ak ide o aplikačné kontajnery alebo domovské adresáre, mali by ste myslieť na oddelenie konfiguračných súborov webového servera a iných služieb tak, aby sa čo najviac eliminovali závislosti medzi zväzkami. Napríklad každá lokalita beží od vlastného používateľa, konfiguračné súbory lokality sú v domovskom adresári používateľa, v nastaveniach webového servera nie sú konfiguračné súbory lokality zahrnuté cez /etc/nginx/conf.d/.conf a napríklad /home//configs/nginx/*.conf

Ak existuje niekoľko diskov, môžete vytvoriť softvérové ​​pole RAID (a nakonfigurovať jeho ukladanie do vyrovnávacej pamäte na SSD, ak je to potrebné a príležitosť), na ktorom môžete zostaviť LVM podľa vyššie navrhnutých pravidiel. Aj v tomto prípade môžete použiť ZFS alebo BtrFS, ale mali by ste si to dvakrát rozmyslieť: obe vyžadujú oveľa serióznejší prístup k zdrojom a okrem toho ZFS nie je súčasťou linuxového jadra.

Bez ohľadu na použitú schému sa vždy oplatí vopred odhadnúť približnú rýchlosť zápisu zmien na disky a následne vypočítať množstvo voľného miesta, ktoré bude vyhradené na vytváranie snímok. Napríklad, ak náš server zapisuje dáta rýchlosťou 10 megabajtov za sekundu a veľkosť celého dátového poľa je 10 terabajtov - čas synchronizácie môže dosiahnuť jeden deň (22 hodín - toľko sa prenesie taký objem cez sieť 1 Gbps) - oplatí sa rezervovať asi 800 GB . V skutočnosti bude údaj menší, pokojne ho môžete vydeliť počtom logických zväzkov.

Záložné úložné serverové zariadenie

Hlavným rozdielom medzi serverom na ukladanie záložných kópií sú jeho veľké, lacné a relatívne pomalé disky. Keďže moderné HDD už prekročili hranicu 10TB na jednom disku, je potrebné použiť súborové systémy alebo RAID s kontrolnými súčtami, pretože pri prestavbe poľa alebo obnove súborového systému (niekoľko dní!) môže dôjsť k zlyhaniu druhého disku v dôsledku na zvýšenú záťaž. Na diskoch s kapacitou do 1TB to nebolo také citlivé. Pre jednoduchosť popisu predpokladám, že diskový priestor je rozdelený na dve približne rovnako veľké časti (opäť napr. pomocou LVM):

  • zväzky zodpovedajúce serverom používaným na ukladanie používateľských údajov (na ich overenie bude nasadená posledná vytvorená záloha);
  • zväzky používané ako úložiská BorgBackup (údaje pre zálohy pôjdu priamo sem).

Princíp fungovania spočíva v tom, že pre každý server sa vytvárajú samostatné zväzky pre úložiská BorgBackup, kam budú smerovať údaje z bojových serverov. Repozitáre fungujú v režime iba pripájania, čo eliminuje možnosť zámerného vymazávania dát a z dôvodu deduplikácie a pravidelného čistenia úložísk zo starých záloh (zostávajú ročné kópie, mesačné za posledný rok, týždenné za posledný mesiac, denne za minulý týždeň, prípadne v špeciálnych prípadoch - hodinová za posledný deň: spolu 24 + 7 + 4 + 12 + ročne - približne 50 kópií na každý server).
Repozitáre BorgBackup nepovoľujú režim iba pridania; namiesto toho sa používa ForcedCommand v .ssh/authorized_keys takto:

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.......

Zadaná cesta obsahuje na vrchu borg wrapper skript, ktorý okrem spustenia binárky s parametrami navyše spustí proces obnovy záložnej kópie po odstránení dát. Na tento účel vytvorí obalový skript vedľa príslušného úložiska súbor značky. Posledná vytvorená záloha sa po dokončení procesu plnenia údajov automaticky obnoví na zodpovedajúci logický zväzok.

Tento dizajn vám umožňuje pravidelne čistiť nepotrebné zálohy a tiež zabraňuje bojovým serverom vymazať čokoľvek na serveri zálohovania.

Proces zálohovania

Iniciátorom zálohovania je samotný dedikovaný server alebo VPS, pretože táto schéma poskytuje väčšiu kontrolu nad procesom zálohovania zo strany tohto servera. Najprv sa urobí snímka stavu aktívneho koreňového súborového systému, ktorá sa pripojí a odošle pomocou BorgBackup na server zálohovania. Po dokončení zachytávania údajov sa snímka odpojí a odstráni.

Ak existuje malá databáza (do 1 GB pre každú lokalitu), vytvorí sa výpis databázy, ktorý sa uloží do príslušného logického zväzku, kde sa nachádza zvyšok údajov pre tú istú lokalitu, ale tak, aby bol výpis nie sú dostupné cez webový server. Ak sú databázy veľké, mali by ste nakonfigurovať „horúce“ odstraňovanie údajov, napríklad pomocou xtrabackup pre MySQL, alebo pracovať s WAL s príkazom archive_command v PostgreSQL. V tomto prípade bude databáza obnovená oddelene od údajov lokality.

Ak sa používajú kontajnery alebo virtuálne stroje, mali by ste nakonfigurovať qemu-guest-agent, CRIU alebo iné potrebné technológie. V iných prípadoch ďalšie nastavenia najčastejšie nie sú potrebné – jednoducho vytvoríme snímky logických zväzkov, ktoré sa následne spracujú rovnakým spôsobom ako snímka stavu koreňového súborového systému. Po nasnímaní údajov sa snímky vymažú.

Ďalšia práca sa vykonáva na serveri zálohovania:

  • skontroluje sa posledná záloha vytvorená v každom úložisku,
  • skontroluje sa prítomnosť súboru značiek, čo znamená, že proces zberu údajov je dokončený,
  • údaje sa rozšíria na zodpovedajúci lokálny objem,
  • súbor značky sa odstráni

Proces obnovy servera

Ak hlavný server zomrie, spustí sa podobný dedikovaný server, ktorý sa spustí z nejakého štandardného obrazu. Sťahovanie sa s najväčšou pravdepodobnosťou uskutoční cez sieť, ale technik dátového centra, ktorý nastavuje server, môže tento štandardný obraz okamžite skopírovať na jeden z diskov. Sťahovanie sa uskutoční do pamäte RAM, po ktorom sa spustí proces obnovy:

  • požiadavka na pripojenie blokového zariadenia cez iscsinbd alebo iný podobný protokol k logickému zväzku obsahujúcemu koreňový súborový systém zosnulého servera; Keďže koreňový súborový systém musí byť malý, tento krok by mal byť dokončený za niekoľko minút. Bootloader je tiež obnovený;
  • štruktúra lokálnych logických zväzkov je znovu vytvorená, logické zväzky sú pripojené zo záložného servera pomocou modulu jadra dm_clone: ​​spustí sa obnova dát a zmeny sa okamžite zapíšu na lokálne disky
  • spustí sa kontajner so všetkými dostupnými fyzickými diskami - funkčnosť servera je plne obnovená, ale so zníženým výkonom;
  • po dokončení synchronizácie údajov sa logické zväzky zo záložného servera odpoja, kontajner sa vypne a server sa reštartuje;

Po reštarte bude mať server všetky údaje, ktoré tam boli v čase vytvorenia zálohy, a bude obsahovať aj všetky zmeny, ktoré boli vykonané počas procesu obnovy.

Ďalšie články zo série

Zálohovanie, časť 1: Prečo je potrebné zálohovanie, prehľad metód, technológií
Zálohovanie, časť 2: Kontrola a testovanie zálohovacích nástrojov založených na rsync
Zálohovanie Časť 3: Kontrola a testovanie duplicity, duplicity
Zálohovanie Časť 4: Kontrola a testovanie zbackup, restic, borgbackup
Zálohovanie, časť 5: Testovanie Bacula a Veeam Backup pre Linux
Zálohovanie: časť na žiadosť čitateľov: recenzia AMANDA, UrBackup, BackupPC
Zálohovanie Časť 6: Porovnanie nástrojov zálohovania
Zálohovanie Časť 7: Závery

Pozývam vás na diskusiu o navrhovanej možnosti v komentároch, ďakujem za pozornosť!

Zdroj: hab.com

Pridať komentár