Proč potřebujete zálohovat? Koneckonců, zařízení je velmi, velmi spolehlivé a kromě toho existují „cloudy“, které jsou spolehlivější než fyzické servery: se správnou konfigurací může „cloudový“ server snadno přežít selhání infrastrukturního fyzického serveru. z pohledu uživatelů služeb dojde k malému, sotva znatelnému skoku v časové službě. Duplikace informací navíc často vyžaduje platbu za „extra“ procesorový čas, zatížení disku a síťový provoz.
Ideální program běží rychle, neprosakuje paměť, nemá díry a neexistuje.
-Neznámý
Vzhledem k tomu, že programy stále píší proteinoví vývojáři a často neexistuje žádný testovací proces, navíc jsou programy zřídka dodávány s použitím „osvědčených postupů“ (které samy o sobě jsou také programy, a proto nedokonalé), musí správci systému nejčastěji řešit problémy, které znějí krátce, ale lapidárně: „návrat k tomu, jak to bylo“, „uveďte základnu do normálního provozu“, „funguje pomalu – vraťte se zpět“ a také moje oblíbené „nevím co, ale opravte to“.
Kromě logických chyb, které vznikají v důsledku neopatrné práce vývojářů nebo souhrou okolností, stejně jako neúplné znalosti nebo nepochopení drobných funkcí stavebních programů - včetně těch spojovacích a systémových, včetně operačních systémů, ovladačů a firmwaru - jsou tam i další chyby. Většina vývojářů například spoléhá na runtime a zcela zapomíná na fyzikální zákony, které stále nelze pomocí programů obejít. To zahrnuje nekonečnou spolehlivost diskového subsystému a obecně jakéhokoli subsystému pro ukládání dat (včetně RAM a mezipaměti procesoru!), nulovou dobu zpracování na procesoru a absenci chyb při přenosu po síti a během zpracování na procesor, a latence sítě, která se rovná 0. Notoricky známý termín byste neměli zanedbávat, protože pokud jej nestihnete včas, nastanou problémy horší než nuance provozu sítě a disku.
Co dělat s problémy, které narůstají v plné síle a visí nad cennými daty? Neexistuje nic, co by nahradilo žijící vývojáře, a není pravda, že to bude možné v blízké budoucnosti. Na druhou stranu jen několika málo projektům se podařilo plně prokázat, že program bude fungovat tak, jak bylo zamýšleno, a důkazy nemusí být nutně možné převzít a aplikovat na jiné podobné projekty. Takové důkazy také zaberou spoustu času a vyžadují speciální dovednosti a znalosti, což prakticky minimalizuje možnost jejich použití s ohledem na termíny. Navíc zatím nevíme, jak využít ultrarychlou, levnou a nekonečně spolehlivou technologii pro ukládání, zpracování a přenos informací. Takové technologie, pokud existují, jsou ve formě konceptů nebo - nejčastěji - pouze ve sci-fi knihách a filmech.
Dobří umělci kopírují, skvělí umělci kradou.
—Pablo Picasso.
Nejúspěšnější řešení a překvapivě jednoduché věci se obvykle dějí tam, kde se setkávají na první pohled absolutně neslučitelné pojmy, technologie, znalosti a vědní obory.
Například ptáci a letadla mají křídla, ale navzdory funkční podobnosti - princip fungování v některých režimech je stejný a technické problémy jsou řešeny podobným způsobem: duté kosti, použití pevných a lehkých materiálů atd. - výsledky jsou zcela odlišné, i když velmi podobné. Nejlepší příklady, které vidíme v naší technologii, jsou také z velké části vypůjčeny z přírody: přetlakové prostory lodí a ponorek jsou přímou analogií s kroužkovci; vytváření raidových polí a kontrola integrity dat - duplikování řetězce DNA; stejně jako párové orgány, nezávislost práce různých orgánů na centrálním nervovém systému (automatizace srdce) a reflexy - autonomní systémy na internetu. Přijímání a aplikace hotových řešení „čelem“ je samozřejmě plné problémů, ale kdo ví, možná neexistují žádná jiná řešení.
Kdybych jen věděl, kam spadneš, rozložil bych stébla!
—Běloruské lidové přísloví
To znamená, že záložní kopie jsou životně důležité pro ty, kteří chtějí:
- Buďte schopni obnovit provoz svých systémů s minimálními prostoji nebo dokonce bez nich
- Jednejte směle, protože v případě chyby vždy existuje možnost vrácení zpět
- Minimalizujte následky úmyslného poškození dat
Tady je malá teorie
Jakákoli klasifikace je libovolná. Příroda neklasifikuje. Zařazujeme, protože je to pro nás pohodlnější. A třídíme podle údajů, které také libovolně bereme.
— Jean Bruler
Bez ohledu na způsob fyzického ukládání lze logické úložiště dat rozdělit na dva způsoby přístupu k těmto datům: blok a soubor. Toto rozdělení je v poslední době velmi nejasné, protože čistě blokové, stejně jako čistě souborové, logické úložiště neexistuje. Pro jednoduchost však budeme předpokládat, že existují.
Blokové ukládání dat znamená, že existuje fyzické zařízení, kde jsou data zapisována do určitých pevných částí, bloků. K blokům se přistupuje na určité adrese, každý blok má v zařízení svou vlastní adresu.
Záloha se obvykle provádí zkopírováním bloků dat. Aby byla zajištěna integrita dat, záznam nových bloků, stejně jako změny stávajících, jsou v době kopírování pozastaveny. Vezmeme-li přirovnání z běžného světa, nejbližší věc je skříň se stejně očíslovanými buňkami.
Souborové datové úložiště založené na principu logického zařízení se blíží blokovému úložišti a je často organizováno nahoře. Důležitými rozdíly jsou přítomnost hierarchie úložiště a lidem čitelné názvy. Abstrakce je alokována ve formě souboru - pojmenované datové oblasti, a také adresáře - speciálního souboru, ve kterém jsou uloženy popisy a přístup k dalším souborům. Soubory lze dodat s dalšími metadaty: čas vytvoření, příznaky přístupu atd. Zálohy se obvykle provádějí tímto způsobem: vyhledávají změněné soubory a poté je zkopírují do jiného úložiště souborů se stejnou strukturou. Integrita dat je obvykle realizována absencí souborů, do kterých se zapisuje. Metadata souboru se zálohují stejným způsobem. Nejbližší analogií je knihovna, která má sekce s různými knihami a má také katalog s lidsky čitelnými názvy knih.
V poslední době je někdy popisována další možnost, od které v zásadě začalo ukládání dat do souborů a která má stejné archaické rysy: objektové ukládání dat.
Od úložiště souborů se liší tím, že nemá více než jedno vnoření (ploché schéma) a názvy souborů, i když jsou čitelné pro člověka, jsou stále vhodnější pro zpracování stroji. Při provádění záloh se s úložištěm objektů zachází nejčastěji podobně jako s úložištěm souborů, ale občas existují i jiné možnosti.
— Existují dva typy správců systému, ti, kteří neprovádějí zálohy, a ti, kteří JIŽ dělají.
- Ve skutečnosti existují tři typy: existují také ti, kteří kontrolují, zda lze zálohy obnovit.-Neznámý
Rovněž stojí za to pochopit, že samotný proces zálohování dat provádějí programy, takže má všechny stejné nevýhody jako jakýkoli jiný program. K odstranění (nikoli odstranění!) závislosti na lidském faktoru a také rysů - které jednotlivě nemají silný vliv, ale dohromady mohou dát znatelný efekt - tzv. pravidlo 3-2-1. Existuje mnoho možností, jak to dešifrovat, ale já preferuji následující výklad: potřebujete uložit 3 sady stejných dat, 2 sady je třeba uložit v různých formátech a 1 sada by měla být uložena na geograficky vzdáleném úložišti.
Formát úložiště by měl být chápán takto:
- Pokud existuje závislost na fyzickém způsobu uložení, změníme fyzický způsob.
- Pokud existuje závislost na metodě logického ukládání, změníme logickou metodu.
Pro dosažení maximálního účinku pravidla 3-2-1 se doporučuje změnit formát úložiště oběma způsoby.
Z hlediska připravenosti zálohy pro zamýšlený účel - obnovení funkčnosti - se rozlišuje mezi „horkými“ a „studenými“ zálohami. Horké se liší od studených pouze v jedné věci: jsou okamžitě připraveny k použití, zatímco studené vyžadují některé další kroky pro obnovu: dešifrování, extrahování z archivu atd.
Nezaměňujte horké a studené kopie s online a offline kopiemi, které znamenají fyzickou izolaci dat a ve skutečnosti jsou dalším znakem klasifikace metod zálohování. Offline kopie – nepřímo připojená k systému, kde je potřeba ji obnovit – tedy může být buď horká, nebo studená (z hlediska připravenosti k obnově). Online kopie může být dostupná přímo tam, kde je potřeba ji obnovit, a nejčastěji je horká, ale existují i studená.
Navíc nezapomínejte, že samotný proces vytváření záložních kopií vytvořením jedné záložní kopie většinou nekončí a kopií může být poměrně velké množství. Proto je nutné rozlišovat plné zálohy, tzn. ty, které lze obnovit nezávisle na jiných zálohách, a také rozdílové (přírůstkové, rozdílové, dekrementální atd.) kopie – ty, které nelze obnovit samostatně a vyžadují předběžné obnovení jedné nebo více dalších záloh.
Rozdílové přírůstkové zálohy jsou pokusem ušetřit úložný prostor záloh. Do záložní kopie se tedy zapisují pouze změněná data z předchozí zálohy.
Rozdílové dekrementální jsou vytvořeny pro stejný účel, ale trochu jiným způsobem: vytvoří se úplná záložní kopie, ale ve skutečnosti se uloží pouze rozdíl mezi novou kopií a předchozí.
Samostatně stojí za zvážení proces zálohování přes úložiště, který podporuje absenci ukládání duplikátů. Pokud tedy na něj napíšete úplné zálohy, ve skutečnosti se zapíší pouze rozdíly mezi zálohami, ale proces obnovy záloh bude podobný obnově z plné kopie a zcela transparentní.
Quis custodiet ipsos custodes?
(Kdo bude hlídat samotné hlídače? - lat.)
Je velmi nepříjemné, když neexistují žádné záložní kopie, ale mnohem horší je, když se zdá, že záložní kopie byla vytvořena, ale při obnově se ukáže, že ji nelze obnovit, protože:
- Integrita zdrojových dat byla narušena.
- Záložní úložiště je poškozené.
- Obnova funguje velmi pomalu, nelze použít data, která byla částečně obnovena.
Správně sestavený proces zálohování musí s takovými připomínkami počítat, zejména s prvními dvěma.
Integritu zdrojových dat lze zaručit několika způsoby. Nejčastěji se používají tyto: a) vytváření snímků souborového systému na úrovni bloku, b) „zmrazení“ stavu souborového systému, c) speciální blokové zařízení s ukládáním verzí, d) sekvenční nahrávání souborů popř. bloky. Kontrolní součty se také používají k zajištění ověření dat během obnovy.
Poškození úložiště lze také zjistit pomocí kontrolních součtů. Další metodou je použití specializovaných zařízení nebo souborových systémů, ve kterých již zaznamenaná data nelze měnit, ale lze je přidávat nová.
Pro urychlení obnovy se obnova dat používá s více procesy pro obnovu - za předpokladu, že neexistuje úzké hrdlo v podobě pomalé sítě nebo pomalého diskového systému. Chcete-li obejít situaci s částečně obnovenými daty, můžete proces zálohování rozdělit na relativně malé dílčí úkoly, z nichž každá se provádí samostatně. Je tak možné konzistentně obnovovat výkon a zároveň předvídat dobu obnovy. Tento problém nejčastěji spočívá v organizační rovině (SLA), takže se tím nebudeme podrobně zabývat.
Přeborník na koření není ten, kdo je přidává do každého pokrmu, ale ten, kdo do něj nikdy nepřidává nic navíc.
-V. Sinyavsky
Praxe týkající se softwaru používaného správci systému se může lišit, ale obecné principy jsou stále, tak či onak, stejné, zejména:
- Důrazně se doporučuje používat hotová řešení.
- Programy by měly fungovat předvídatelně, tzn. Neměly by existovat žádné nezdokumentované funkce nebo překážky.
- Nastavení každého programu by mělo být tak jednoduché, abyste nemuseli pokaždé číst manuál nebo cheat sheet.
- Pokud je to možné, řešení by mělo být univerzální, protože hardwarové vlastnosti serverů se mohou značně lišit.
Existují následující běžné programy pro vytváření záloh z blokových zařízení:
- dd, známý veteránům správy systému, zahrnuje také podobné programy (například stejný dd_rescue).
- Nástroje zabudované do některých systémů souborů, které vytvářejí výpis systému souborů.
- Všežravé nástroje; například partclone.
- Vlastní, často vlastnická, rozhodnutí; například NortonGhost a novější.
U souborových systémů je problém zálohování částečně vyřešen pomocí metod použitelných pro bloková zařízení, ale problém lze vyřešit efektivněji například pomocí:
- Rsync, univerzální program a protokol pro synchronizaci stavu systémů souborů.
- Vestavěné archivační nástroje (ZFS).
- archivační nástroje třetích stran; nejoblíbenějším zástupcem je dehet. Existují další, například dar - náhrada dehtu zaměřená na moderní systémy.
Samostatně stojí za zmínku o softwarových nástrojích pro zajištění konzistence dat při vytváření záložních kopií. Nejčastěji používané možnosti jsou:
- Připojení souborového systému v režimu pouze pro čtení (ReadOnly) nebo zmrazení systému souborů (zmrazení) - metoda má omezenou použitelnost.
- Vytváření snímků stavu souborových systémů nebo blokových zařízení (LVM, ZFS).
- Použití nástrojů třetích stran pro organizaci zobrazení, a to i v případech, kdy z nějakého důvodu nelze poskytnout předchozí body (programy jako hotcopy).
- Technika copy-on-change (CopyOnWrite) je však nejčastěji vázána na použitý souborový systém (BTRFS, ZFS).
Takže pro malý server musíte poskytnout schéma zálohování, které splňuje následující požadavky:
- Snadné použití – během provozu nejsou nutné žádné speciální dodatečné kroky, minimální kroky k vytváření a obnově kopií.
- Univerzální - funguje na velkých i malých serverech; to je důležité při zvyšování počtu serverů nebo škálování.
- Instaluje se správcem balíčků nebo jedním nebo dvěma příkazy, jako je „stáhnout a rozbalit“.
- Stabilní – používá se standardní nebo dlouhodobě zavedený formát úložiště.
- Rychle v práci.
Uchazeči z řad těch, kteří více či méně splňují požadavky:
- rdiff-backup
- rsnapshot
- říhnutí
- duplikát
- neupřímnost
- nech dup
- dar
- zbackup
- zbytkový
- borgbackup
Jako testovací stolice bude použit virtuální stroj (založený na XenServeru) s následujícími vlastnostmi:
- 4 jádra 2.5 GHz,
- 16 GB RAM,
- 50 GB hybridní úložiště (úložný systém s mezipamětí na SSD 20 % velikosti virtuálního disku) ve formě samostatného virtuálního disku bez dělení,
- Internetový kanál 200 Mbps.
Téměř stejný stroj bude použit jako záložní přijímací server, pouze s 500 GB pevným diskem.
Operační systém - Centos 7 x64: standardní oddíl, další oddíl bude použit jako zdroj dat.
Jako počáteční data si vezměme web WordPress se 40 GB mediálních souborů a databází mysql. Protože se virtuální servery velmi liší ve vlastnostech a také kvůli lepší reprodukovatelnosti, zde je
výsledky testování serveru pomocí sysbench.sysbench --threads=4 --time=30 --cpu-max-prime=20000 spuštění CPU
sysbench 1.1.0-18a9f86 (pomocí přibaleného LuaJIT 2.1.0-beta3)
Spuštění testu s následujícími možnostmi:
Počet vláken: 4
Inicializace generátoru náhodných čísel z aktuálního času
Limit prvočísel: 20000 XNUMX
Inicializace pracovních vláken…
Vlákna byla spuštěna!
Rychlost procesoru:
událostí za sekundu: 836.69
Propustnost:
události/s (eps): 836.6908
uplynulý čas: 30.0039s
celkový počet událostí: 25104
Latence (ms):
min: 2.38
průměr: 4.78
max: 22.39
95. percentil: 10.46
součet: 119923.64
Spravedlivost vláken:
události (prům./stddev): 6276.0000/13.91
doba provedení (prům./stddev): 29.9809/0.01
sysbench --threads=4 --time=30 --memory-block-size=1K --memory-scope=global --memory-total-size=100G --memory-oper=spuštění paměti pro čtení
sysbench 1.1.0-18a9f86 (pomocí přibaleného LuaJIT 2.1.0-beta3)
Spuštění testu s následujícími možnostmi:
Počet vláken: 4
Inicializace generátoru náhodných čísel z aktuálního času
Spuštění testu rychlosti paměti s následujícími možnostmi:
velikost bloku: 1KiB
celková velikost: 102400MiB
operace: číst
rozsah: globální
Inicializace pracovních vláken…
Vlákna byla spuštěna!
Celkový počet operací: 50900446 (1696677.10 za sekundu)
Přeneseno 49707.47 MiB (1656.91 MiB/s)
Propustnost:
události/s (eps): 1696677.1017
uplynulý čas: 30.0001s
celkový počet událostí: 50900446
Latence (ms):
min: 0.00
průměr: 0.00
max: 24.01
95. percentil: 0.00
součet: 39106.74
Spravedlivost vláken:
události (prům./stddev): 12725111.5000/137775.15
doba provedení (prům./stddev): 9.7767/0.10
sysbench --threads=4 --time=30 --memory-block-size=1K --memory-scope=global --memory-total-size=100G --memory-oper=spuštění paměti pro zápis
sysbench 1.1.0-18a9f86 (pomocí přibaleného LuaJIT 2.1.0-beta3)
Spuštění testu s následujícími možnostmi:
Počet vláken: 4
Inicializace generátoru náhodných čísel z aktuálního času
Spuštění testu rychlosti paměti s následujícími možnostmi:
velikost bloku: 1KiB
celková velikost: 102400MiB
operace: zápis
rozsah: globální
Inicializace pracovních vláken…
Vlákna byla spuštěna!
Celkový počet operací: 35910413 (1197008.62 za sekundu)
Přeneseno 35068.76 MiB (1168.95 MiB/s)
Propustnost:
události/s (eps): 1197008.6179
uplynulý čas: 30.0001s
celkový počet událostí: 35910413
Latence (ms):
min: 0.00
průměr: 0.00
max: 16.90
95. percentil: 0.00
součet: 43604.83
Spravedlivost vláken:
události (prům./stddev): 8977603.2500/233905.84
doba provedení (prům./stddev): 10.9012/0.41
sysbench --threads=4 --file-test-mode=rndrw --time=60 --file-block-size=4K --file-total-size=spuštění souboru 1G
sysbench 1.1.0-18a9f86 (pomocí přibaleného LuaJIT 2.1.0-beta3)
Spuštění testu s následujícími možnostmi:
Počet vláken: 4
Inicializace generátoru náhodných čísel z aktuálního času
Další příznaky otevření souboru: (žádné)
128 souborů, každý 8 MiB
Celková velikost souboru 1GiB
Velikost bloku 4KiB
Počet IO požadavků: 0
Poměr čtení/zápis pro kombinovaný náhodný test IO: 1.50
Povoleno pravidelné FSYNC, volání fsync() každých 100 požadavků.
Volání fsync() na konci testu, povoleno.
Použití synchronního režimu I/O
Provedení náhodného r/w testu
Inicializace pracovních vláken…
Vlákna byla spuštěna!
Propustnost:
čtení: IOPS=3868.21 15.11 MiB/s (15.84 MB/s)
zápis: IOPS=2578.83 10.07 MiB/s (10.56 MB/s)
fsync: IOPS=8226.98
Latence (ms):
min: 0.00
průměr: 0.27
max: 18.01
95. percentil: 1.08
součet: 238469.45
Tato poznámka začíná ve velkém
série článků o zálohování
- Zálohování, část 1: Proč je zálohování potřeba, přehled metod, technologií
- Zálohování, část 2: Kontrola a testování nástrojů zálohování založených na rsync
- Zálohování Část 3: Kontrola a testování duplicity, duplicity, deja dup
- Zálohování Část 4: Kontrola a testování zbackup, restic, borgbackup
- Zálohování, část 5: Testování zálohování bacula a veeam pro linux
- Zálohování Část 6: Porovnání nástrojů pro zálohování
- Záloha Část 7: Závěry
Zdroj: www.habr.com