Zálohování ve Windows. Zálohování operačního systému Windows do Acronis

Od virů a softwarových chyb, selhání hardwaru nebo lidské chyby existuje mnoho potenciálních nebezpečí infikujících vaše soubory.

Nebo se může stát ještě něco horšího – například ztráta osobních fotografií, hudební knihovny, důležitých obchodních dokumentů – něco, co může být skutečně cenné. Proto je nutné automaticky vytvořit záložní kopii vašeho počítače.

Udělat to sami je velmi obtížné, ale se správným softwarem to bude mnohem jednodušší, než si myslíte. Bez jakýchkoli peněžních výdajů, protože nějaké jsou bezplatné programy pro zálohování a klonování disků.

Pokud chceš, zkopírujte obsah svých dokumentů někde , naklonujte jeden disk na druhý nebo vytvořit zálohu celého systému, Našel jsem mnoho programů, které mohou pomoci.

Záloha akce

Action Backup je možná nejlepší plánované zálohování souborů pro domácí a pracovní počítače. Program je velmi pohodlný, protože kombinuje snadné použití a širokou funkčnost pro provádění záloh. S Action Backup získáte: podporu pro plné, rozdílové, přírůstkové zálohy, automatické* ukládání záloh na FTP servery, CD/DVD, vzdálené síťové zdroje, podporu formátu zip64, podporu funkce stínové kopie, práci v režimu služby Windows *, automatické mazání předchozích (zastaralých) archivů*, zasílání reportu e-mailem a mnoho dalšího (podrobný popis funkčnosti je k dispozici na oficiálních stránkách vývojáře).

Action Backup je ideální pro začátečníky i zkušené uživatele, což z něj činí vynikající nástroj pro zálohování souborů na domácích počítačích, pracovních stanicích a serverech.

* - k dispozici pouze v placené verzi. Na oficiálních stránkách je srovnání verzí.

Aomei Backupper

Pokud máte rádi zálohovací programy, Aomei má jednoduché rozhraní. Vyberte jednotku nebo oddíl, který chcete zálohovat, cílovou jednotku a klikněte Záložník dojde k vytvoření obrazu.

Program má docela dobré nástroje, pokud je potřebujete. Existují možnosti šifrovat nebo komprimovat zálohy. Můžete tvořit přírůstkové nebo rozdílové zálohy pro zvýšení rychlosti. Můžeš obnovit jednotlivé soubory a složky nebo celý obraz a dokonce existují nástroje pro klonování disků a diskových oddílů.

Co bohužel nemůžete Plánované zálohy- musí být spuštěny ručně. Ale jinak Aomei Backupper je vynikající nástroj, s obrovským množstvím funkcí, ale také snadno použitelný.

EASEUS Todo Backup zdarma

Stejně jako většina bezplatných (pro osobní použití) komerčních softwarových programů, EASEUS Todo Backup zdarma má několik omezení - ale balíček má stále více než dostatek funkcí pro většinu lidí.

Program může pracovat jak na základě souboru, tak na bázi záložního souboru, například ručně nebo podle plánu. Jste schopni pracovat s plné nebo přírůstkové zálohy.

Možnost omezit rychlost zápisu snižuje dopad záloh na výkon systému. To je možné v jednotlivých souborech nebo složkách nebo celý obraz pomocí programu pro obnovu disku. A existují také nástroje pro klonování a formátování jednotek.

Na druhou stranu nezískáte žádné šifrování, žádné rozdílové zálohování a získáte pouze diskový Linux (nikoli Windows PE). Ale EASEUS Todo Backup Free nám stále připadá jako skvělý program.

Znovu zálohování a obnovení

Znovu zálohování a obnovení — je nástroj pro zálohování vizualizace s rozdílem. Místo instalace programu si musíte stáhnout velký (249 MB) soubor ISO a vypálit na CD nebo USB disk. Pak z něj stačí nabootovat a spustit jednoduchý nástroj, který dokáže zálohovat váš pevný disk a později jej obnovit.

K dispozici je také nástroj pro obnovu a dokonce i webový prohlížeč, pokud potřebujete vyhledat pomoc s problémem s počítačem.

Program není úplně pohodlný. Zálohování nelze naplánovat, všechny se musí spouštět ručně a možností je velmi málo.

Je ale také snadno použitelný a zdarma pro každého, takže pokud chcete spouštět příležitostnou zálohu, kterou můžete použít na jakémkoli počítači bez instalace softwaru, je tento produkt pro vás.

Záloha Cobian

Záloha Cobian je vynikající zálohovací software se spoustou funkcí. Získáte například plné, rozdílové a přírůstkové zálohy; komprese ZIP nebo 7zip 256bitové šifrování; zahrnout a vyloučit filtry; plánovač, zálohování nebo FTP servery a seznam pokračuje. Každý aspekt programu je extrémně přizpůsobitelný (existuje více než 100 parametrů, které si můžete přizpůsobit).

PC nebo zálohování, začátečníci to budou mít nejspíš velmi těžké. Pokud jste zkušenější, budete milovat množství nástrojů Záloha Cobian vám dává kontrolu nad každým aspektem procesu zálohování.

Macrium Reflect zdarma

Jeden z nejpopulárnějších bezplatných (pro domácí použití) programů pro zobrazování disků, Macrium Reflect zdarma Základní sada funkcí prostřednictvím rozhraní se snadno používá.

Program nemá přírůstkové ani rozdílové zálohy. A nezískáte šifrování ani ochranu heslem. Díky tomu je vytváření záloh velmi snadné (vyberte zdrojový disk a nastavte kompresní poměr, hotovo).

Existuje plánovač; Obrazy můžete připojit v Průzkumníku Windows nebo je zcela obnovit z Linuxu i Obnovovací disky Windows PE. A obecně Macrium Reflect zdarma Vynikající volba pro ty, kteří chtějí jednoduchý, ale spolehlivý nástroj pro zálohování obrazu.

DriveImage XML

Zdarma pro osobní použití, DriveImage XM je snadnou alternativou k pokročilejším konkurentům. Zálohování je stejně snadné jako výběr zdrojové jednotky, cíle a (volitelně) nastavení úrovně komprese.

Obnova je stejně jednoduchá a jedinou významnou výhodou je možnost přímého kopírování z jednoho disku na druhý.

Některé komplikace jsou i jinde. Klikněte na tlačítko „Plánovač úloh“ a obdržíte pokyny k ruční konfiguraci Plánovač úloh systému Windows pro spuštění zálohování. Ale pokud potřebujete pouze základní vykreslovací nástroj, dejte DriveImage XML Rukojeť.

FBackup

FBackup je dobrý nástroj pro zálohování souborů, zdarma pro osobní i komerční použití. Rozhraní je jednoduché a přehledné a obsahuje řadu funkcí.

Pluginy umožňují zálohovat jednotlivé programy jedním kliknutím; existuje podpora pro zahrnutí a vyloučení filtrů; a můžete spouštět zálohy "Mirror", které jednoduše zkopírují vše, aniž by to komprimovaly (což velmi usnadňuje obnovu souborů).

Komprese však není tak dobrá (je to slabý Zip2) a plánovač je také základnější, než uvidíte v jiných programech. Ale pokud jsou vaše potřeby jednoduché FBackup by vám mělo vyhovovat.

Backup Maker

Nejprve zdarma pro osobní použití BackupMaker Vypadá to jako jakýkoli jiný nástroj pro zálohování souborů s dostupnými volitelnými nebo úplnými zálohami, plánováním, kompresí, šifrováním, filtry pro začlenění a vyloučení a tak dále.

Mezi zajímavé doplňkové služby ale patří podpora online zálohování na FTP servery a při výkonu zálohovat automaticky když je připojeno zařízení USB.

Data programu jsou také uložena v souborech Zip, což usnadňuje jejich přístup. A BackUp Maker je dodáván v malém instalačním balíčku o velikosti 6,5 Mb, který je mnohem lépe ovladatelný než někteří z objemných konkurentů.

Pokud jste domácí uživatel, který hledá způsob zálohování souborů, poté zálohovat Výrobce může být perfektní.

Clonezilla

Stejně jako opakování zálohování a obnovení, Clonezilla ne instalační program: je spouštěcí prostředí DOS, který lze spustit z CD nebo USB flash disku.

A je to také velmi výkonný program: budete moci vytvořit obraz disku; obnovit obraz (na jednom disku nebo na několika současně); klonovat disk (zkopírovat jeden disk na druhý) s větší kontrolou.

Zatímco opakované zálohování a obnovení se zaměřuje na snadné použití, Clonezilla více o poskytování dalších možností, jako je „bezobslužný“ Clonezilla přes PXE boot." Není to nic těžkého, asi nejlepší bezplatný program na klonování disků – program je ale zaměřen na zkušené uživatele zálohování, pro začátečníky je lepší najít vhodnější možnost.

Paragon Backup & Recovery 2014 zdarma

Další bezplatný program pro osobní použití, Paragon Backup & Recovery 2014 zdarma
je dobrý nástroj s určitými omezeními.

Silná podpora nadace: můžete vytvořit zálohu obrazu(plné nebo diferenciální), komprimovat a šifrovat jejich použití vylučovací filtry pomoci určit, co je zahrnuto, udělejte plánované zálohy a poté obnovte jednotlivé soubory a složky nebo všechny.

Navíc obsahuje samostatnou část, která pomáhá udržovat vaše zálohy v bezpečí. Součástí je také dobrá sada základních nástrojů.

problémy? Nezískáte přírůstkové zálohy; Nelze klonovat disky ani diskové oddíly a rozhraní někdy nepůsobí příliš dobře. Nicméně Paragon Backup & Recovery 20134 zdarma Kvalitní nástroj a stojí za vaši pozornost.

Duplikát

Pokud potřebujete online zálohy, pak Duplikát je jedním z nejuniverzálnějších nástrojů s podporou ukládání souborů SkyDrive, Google Docs, FTP servery, Amazon S3, Rackspace Cloudfiles a WebDAV.

Program také umí uložit na místní a síťové disky, i když obsahuje spoustu užitečných možností (šifrování AES-256, ochrana heslem, plánovač, úplné a přírůstkové zálohy, podpora regulárních výrazů pro zahrnutí/vyloučení filtrů, dokonce i omezení rychlosti nahrávání a stahování pro snížení dopadu na váš systém).

Ať už tedy ukládáte soubory online nebo lokálně, pak je tento program pro vás.

ALEXEJ BEREZHNOY, Správce systému. Hlavní oblasti činnosti: virtualizace a heterogenní sítě. Dalším koníčkem kromě psaní článků je popularizace svobodného softwaru

Záloha
Teorie a praxe. souhrn

Chcete-li zorganizovat zálohovací systém co nejefektivněji, musíte vytvořit skutečnou strategii pro ukládání a obnovu informací

Zálohování (nebo, jak se také říká, zálohování - z anglického slova „backup“) je důležitým procesem v životě jakékoli IT struktury. Je to padák pro záchranu v případě nepředvídané katastrofy. Zálohování zároveň slouží k vytvoření jakéhosi historického archivu podnikatelské činnosti firmy za určité období jejího života. Pracovat bez zálohy je jako žít pod širým nebem – počasí se může každou chvíli zkazit a není se kam schovat. Jak ji ale správně uspořádat, abyste nepřišli o důležitá data a neutratili za ně fantastické částky?

Články na téma organizace záloh obvykle pojednávají především o technických řešeních a jen občas se věnují teorii a metodice organizace ukládání dat.

V tomto článku budeme hovořit o pravém opaku: hlavní pozornost je věnována obecným pojmům a technických prostředků se dotkneme pouze jako příklady. To nám umožní abstrahovat od hardwaru a softwaru a odpovědět na dvě hlavní otázky: "Proč to děláme?", "Můžeme to udělat rychleji, levněji a spolehlivěji?"

Cíle a cíle zálohování

V procesu organizace zálohování jsou stanoveny dva hlavní úkoly: obnova infrastruktury v případě poruch (Disaster Recovery) a údržba datového archivu za účelem následného zpřístupnění informací za minulá období.

Klasickým příkladem záložní kopie pro zotavení po havárii je obraz systémového diskového oddílu serveru vytvořený aplikací Acronis True Image.

Příkladem archivu může být měsíční stahování databází z 1C, nahrané na magnetofonové pásky a následné uložení na speciálně určené místo.

Existuje několik faktorů, které odlišují zálohu rychlé obnovy od archivu:

• Doba uložení dat. U archivních kopií to trvá poměrně dlouho. V některých případech je upravena nejen obchodními požadavky, ale také zákonem. U kopií obnovy po havárii je to relativně malé. Obvykle vytvoří jednu nebo dvě (se zvýšenými požadavky na spolehlivost) záložní kopie pro zotavení po havárii s maximálním intervalem jednoho nebo dvou dnů, poté jsou přepsány novými. Ve zvláště kritických případech je možné aktualizovat záložní kopii častěji pro obnovu po havárii, například jednou za několik hodin.
• Rychlý přístup k datům. Rychlost přístupu k dlouhodobému archivu není ve většině případů kritická. Potřeba „aktualizovat data za období“ obvykle vzniká v době sesouhlasování dokumentů, návratu k předchozí verzi atd., tedy nikoli v nouzovém režimu. Další věcí je obnova po havárii, kdy je nutné co nejdříve vrátit potřebná data a výkon služby. V tomto případě je extrémně důležitým ukazatelem rychlost přístupu k záloze.
• Složení zkopírovaných informací. Záložní kopie obvykle obsahuje pouze uživatelská a obchodní data po určité období. Kromě těchto dat obsahuje kopie určená pro obnovu po havárii buď bitové kopie systému nebo kopie nastavení operačního systému a aplikačního softwaru, jakož i další informace nezbytné pro obnovu.

Někdy je možné tyto úkoly kombinovat. Například měsíční úplné snímky souborového serveru za rok a změny provedené během týdne. True Image je pro vytvoření takové zálohy vhodným nástrojem.

Nejdůležitější je jasně pochopit, proč se rezervace provádí. Uvedu příklad: kritický SQL server selhal kvůli poruše diskového pole. Správný hardware máme skladem, takže jediným řešením bylo obnovit software a data. Vedení společnosti si klade srozumitelnou otázku: Kdy to začne fungovat? – a je nemile překvapen, když zjistí, že zotavení bude trvat celé čtyři hodiny. Faktem je, že po celou dobu životnosti serveru byly pravidelně zálohovány pouze databáze bez zohlednění nutnosti obnovy samotného serveru se všemi nastaveními, včetně samotného softwaru DBMS. Jednoduše řečeno, naši hrdinové pouze uložili databáze a zapomněli na systém.

Dovolte mi uvést další příklad. Za celou dobu své práce vytvářel mladý specialista pomocí programu ntbackup jedinou kopii souborového serveru se systémem Windows Server 2003, včetně dat a stavu systému ve sdílené složce na jiném počítači. Kvůli omezenému prostoru na disku byla tato kopie neustále přepisována. Po nějaké době byl požádán, aby obnovil předchozí verzi vícestránkové zprávy, která byla při ukládání poškozena. Je jasné, že když neměl archivovanou historii s vypnutou Stínovou kopií, nemohl tento požadavek dokončit.

Na poznámku Stínová kopie, doslova – „stínová kopie“. Zajišťuje, že okamžité kopie systému souborů jsou vytvářeny takovým způsobem, že na ně další změny originálu nemají žádný vliv. Pomocí této funkce je možné vytvořit více skrytých kopií souboru za určitou dobu, stejně jako průběžné záložní kopie souborů otevřených pro zápis. Za provoz stínové kopie je zodpovědná služba Stínová kopie svazku. Stav systému, doslova – „stav systému“. System State Copy vytváří záložní kopie důležitých součástí operačních systémů Windows. To vám umožní obnovit dříve nainstalovaný systém po zničení. Při kopírování Stav systému se uloží registr, boot a další soubory důležité pro systém, včetně pro obnovu Active Directory, databáze Certifikační služby, Registrační databáze COM+Class, adresář SYSVOL. V operačních systémech UNIX je nepřímým analogem kopírování stavu systému uložení obsahu adresářů /etc, /usr/local/etc a dalších souborů nezbytných k obnovení stavu systému.

Co z toho vyplývá: musíte používat oba typy záloh: jak pro obnovu po havárii, tak pro archivaci. V tomto případě je nutné určit seznam zkopírovaných zdrojů, dobu provádění úloh a také kde, jak a jak dlouho budou záložní kopie uloženy.

S malým množstvím dat a nepříliš složitou IT infrastrukturou můžete zkusit spojit oba tyto úkoly v jeden, například vytvořit denní plnou kopii všech diskových oddílů a databází. Stále je ale lepší rozlišovat mezi dvěma cíli a pro každý z nich vybrat ty správné prostředky. Podle toho se pro každou úlohu používá jiný nástroj, i když existují i ​​univerzální řešení, jako je balíček Acronis True Image nebo program ntbackup

Je zřejmé, že při definování cílů a záměrů zálohování, ale i řešení pro implementaci je nutné vycházet z obchodních požadavků.

Při implementaci úlohy zotavení po havárii můžete použít různé strategie.

V některých případech je nutné přímo obnovit systém na holý kov. To lze provést například pomocí programu Acronis True Image s modulem Universal Restore. V tomto případě lze konfiguraci serveru vrátit do provozu ve velmi krátké době. Například je docela možné obnovit oddíl s 20 GB operačním systémem ze zálohy za osm minut (za předpokladu, že záložní kopie je přístupná přes síť 1 Gb/s).

V jiné možnosti je účelnější nastavení jednoduše „vrátit“ do nově nainstalovaného systému, jako je například zkopírování konfiguračních souborů ze složky /etc a dalších v systémech typu UNIX (ve Windows to zhruba odpovídá kopírování a obnovení stavu systému). S tímto přístupem bude server samozřejmě zprovozněn nejdříve po instalaci operačního systému a obnovení potřebných nastavení, což bude trvat mnohem déle. Ale v každém případě rozhodnutí o tom, jaký druh obnovy po havárii by mělo být, vyplývá z potřeb podniku a omezených zdrojů.

Zásadní rozdíl mezi záložními a redundantními redundantními systémy

To je další zajímavá otázka, kterou bych rád položil. Redundantní systémy redundance zařízení znamenají zavedení určité redundance do hardwaru za účelem zachování funkčnosti v případě náhlého selhání jedné z komponent. Vynikajícím příkladem je v tomto případě pole RAID (Redundant Array of Independent Disks). V případě výpadku jednoho disku se můžete vyhnout ztrátě informací a bezpečně je nahradit, čímž ušetříte data díky specifické organizaci samotného diskového pole (více o RAID in).

Slyšel jsem větu: „Máme velmi spolehlivé vybavení, všude máme pole RAID, takže nepotřebujeme zálohy.“ Ano, samozřejmě, stejné pole RAID ochrání data před zničením, pokud selže jeden pevný disk. To vás ale nezachrání před poškozením dat počítačovým virem nebo nešikovnými akcemi uživatelů. RAID vás nezachrání, pokud se souborový systém zhroutí v důsledku neoprávněného restartu.

Mimochodem Důležitost rozlišení zálohování od redundantních systémů by měla být posouzena při sestavování plánu kopírování dat, ať už jde o organizaci nebo domácí počítače. Zeptejte se sami sebe, proč vytváříte kopie. Pokud se bavíme o zálohování, pak to znamená záchranu dat při náhodné (úmyslné) akci. Redundantní redundance umožňuje uložit data, včetně záložních kopií, v případě poruchy zařízení. Nyní je na trhu mnoho levných zařízení, která poskytují spolehlivé zálohování pomocí polí RAID nebo cloudových technologií (například Amazon S3). Doporučuje se používat oba typy zálohování informací současně. Andrey Vasiliev, generální ředitel společnosti Qnap Rusko

Uvedu jeden příklad. Existují případy, kdy se události vyvíjejí podle následujícího scénáře: když dojde k poruše disku, data se obnoví pomocí mechanismu redundance, zejména pomocí uložených kontrolních součtů. V tomto případě dojde k výraznému poklesu výkonu, server zamrzne a kontrola je téměř ztracena. Správce systému, který nevidí jiné východisko, restartuje server studeným restartem (jinými slovy klikne na „RESETOVAT“). V důsledku takového živého přetížení dochází k chybám souborového systému. Nejlepší, co lze v tomto případě očekávat, je, že program kontroly disku poběží dlouhou dobu, aby se obnovila integrita systému souborů. V nejhorším případě se budete muset rozloučit se souborovým systémem a lámat si hlavu nad otázkou, kde, jak a v jakém časovém horizontu můžete obnovit data a výkon serveru.

Zálohám se nevyhnete ani v případě, že máte clusterovou architekturu. Cluster s podporou převzetí služeb při selhání v podstatě zachovává funkčnost služeb, které jsou mu svěřeny, pokud jeden ze serverů selže. V případě výše uvedených problémů, jako je virový útok nebo poškození dat v důsledku notoricky známého „lidského faktoru“, vás žádný cluster nezachrání.

Jediná věc, která může fungovat jako podřadná náhrada zálohy za Disaster Recovery, je přítomnost zrcadlového zálohovacího serveru s neustálou replikací dat z hlavního serveru na záložní (podle principu Primary  Standby). Pokud v tomto případě selže hlavní server, jeho úkoly převezme záložní a nebudete muset ani přenášet data. Ale takový systém je poměrně drahý a pracný na organizaci. Nezapomínejme na nutnost neustálé replikace.

Je zřejmé, že takové řešení je nákladově efektivní pouze v případě kritických služeb s vysokými požadavky na odolnost proti chybám a minimální dobou obnovy. Tyto programy se zpravidla používají ve velmi velkých organizacích s vysokým obratem komodit a hotovosti. A toto schéma je podřadnou náhradou zálohování, protože v každém případě, pokud jsou data poškozena počítačovým virem, nešikovnými akcemi uživatele nebo nesprávným provozem aplikace, mohou být ovlivněna data a software na obou serverech.

A samozřejmě žádný redundantní zálohovací systém nevyřeší problém s udržováním archivu dat po určitou dobu.

Koncept „záložního okna“

Provádění zálohování silně zatěžuje zálohovaný server. To platí zejména pro diskový subsystém a síťová připojení. V některých případech, kdy má proces kopírování poměrně vysokou prioritu, to může vést k nedostupnosti určitých služeb. Kromě toho je kopírování dat v době provádění změn spojeno se značnými obtížemi. Samozřejmě existují technické prostředky, jak se v tomto případě vyhnout problémům při zachování integrity dat, ale pokud je to možné, je lepší se takovému kopírování za běhu vyhnout.

Řešení výše popsaných problémů se nabízí samo: odložit začátek procesu vytváření kopie na dobu nečinnosti, kdy bude vzájemné ovlivňování zálohovacích a ostatních běžících systémů minimální. Toto časové období se nazývá „okno zálohování“. Například pro organizaci fungující podle vzorce 8x5 (pět osmihodinových pracovních dnů v týdnu) jsou takovým „oknem“ obvykle víkendy a noční hodiny.

U systémů pracujících podle vzorce 24x7 (celý týden 24 hodin) se jako období minimální aktivity používá období, kdy nedochází k vysokému zatížení serverů.

Typy zálohování

Aby se předešlo zbytečným nákladům na materiál při organizování záloh a také pokud možno nepřekračovali zálohovací okno, bylo vyvinuto několik zálohovacích technologií, které se používají v závislosti na konkrétní situaci.

Úplná záloha (nebo Úplná záloha)

Je to hlavní a základní metoda vytváření záložních kopií, při které se celé zkopíruje vybrané pole dat. Jedná se o nejúplnější a nejspolehlivější typ zálohování, i když je nejdražší. Pokud je nutné uložit několik kopií dat, celkový uložený objem se zvýší úměrně jejich počtu. Aby se tomuto plýtvání zabránilo, používají se kompresní algoritmy a také kombinace této metody s jinými typy zálohování: přírůstkové nebo rozdílové. A samozřejmě, úplná záloha je nepostradatelná, když potřebujete připravit záložní kopii pro rychlou obnovu systému od nuly.

Přírůstková kopie

Na rozdíl od úplné zálohy se v tomto případě nezkopírují všechna data (soubory, sektory atd.), ale pouze ta, která se od poslední kopie změnila. K určení doby zálohování lze použít různé metody, například na systémech s operačními systémy Windows se používá odpovídající atribut souboru (archivační bit), který se nastaví, když je soubor upraven a resetován zálohovacím programem. Jiné systémy mohou použít datum změny souboru. Je jasné, že schéma využívající tento typ zálohy bude neúplné, pokud nebude čas od času provedena plná záloha. Při provádění úplné obnovy systému je třeba provést obnovu z poslední kopie vytvořené pomocí Úplné zálohy a poté střídavě „srolovat“ data z přírůstkových kopií v pořadí, v jakém byly vytvořeny.

K čemu se tento typ kopírování používá? V případě vytváření archivních kopií je nutné snížit spotřebované svazky na úložných zařízeních (například snížit počet použitých páskových médií). To také minimalizuje čas potřebný k dokončení úloh zálohování, což může být extrémně důležité v podmínkách, kdy musíte pracovat v nabitém programu 24 hodin denně, 7 dní v týdnu nebo pumpovat velké objemy informací.

Existuje jedno upozornění na postupné kopírování, které musíte vědět. Obnova krok za krokem také vrátí potřebné smazané soubory během období obnovy. Dovolte mi uvést příklad. Řekněme, že o víkendech se provádí úplná kopie a ve všední dny přírůstková. Uživatel vytvořil soubor v pondělí, v úterý jej změnil, ve středu přejmenoval a ve čtvrtek smazal. Takže při postupné, postupné obnově dat po týdenní období obdržíme dva soubory: se starým názvem v úterý před přejmenováním a s novým jménem vytvořeným ve středu. Stalo se to proto, že různé přírůstkové kopie ukládaly různé verze stejného souboru a nakonec by byly všechny verze obnoveny. Proto při postupném obnovování dat z archivu „tak jak jsou“ má smysl vyhradit si více místa na disku, aby se vešly i smazané soubory.

Rozdílová záloha

Od přírůstkové se liší tím, že data se kopírují od posledního okamžiku úplné zálohy. Data jsou v archivu ukládána na „kumulativní bázi“. V systémech řady Windows je tohoto efektu dosaženo tím, že archivní bit není resetován během rozdílového kopírování, takže změněná data skončí v archivní kopii, dokud úplná kopie neresetuje archivní bity.

Vzhledem k tomu, že každá takto vytvořená nová kopie obsahuje data z předchozí, je to výhodnější pro kompletní obnovu dat v době katastrofy. K tomu potřebujete pouze dvě kopie: úplnou a poslední z rozdílových, takže data můžete vrátit k životu mnohem rychleji, než postupně rozbalovat všechny přírůstky. Tento typ kopírování navíc neobsahuje výše uvedené funkce přírůstkového kopírování, kdy se po úplné obnově staré soubory jako pták Phoenix znovu zrodí z popela. Je tam menší zmatek.

Rozdílové kopírování je však výrazně horší než přírůstkové kopírování v úspoře požadovaného místa. Protože každá nová kopie ukládá data z předchozích, celkový objem rezervovaných dat může být srovnatelný s úplnou kopií. A samozřejmě při plánování plánu (a výpočtu, zda se proces zálohování vejde do časového okna), musíte vzít v úvahu čas potřebný k vytvoření poslední, nejtlustší, rozdílové kopie.

Záložní topologie

Podívejme se, jaká existují schémata zálohování.

Decentralizované schéma

Jádrem tohoto schématu je určitý sdílený síťový zdroj (viz obr. 1). Například sdílená složka nebo FTP server. Je také vyžadována sada zálohovacích programů, které čas od času nahrávají informace ze serverů a pracovních stanic a také další síťové objekty (například konfigurační soubory ze směrovačů) do tohoto zdroje. Tyto programy jsou nainstalovány na každém serveru a fungují nezávisle na sobě. Nespornou výhodou je snadná implementace tohoto schématu a jeho nízké náklady. Jako kopírovací programy jsou vhodné standardní nástroje zabudované do operačního systému nebo softwaru, jako je DBMS. Může to být například program ntbackup pro rodinu Windows, program tar pro operační systémy typu UNIX nebo sada skriptů obsahujících vestavěné příkazy SQL serveru pro uvolnění databází do záložních souborů. Další výhodou je možnost používat různé programy a systémy, pokud mají všechny přístup k cílovému prostředku pro ukládání záložních kopií.

Nevýhodou je nemotornost tohoto schématu. Protože se programy instalují nezávisle na sobě, je třeba každý z nich nakonfigurovat samostatně. Je poměrně obtížné vzít v úvahu zvláštnosti harmonogramu a rozdělit časové intervaly, aby se zabránilo konkurenci o cílový zdroj. Sledování je také obtížné; proces kopírování z každého serveru musí být monitorován odděleně od ostatních, což může vést k vysokým mzdovým nákladům.

Proto se toto schéma používá v malých sítích, stejně jako v situacích, kdy není možné zorganizovat centralizované schéma zálohování pomocí dostupných prostředků. Podrobnější popis tohoto schématu a praktické uspořádání naleznete v.

Centralizované zálohování

Na rozdíl od předchozího schématu je v tomto případě použit jasný hierarchický model pracující na principu klient-server. V klasické verzi jsou na každém počítači instalovány speciální agentské programy a serverový modul softwarového balíku je instalován na centrální server. Tyto systémy mají také specializovanou konzolu pro správu backendu. Schéma ovládání je následující: z konzole vytváříme úlohy pro kopírování, obnovu, sběr systémových informací, diagnostiku atd. a server dává agentům potřebné instrukce k provádění těchto operací.

Právě na tomto principu funguje většina oblíbených zálohovacích systémů, jako je Symantec Backup Exec, CA Bright Store ARCServe Backup, Bacula a další (viz obr. 2).

Kromě různých agentů pro většinu operačních systémů existuje vývoj pro zálohování populárních databází a podnikových systémů, například pro MS SQL Server, MS Exchange, Oracle Database a tak dále.

Pro velmi malé společnosti můžete v některých případech vyzkoušet zjednodušenou verzi schématu centralizovaného zálohování bez použití agentských programů (viz obr. 3). Toto schéma lze také použít, pokud pro použitý zálohovací software není implementován speciální agent. Místo toho bude serverový modul využívat již existující služby. Například „seškrabujte“ data ze skrytých sdílených složek na serverech Windows nebo kopírujte soubory přes SSH ze serverů se systémy UNIX. Toto schéma má velmi významná omezení spojená s problémy ukládání souborů otevřených pro zápis. V důsledku těchto akcí budou otevřené soubory buď přeskočeny a nebudou zahrnuty do záložní kopie, nebo budou zkopírovány s chybami. Existují různá řešení tohoto problému, například spuštění úlohy znovu, aby se zkopírovaly pouze dříve otevřené soubory, ale žádná z nich není spolehlivá. Proto je toto schéma vhodné použít pouze v určitých situacích. Například v malých organizacích pracujících v režimu 5x8 s disciplinovanými zaměstnanci, kteří ukládají změny a zavírají soubory, než odejdou domů. ntbackup je dobrou volbou pro organizaci takového zkráceného centralizovaného schématu, které funguje výhradně v prostředí Windows. Pokud potřebujete použít podobné schéma v heterogenních prostředích nebo výhradně mezi počítači UNIX, doporučuji se poohlédnout po Backup PC (viz).

Obrázek 4. Smíšené schéma zálohování

Co je mimo místo?

V našem turbulentním, měnícím se světě mohou nastat události, které mohou způsobit nepříjemné důsledky pro IT infrastrukturu a podnikání jako celek. Například požár v budově. Nebo porucha baterie ústředního topení v serverovně. Nebo banální krádež zařízení a komponentů. Jednou z metod, jak se v takových situacích vyhnout ztrátě informací, je ukládat zálohy do umístění mimo hlavní umístění. serverové zařízení. Zároveň je nutné zajistit rychlý způsob přístupu k datům nezbytným pro obnovu. Popsaná metoda se nazývá off-site (jinými slovy ukládání kopií mimo území podniku). V zásadě se používají dva způsoby organizace tohoto procesu.

Zápis dat na vyměnitelná média a jejich fyzický přesun. V tomto případě musíte zvážit způsob, jak rychle získat média zpět v případě selhání. Uložte je například v sousední budově. Výhodou této metody je možnost bez problémů organizovat tento proces. Nevýhodou je obtížnost vracení médií a samotná nutnost přenášet informace pro skladování a také riziko poškození médií při přepravě.

Kopírování dat na jiné místo přes síťové spojení. Například pomocí VPN tunelu přes internet. Výhodou v tomto případě je, že není potřeba někam dopravovat média s informacemi, nevýhodou nutnost použít dostatečně široký kanál (ten je zpravidla velmi drahý) a chránit přenášená data (např. stejná VPN). Potíže při přenosu velkých objemů dat lze výrazně snížit použitím kompresních algoritmů nebo deduplikační technologie.

Samostatně stojí za zmínku o bezpečnostních opatřeních při organizaci ukládání dat. V první řadě je třeba dbát na to, aby se datové nosiče nacházely v zabezpečeném prostoru a aby byla přijata opatření, která zabrání neoprávněným osobám číst data. Například používat šifrovací systém, uzavírat smlouvy o mlčenlivosti a podobně. Pokud je použito vyměnitelné médium, musí být data na něm také šifrována. Použitý systém označování by útočníkovi neměl pomoci při analýze dat. Pro označení médií jmen přenášených souborů je nutné použít anonymní číslování. Při přenosu dat po síti je nutné (jak již bylo zmíněno výše) použít bezpečné metody přenosu dat, například VPN tunel.

Probrali jsme hlavní body při organizování zálohy. V další části budou diskutována metodická doporučení a uvedeny praktické příklady pro vytvoření efektivního zálohovacího systému.

1. Popis zálohování ve Windows, včetně stavu systému - http://www.datamills.com/Tutorials/systemstate/tutorial.htm.
2. Popis stínové kopie - http://ru.wikipedia.org/wiki/Shadow_Copy.
3. Oficiální stránky Acronis – http://www.acronis.ru/enterprise/products.
4. Popis ntbackup - http://en.wikipedia.org/wiki/NTBackup.
5. Berezhnoy A. Optimalizace provozu MS SQL Server. //Správce systému, č. 1, 2008 – str. 14-22 ().
6. Berezhnoy A. Organizujeme záložní systém pro malé a středně velké kanceláře. //Správce systému, č. 6, 2009 – s. 14-23 ().
7. Markelov A. Linux střežící Windows. Kontrola a instalace zálohovacího systému BackupPC. //Správce systému, č. 9, 2004 – S. 2-6 ().
8. Popis VPN – http://ru.wikipedia.org/wiki/VPN.
9. Deduplikace dat – http://en.wikipedia.org/wiki/Data_deduplication.

V kontaktu s

Příprava nového serveru k provozu by měla začít nastavením zálohy. Zdá se, že o tom všichni vědí - ale někdy i zkušení správci systému dělají neomluvitelné chyby. A nejde jen o to, že úkol nastavení nového serveru je třeba vyřešit velmi rychle, ale také o to, že není vždy jasné, jakou metodu zálohování použít.

Samozřejmě nelze vytvořit ideální metodu, která by vyhovovala všem: vše má své pro a proti. Ale zároveň se zdá docela reálné zvolit metodu, která nejlépe vyhovuje specifikům konkrétního projektu.

Při výběru způsobu zálohování musíte nejprve věnovat pozornost následujícím kritériím:

1. Rychlost (čas) zálohování do úložiště;
2. Rychlost (čas) obnovy ze záložní kopie;
3. Kolik kopií lze uchovat s omezenou velikostí úložiště (server zálohování);
4. Objem rizik způsobených nekonzistentností záložních kopií, nevyvinutým způsobem provádění záloh, úplnou nebo částečnou ztrátou záloh;
5. Režijní náklady: úroveň zatížení vytvořeného na serveru při provádění kopie, snížení rychlosti odezvy služby atd.
6. Cena pronájmu všech využívaných služeb.

V tomto článku si povíme o hlavních metodách zálohování serverů se systémy Linux a o nejčastějších problémech, se kterými se mohou začátečníci setkat v této velmi důležité oblasti správy systému.

Schéma pro uspořádání úložiště a obnovy ze záložních kopií

Při výběru organizačního schématu metody zálohování byste měli věnovat pozornost následujícím základním bodům:

1. Zálohy nelze ukládat na stejné místo jako zálohovaná data. Pokud zálohu uložíte na stejné diskové pole jako vaše data, při poškození hlavního diskového pole o ni přijdete.
2. Mirroring (RAID1) nelze srovnávat se zálohováním. Raid vás chrání pouze před hardwarovým problémem s jedním z disků (a dříve nebo později k takovému problému dojde, protože diskový subsystém je téměř vždy úzkým hrdlem serveru). Navíc při použití hardwarových raidů hrozí selhání řadiče, tzn. musíte si nechat náhradní model.
3. Pokud zálohy ukládáte v rámci jednoho racku v DC nebo jednoduše v rámci jednoho DC, pak v této situaci existují i ​​určitá rizika (o tom si můžete přečíst např.
4. Pokud ukládáte záložní kopie v různých DC, náklady na síť a rychlost obnovy ze vzdálené kopie se prudce zvýší.

Často je důvodem pro obnovu dat poškození systému souborů nebo disků. Tito. zálohy musí být uloženy někde na samostatném úložném serveru. V tomto případě může být problémem „šířka“ kanálu přenosu dat. Pokud máte dedikovaný server, je velmi vhodné provádět zálohy na samostatném síťovém rozhraní a ne na stejném rozhraní, které si vyměňuje data s klienty. V opačném případě se požadavky vašeho klienta nemusí „vejít“ do omezeného komunikačního kanálu. Nebo z důvodu zákaznického provozu nebudou zálohy provedeny včas.

Dále je třeba se zamyslet nad schématem a dobou obnovy dat z hlediska ukládání záloh. Můžete být docela spokojeni se zálohou dokončenou za 6 hodin v noci na úložišti s omezenou rychlostí přístupu, ale 6hodinová obnova vám pravděpodobně nebude vyhovovat. To znamená, že přístup k záložním kopiím by měl být pohodlný a data by měla být kopírována dostatečně rychle. Takže například obnova 1TB dat s šířkou pásma 1Gb/s zabere téměř 3 hodiny, a to v případě, že nejste limitováni výkonem diskového subsystému v úložišti a serveru. A k tomu nezapomeňte přičíst čas potřebný k odhalení problému, čas potřebný k rozhodnutí o vrácení zpět, čas potřebný ke kontrole integrity obnovených dat a množství následné nespokojenosti mezi klienty/kolegy .

Přírůstkové zálohování

Na přírůstkové záloha zkopíruje pouze soubory, které se od předchozí zálohy změnily. Následné přírůstkové zálohy přidávají pouze soubory, které se od té předchozí změnily. V průměru zaberou přírůstkové zálohy méně času, protože se zkopíruje méně souborů. Proces obnovy dat však trvá déle, protože je nutné obnovit data z poslední úplné zálohy a data ze všech následujících přírůstkových záloh. V tomto případě, na rozdíl od rozdílového kopírování, změněné nebo nové soubory nenahrazují staré, ale jsou přidány na médium nezávisle.

Přírůstkové kopírování se nejčastěji provádí pomocí nástroje rsync. S jeho pomocí můžete ušetřit úložný prostor, pokud počet změn za den není příliš velký. Pokud jsou změněné soubory velké, budou zcela zkopírovány, aniž by byly nahrazeny předchozí verze.

Proces zálohování pomocí rsync lze rozdělit do následujících kroků:

1. Sestaví se seznam souborů na redundantním serveru a v úložišti, pro každý soubor se načtou metadata (oprávnění, čas úpravy atd.) nebo kontrolní součet (při použití klíče —checksum).
2. Pokud se metadata souborů liší, pak se soubor rozdělí do bloků a pro každý blok se vypočítá kontrolní součet. Bloky, které se liší, jsou nahrány do úložiště.
3. Pokud je v souboru provedena změna během výpočtu kontrolního součtu nebo přenosu souboru, jeho záloha se opakuje od začátku.
4. Ve výchozím nastavení rsync přenáší data přes SSH, což znamená, že každý blok dat je navíc šifrován. Rsync lze také spustit jako démona a přenášet data bez šifrování pomocí jeho protokolu.

Podrobnější informace o tom, jak rsync funguje, najdete na oficiálních stránkách.

Pro každý soubor rsync provádí velmi velké množství operací. Pokud je na serveru mnoho souborů nebo je procesor silně zatížen, rychlost zálohování se výrazně sníží.

Ze zkušenosti můžeme říci, že problémy na SATA discích (RAID1) začínají po cca 200G dat na serveru. Ve skutečnosti vše samozřejmě závisí na počtu inodů. A v každém případě se tato hodnota může posunout jedním nebo druhým směrem.

Po určité době bude doba provádění zálohy velmi dlouhá nebo jednoduše nebude dokončena za den.

Aby se neporovnávaly všechny soubory, je tu lsyncd. Tento démon shromažďuje informace o změněných souborech, tzn. jejich seznam již budeme mít pro rsync připravený předem. Je však třeba vzít v úvahu, že to navíc zatěžuje diskový subsystém.

Rozdílová záloha

Na rozdíl V záloze se pokaždé zálohuje každý soubor, který se od poslední úplné zálohy změnil. Rozdílové kopírování urychluje proces obnovy. Vše, co potřebujete, je nejnovější plná a nejnovější rozdílová záloha. Rozdílové zálohování je stále oblíbenější, protože všechny kopie souborů jsou vytvářeny v určitých okamžicích, což je například velmi důležité při infikování viry.

Rozdílové zálohování se provádí například pomocí nástroje, jako je rdiff-backup. Při práci s touto utilitou vznikají stejné problémy jako u přírůstkových záloh.

Obecně platí, že pokud při hledání rozdílů v datech provádíte úplné prohledávání souborů, problémy tohoto druhu zálohování jsou podobné problémům s rsync.

Rádi bychom zvlášť poznamenali, že pokud je ve vašem schématu zálohování každý soubor zkopírován samostatně, pak se vyplatí smazat/vyloučit soubory, které nepotřebujete. Mohou to být například CMS cache. Takové cache obvykle obsahují mnoho malých souborů, jejichž ztráta neovlivní správný chod serveru.

Plná záloha

Úplná záloha obvykle ovlivní celý váš systém a všechny soubory. Týdenní, měsíční a čtvrtletní zálohy zahrnují vytvoření kompletní kopie všech dat. Obvykle se provádí v pátek nebo o víkendu, kdy kopírování velkého množství dat nemá vliv na práci organizace. Následné zálohy, prováděné od pondělí do čtvrtka až do další úplné zálohy, mohou být rozdílové nebo přírůstkové, především z důvodu úspory času a úložného prostoru. Úplné zálohování by mělo být prováděno alespoň jednou týdně.

Většina souvisejících publikací doporučuje provádět úplnou zálohu jednou nebo dvakrát týdně a po zbytek času používat přírůstkové a rozdílové zálohy. Taková rada má svůj důvod. Ve většině případů stačí úplná záloha jednou týdně. Má smysl jej znovu spustit, pokud nemáte možnost aktualizovat plnou zálohu na straně úložiště a zajistit správnost záložní kopie (to může být nutné například v případech, kdy z toho či onoho důvodu nedůvěřujte skriptům, které máte, ani zálohovacímu softwaru.

Ve skutečnosti lze úplnou zálohu rozdělit na 2 části:

1. Úplná záloha na úrovni systému souborů;
2. Úplné zálohování na úrovni zařízení.

Podívejme se na jejich charakteristické rysy na příkladu:
root@komarov:~# df -h Velikost souborového systému Použitá Avail Použití % Namontováno na /dev/mapper/komarov_system-root 3.4G 808M 2.4G 25 % / /dev/mapper/komarov_system-home 931G 439G 493G 3M 48 % /houde 4.0K 383M 1% /dev tmpfs 107M 104K 107M 1% /run tmpfs 531M 0 531M 0% /tmp žádný 5.0M 0 5.0M 0% /run/lock žádný 531M 0% / 531M 0% /1devsh 22M 109M 17% /bot

Budeme pouze rezervovat / domů. Vše ostatní lze rychle obnovit ručně. Můžete také nasadit server se systémem správy konfigurace a připojit k němu náš /home.

Úplná záloha na úrovni souborového systému

Typický představitel: skládka.

Nástroj vytvoří „dump“ systému souborů. Můžete vytvořit nejen plnou, ale i přírůstkovou zálohu. dump pracuje s tabulkou inodů a „rozumí“ struktuře souborů (takže řídké soubory jsou komprimovány).
Vypisování spuštěného systému souborů je „hloupé a nebezpečné“, protože systém souborů se může během vytváření výpisu změnit. Musí být vytvořen ze snímku (o něco později podrobněji probereme funkce práce se snímky), připojeného nebo zmrazeného souborového systému.

Toto schéma také závisí na počtu souborů a doba jeho provádění se prodlužuje s množstvím dat na disku. Dump má zároveň vyšší provozní rychlost než rsync.
Pokud potřebujete obnovit ne celou záložní kopii, ale například pouze několik náhodně poškozených souborů), může načítání takových souborů pomocí nástroje pro obnovu trvat příliš dlouho.

Úplné zálohování na úrovni zařízení

1. mdraid a DRBD
   Ve skutečnosti je RAID1 nakonfigurován s diskem/raidem na serveru a síťovou jednotkou a čas od času (podle frekvence zálohování) je další disk synchronizován s hlavním diskem/raidem na serveru.

   Největší plus je rychlost. Délka synchronizace závisí pouze na počtu změn provedených za poslední den.
   Tento zálohovací systém se používá poměrně často, ale málokdo si uvědomuje, že záložní kopie získané s jeho pomocí mohou být neúčinné a zde je důvod. Po dokončení synchronizace disku se disk obsahující záložní kopii odpojí. Pokud například provozujeme DBMS, který po částech zapisuje data na lokální disk a ukládá mezilehlá data do mezipaměti, není zaručeno, že skončí i na záložním disku. V nejlepším případě přijdeme o některá měněná data. Proto lze takové zálohy jen stěží považovat za spolehlivé.

2. LVM+dd
   Snímky jsou skvělým nástrojem pro vytváření konzistentních záloh. Před vytvořením snímku musíte resetovat mezipaměť FS a vašeho softwaru na diskový subsystém.

Například se samotným MySQL by to vypadalo takto:
$ sudo mysql -e "VYPLACHOVAT TABULKY SE ZÁMEKEM ČTENÍ;" $ sudo mysql -e "FLUSH LOGS;" $ sudo sync $ sudo lvcreate -s -p r -l100%zdarma -n %s_backup /dev/vg/%s $ sudo mysql -e "ODEMKNUTÍ TABULEK;"

* Kolegové vyprávějí příběhy o tom, jak něčí „zámek čtení“ někdy vedl k uváznutí, ale v mé paměti se to nikdy nestalo.

Zálohy DBMS lze vytvářet samostatně (například pomocí binárních protokolů), čímž se eliminují prostoje při resetování mezipaměti. Můžete také vytvořit výpisy v úložišti spuštěním instance DBMS tam. Zálohování různých DBMS je téma pro samostatné publikace.

Snímek můžete zkopírovat pomocí obnovení (například rsync s opravou pro kopírování blokových zařízení bugzilla.redhat.com/show_bug.cgi?id=494313), můžete blokovat po bloku a bez šifrování (netcat, ftp). Bloky můžete přenášet v komprimované podobě a připojit je do úložiště pomocí AVFS a na server připojit oddíl se zálohami přes SMB.

Komprese odstraňuje problémy s přenosovou rychlostí, přetížením kanálů a úložným prostorem. Pokud však nepoužíváte AVFS v úložišti, pak vám obnovení pouze části dat zabere spoustu času. Pokud používáte AVFS, setkáte se s jeho „vlhkostí“.
Alternativou k blokové kompresi je squashfs: k serveru můžete připojit například oddíl Samba a spustit mksquashfs, ale tento nástroj pracuje i se soubory, tzn. závisí na jejich množství.

Při vytváření squashfů se navíc plýtvá poměrně hodně RAM, což může snadno vést k volání oom-killer.

Bezpečnost

Je nutné se chránit před situací, kdy dojde k napadení úložiště nebo vašeho serveru. Pokud je server hacknutý, je lepší, aby uživatel, který tam zapisuje data, neměl práva na mazání/změnu souborů v úložišti.
Pokud je úložiště hacknuto, pak je také vhodné maximálně omezit práva uživatele zálohování na serveru.

Pokud lze záložní kanál odposlouchávat, je nutné šifrování.

Závěr

Každý zálohovací systém má svá pro a proti. V tomto článku jsme se pokusili zdůraznit některé nuance při výběru zálohovacího systému. Doufáme, že pomohou našim čtenářům.

V důsledku toho musíte při výběru zálohovacího systému pro váš projekt provést testy vybraného typu zálohování a věnovat pozornost:

• čas zálohování v aktuální fázi projektu;
• doba zálohování v případě, že je dat mnohem více;
• zatížení kanálu;
• zatížení diskového subsystému na serveru a v úložišti;
• čas na obnovení všech dat;
• doba obnovy pro dvojici souborů;
• potřeba konzistence dat, zejména databází;
• spotřeba paměti a přítomnost volání oom-killer;

Jako zálohovací řešení můžete použít supload a naše cloudové úložiště.
Čtenáři, kteří zde nemohou zanechat komentáře, jsou zváni, aby se k nám přidali na blogu.

Štítky: Přidat štítky

29.10.2012 Michel Poulet

Zálohování databáze je nejjednodušší a nejlevnější způsob zajištění bezpečnosti firemních dat. Nenechte se ukolébat falešným pocitem bezpečí, který přichází s nasazením nejnovějšího systému vysoké dostupnosti. Pokud jsou všechna data virtualizována a konsolidována, rizika se dokonce zvyšují

Michel Poulet ( [e-mail chráněný])-editor časopisu SQL Server Pro, spoluzakladatel Mount Vernon Data Systems a Six Sigma Uptime.

Většina společností, které existují již dlouhou dobu, zažila katastrofické události, které je mohly vyřadit z provozu, například selhání databáze. Záloha databáze je kopie dat, struktur a objektů zabezpečení obsažených v databázi. Každá databáze musí být zálohována podle jiného plánu na základě počtu transakcí zápisu provedených za den. Pro minimalizaci ztrát v případě výpadku databáze je nutné zálohovat všechny databáze používané v podniku. A abyste se ujistili, že zálohy jsou funkční, měli byste po operacích obnovení zkontrolovat jejich fungování. Minimálně je potřeba mít kopie databází vhodné pro rychlou obnovu a samotná operace obnovy musí být zpracována a nezpůsobovat potíže.

Po zaměstnancích a zákaznících jsou nejcennějším aktivem firem data. Je odpovědností správce databáze zajistit integritu dat tak, aby bylo možné databáze obnovit i v případě úplného zničení datového centra. Zálohování databáze je nejjednodušší a nejlevnější způsob zajištění bezpečnosti firemních dat.

Nenechte se ukolébat falešným pocitem bezpečí, který přichází s nasazením nejnovějšího systému vysoké dostupnosti. Pokud jsou všechna data virtualizována a konsolidována, rizika se dokonce zvyšují. Jak jednoduchý byl život, když na jednom počítači běžela jediná instance databáze. V dnešní době obvykle na serveru ve virtuálních strojích běží desítky instancí SQL Serveru, které, pokud selže fyzický server, selžou všechny současně. Pokud to finanční prostředky dovolí, můžete vytvořit cluster s podporou převzetí služeb při selhání hostitelů virtuálních strojů na různých fyzických serverech. Pokud je potřeba vysoká dostupnost, obvykle se tak děje. Ale i takový systém odolný proti poruchám může být zranitelný v případě, řekněme, požáru, povodně nebo zemětřesení. Zálohy jsou stále nutné. Vytváření záložních kopií je přitom svěřeno omezenému počtu osob. Další informace o tom, kdo může vytvářet zálohy, najdete na postranním panelu „Kdo může zálohovat?“

Frekvence zálohování databáze závisí na tom, jak dlouho trvá její obnovení ze zálohy. Čím častěji je databáze zálohována, tím méně času zabere obnova. Plán zálohování a obnovy lze konfigurovat individuálně pro každou databázi. Typ rezervace závisí také na velikosti databáze a počtu transakcí provedených za jednotku času. Hlavní typy zálohování jsou plné, žurnálové a přírůstkové. Další informace o režimech obnovy naleznete na postranním panelu „Modely obnovy databáze“ Příkazy zálohování SQL Serveru jsou popsány na postranním panelu „Standardní příkazy zálohování“.

Plná rezervace

Strategie plné redundance je nejjednodušší na pochopení a implementaci. Na konci každého pracovního dne (nebo v jakémkoli jiném časovém intervalu, který můžete určit) se jednoduše spustí postup úplného zálohování databáze (obrázek 1). To nevyžaduje samostatnou zálohu protokolu a nevyžaduje žádná další nastavení. Správa souborů v tomto režimu zálohování také nevyžaduje zvláštní pozornost, protože se jedná o jeden úplný záložní soubor. Obnova z úplné zálohy je také velmi jednoduchá: stačí obnovit z jednoho souboru. Použití plných záloh je dobrou volbou pro organizace s nedostatečně zkušenými IT zaměstnanci.

Úplná záloha je nejvhodnější pro „malé“ databáze – nazvěme ty databáze, které lze zálohovat ve stanoveném čase. Když SQL Server provádí úplnou zálohu databáze, nejprve uloží všechny oblasti na disk (rozsah je osm po sobě jdoucích stránek, každá o velikosti 8 KB). SQL Server poté zálohuje protokol transakcí, takže všechny změny v databázi, ke kterým mohlo dojít během zálohování, jsou také uloženy v souboru úplné zálohy.

Pokud provádíte pouze úplnou zálohu, pak v případě selhání systému může dojít ke ztrátě některých dat – především změn provedených od poslední zálohy. Pokud je frekvence aktualizací databáze nízká, například se provádějí pouze vysokorychlostní hromadné operace, pak můžete naplánovat plnou zálohu ihned po hromadné aktualizaci dat, v takovém případě lze data považovat za poměrně bezpečná.

Plná redundance není vhodná pro produkční systémy, které jsou poměrně intenzivně aktualizovány. Při použití úplné zálohy, pokud potřebujete obnovit, budete muset znovu spustit všechny transakce a hromadné načtení dat, které byly provedeny po bodu zálohování. Je-li poslední plná záloha poškozena, budete muset obnovit předchozí zálohu a znovu ručně zajistit, aby byly použity všechny transakce, ke kterým došlo od této zálohy.

Chcete-li provést úplnou zálohu databáze, spusťte následující kód:

ZÁLOHA DATABÁZE AdventureWorks NA DISK = ‚E:\SQLdata\BACKUPS\AdventureWorks_FullDbBkup.bak‘WITH INIT, NAME = ‚AdventureWorks Full Db backup‘, DESCRIPTION = ‚AdventureWorks Full Database Backup

Parametr DISK určuje cílový soubor zálohy. Zálohovat můžete na disk nebo pásku (v tomto případě na disk). Před spuštěním zálohování se ujistěte, že složka pro uložení zálohy existuje. Ve většině případů je zálohování na disk mnohem rychlejší než zálohování na pásku, ale náklady na diskové úložiště jsou výrazně vyšší. Pro další úroveň ochrany můžete zálohovat na disk a poté zálohu uložit na pásku. Možnost WITH INIT určuje, že záložní soubor by měl být přepsán. Tato metoda je vhodná, pokud se záloha Windows provádí po každé záloze databáze. NAME – název zálohy, až 128 znaků. Pokud nezadáte jméno, pole pro jméno zůstane prázdné. POPIS je úplnější a podrobnější popis, který může pomoci například po delší době zjistit, o jakou zálohu se jedná a proč byla vytvořena.

Chcete-li úplně obnovit databázi, spusťte následující příkaz:

OBNOVIT DATABÁZI AdventureWorks Z DISKU = ‚E:\SQLdata\BACKUPS\AdventureWorks_FullDbBkup.BAK‘ S OBNOVENÍM, VYMĚNIT

WITH RECOVERY instruuje SQL Server, aby zrušil všechny čekající transakce, které by mohly být v protokolu transakcí, a nechal databázi spuštěnou. REPLACE znamená přepsání jakéhokoli existujícího souboru se stejným názvem. Toto je podrobněji popsáno v postranním panelu „Náhrada databáze“.

Při použití strategie úplného zálohování musíte sledovat velikost souboru protokolu transakcí. Úplná záloha nevymaže protokol transakcí od neaktivních položek. Pokud provádíte pouze úplnou zálohu databáze, měli byste po této operaci provést zálohu a vyčištění souboru protokolu. To se provede nastavením TRUNCATE_ONLY, jako v příkazu níže:

ZÁLOHA LOGU AdventureWorks S TRUNCATE_ONLY

Pokud je zadáno nastavení TRUNCATE_ONLY, neprovede se ve skutečnosti žádná záloha protokolu, dá SQL Server pokyn k vytvoření kontrolního bodu, vyčištění neaktivních položek a zmenšení velikosti souboru protokolu. Novější verze SQL Server toto nastavení odstranily, ale místo toho můžete použít režim Simple Recovery, který umožní serveru SQL automaticky vymazat protokol transakcí od neaktivních položek.

Úplná záloha s uchováváním protokolu

Pokud nemůžete tolerovat jakoukoli ztrátu dat během obnovy, můžete použít strategii úplného zálohování s přidaným protokolem. Tato metoda zabrání ztrátě dat; je vhodný pro často aktualizované databáze. Přestože tato strategie zvyšuje složitost provozu a údržby, zkracuje se celkový čas strávený zálohováním databáze.

Obrázek 2 ukazuje příklad plánu pro úplnou zálohu s uchováváním protokolu – týdenní plná záloha v neděli a ukládání protokolu transakcí každý následující den až do následující neděle, kdy se znovu provede úplná záloha. Záloha protokolu ukládá všechny změny provedené od předchozí zálohy protokolu. V uvažovaném plánovacím schématu se ukládají denní změny.

Pokud není uvedeno jinak, po dokončení zálohování protokolu jsou neaktivní položky v protokolu „odstraněny“ (ve skutečnosti jsou označeny pro přepsání). Když spustíte příkaz BACKUP LOG, můžete přidat parametry NO_TRUNCATE nebo COPY_ONLY, aby se položky protokolu při zálohování nezměnily. Tyto možnosti ale nedoporučujeme používat, pokud si nejste jisti, k čemu je můžete potřebovat.

SQL Server 2005 má režim zálohování tail-log, tedy zálohování po zhroucení databáze, pokud nebyl poškozen protokol transakcí. Tento režim zálohuje poslední transakce provedené od poslední zálohy protokolu. Tento režim je podrobněji popsán v postranním panelu „Co jsou zálohy tail-log“.

Použití modelu úplné obnovy poskytuje relativně jednoduché obnovení a je preferovanou možností při provádění úplné zálohy žurnálu. Tím se obnoví poslední plná záloha, poté se obnoví stávající protokoly postupně v chronologickém pořadí (v pořadí, v jakém byly vytvořeny) a nakonec se obnoví poslední část protokolu. Tato strategie je vhodná pro produkční systémy, zejména pokud jsou transakční a mají málo hromadných operací.

Pokud ve vaší databázi dochází k pravidelným hromadným aktualizacím, může mít smysl použít model hromadně protokolované obnovy. Protože jednotlivé záznamy zahrnuté v hromadné operaci nejsou v tomto případě protokolovány, tento přístup snižuje režii protokolování serveru SQL Server. I když při provádění hromadných operací můžete zaznamenat znatelné zvýšení výkonu, riskujete ztrátu dat během obnovy, pokud zdrojová data pro opětovné provedení hromadných operací již nejsou v době obnovy k dispozici. Při použití jednoduchého modelu obnovy není záloha protokolu také možná, protože protokol ořízne na kontrolní bod.

Chcete-li provést úplnou zálohu protokolu, musíte nejprve zálohovat celou databázi, jako v příkladu níže:

ZÁLOHOVÁNÍ DATABÁZE AdventureWorks NA DISK = 'E:\SQLdata\BACKUPS\AdventureWorks_FullDbBkup.bak' S INIT, NAME = 'AdventureWorks Full Db backup', DESCRIPTION = 'AdventureWorks Full Database Backup'

A poté byste měli provést zálohu protokolu pomocí příkazu:

ZÁLOHA PROTOKOLU AdventureWorks NA DISK = ‚E:\SQLdata\BACKUPS\AdventureWorks_TlogBkup.bak‘ S NOINIT, NAME = ‚Záloha Translogu AdventureWorks‘, DESCRIPTION = ‚Záloha protokolu transakcí AdventureWorks‘, NOFORMAT

Volba WITH NOINIT v posledním příkazu určuje, že záložní soubor by měl být zapsán v režimu připojení na existující médium, disk nebo pásku. V tomto případě budou všechny zálohy protokolu transakcí zapsány do stejného souboru jedna po druhé. NOFORMAT dává procesu zálohování pokyn, aby uchoval všechny informace záhlaví, které mohou být obsaženy na záložních discích v záhlavích. Toto je výchozí nastavení a explicitní zadání tohoto nastavení je volitelné, ale je užitečné jako operace s vlastní dokumentací.

Chcete-li obnovit z úplné zálohy nebo úplné zálohy se zachováním protokolu, postupujte takto.

1. Pokud je databáze online, omezte přístup k ní přepnutím režimu přístupu (v okně vlastností) na RESTRICTED_USER. To umožní přístup k databázi pouze členům databázové skupiny db_owner a členům skupin serverů dbcreator a sysadmin.
2. Opravte chybu, která způsobila pád databáze.
3. Pokud je to možné, použijte všechny zálohované protokoly transakcí s možností NORECOVERY.

Chcete-li provést zálohu protokolu ocasu, spusťte příkaz:

ZÁLOHA LOGU AdventureWorks NA DISK = ‚E:\SQLdata\BACKUPS\AdventureWorks_TaillogBkup.bak‘ S NORECOVER

Chcete-li plně obnovit z úplné zálohy, musíte nejprve obnovit soubory databáze pomocí příkazu:

OBNOVIT DATABÁZI AdventureWorks Z DISKU = ‚E:\SQLdata\BACKUPS\AdventureWorks_FullDbBkup.bak‘ S NORECOVERY

Parametr NORECOVERY informuje SQL Server, že částečné transakce by měly být ponechány tak, jak jsou, bez pokusu o jejich vrácení zpět. Následné obnovení protokolů transakcí obnoví data, aby bylo možné tyto dílčí transakce dokončit. Použití možnosti NORECOVERY ponechá databázi v nepoužitelném stavu. Ihned po úplném obnovení musí být všechny zálohy protokolu transakcí obnoveny pomocí možnosti NORECOVERY, jak je uvedeno níže:

OBNOVIT LOG AdventureWorks Z DISKU = ‚E:\SQLdata\BACKUPS\AdventureWorks_TlogBkup.bak‘ S NORECOVERY

Nakonec obnovte konečný fragment pomocí parametru RECOVERY:

OBNOVIT LOG AdventureWorks Z DISKU = ‚E:\SQLdata\BACKUPS\AdventureWorks_TaillogBkup.bak‘ S OBNOVENÍM

Strategie úplné obnovy s obnovou protokolu není absolutní ochranou. Pokud dojde k poškození některé ze záloh protokolu, obnovení bude možné pouze do bodu před poškozeným protokolem. Předpokládejme například, že týdenní úplná záloha se provádí v neděli a zálohy protokolů se provádějí od pondělí do soboty. Pokud je úterní záloha poškozena, lze obnovit pouze pondělní data: riziko poškození integrity dat aplikací středečních transakcí na pondělní data se pravděpodobně nevyplatí. A obnovení konečného fragmentu také nic neudělá.

Plná plus diferenciální redundance

V případech, kdy je vyžadována další úroveň záruky, lze do návrhu přidat kromě zálohy protokolů i rozdílovou zálohu. Tato strategie je vhodná pro transakční databáze, kde se často přidávají záznamy, nelze tolerovat ztrátu dat během obnovy a správci upřednostňují rychlou obnovu.

Rozdílová záloha má kumulativní povahu – zahrnuje všechna data a struktury, které se od poslední plné zálohy změnily, bez ohledu na to, kdy byla provedena poslední plná záloha nebo kolikrát byla od té doby rozdílová záloha provedena. Předpokládejme, že úplná záloha byla provedena v neděli a rozdílová záloha byla provedena každý den, jak je znázorněno na obrázku 3. Pondělní rozdílová kopie bude obsahovat všechny změny provedené v pondělí, úterní rozdílová kopie bude obsahovat změny provedené v pondělí a úterý a středeční rozdílová kopie bude obsahovat pondělní změny , úterý a středu atd.

Obrázek 3. Plán úloh rozdílového zálohování

Obnova rozdílové zálohy obvykle trvá méně času než obnova úplné zálohy plus protokoly, protože je rychlejší obnovit jednu rozdílovou kopii než řetězec protokolů. Uložení rozdílové zálohy se provádí příkazem:

ZÁLOHA DATABÁZE AdventureWorks NA DISK = 'E:\SQLdata\BACKUPS\AdventureWorks_DiffDbBkup.bak' S INIT, DIFFERENTIAL, NAME = 'AdventureWorks Diff Db backup', DESCRIPTION = 'AdventureWorks Differential Database Backup'

Chcete-li obnovit databázi z rozdílové zálohy, postupujte takto.

1. Pokud je databáze online, omezte přístup k ní přepnutím režimu přístupu (v okně vlastností) na RESTRICTED_USER. To umožní přístup k databázi pouze členům databázové skupiny db_owner a členům skupin serverů dbcreator a sysadmin.
2. Proveďte zálohu protokolu ocasu.
3. Opravte problém, který způsobil pád databáze.
4. Obnovte plnou zálohu pomocí možnosti NORECOVERY.
5. Obnovte poslední dostupnou rozdílovou zálohu pomocí možnosti NORECOVERY.
6. Obnovte zálohu tail-log pomocí možnosti RECOVERY.

Chcete-li obnovit rozdílovou zálohu (provádí se po obnovení plné zálohy), zadejte příkaz:

OBNOVIT DATABÁZI AdventureWorks Z DISKU = ‚E:\SQLdata\BACKUPS\AdventureWorks_DiffDbBkup.bak‘WITH NORECOVERY

Poté obnovte konec protokolu pomocí možnosti RECOVERY pomocí příkazu uvedeného výše.

Rozdílové zálohování poskytuje vyšší úroveň integrity dat než samotné zálohování protokolů. Pokud je nejnovější rozdílová záloha poškozena, můžete obnovit předchozí rozdílovou zálohu a přitom zachovat integritu dat.

Kombinační strategie

Pokud není praktické znovu spouštět transakce za účelem obnovení transakcí z minulého dne, můžete provést úplnou zálohu v neděli, rozdílovou zálohu každou následující noc a zálohu protokolu transakcí ráno a večer od pondělí do soboty, jak je znázorněno na obrázku 4. Pokud v pátek večer s databází Pokud dojde ke katastrofě dat a čtvrteční rozdílová záloha je poškozena, můžete obnovit ze středeční rozdílové zálohy a poté použít protokoly ze čtvrtka a pátku. Tímto způsobem bude databáze obnovena až do okamžiku selhání. Tento problém je podrobněji popsán v postranním panelu „Jak obnovit databázi k danému časovému bodu“.

Chcete-li snížit riziko ztráty dat, měli byste přijmout smíšenou strategii, která zahrnuje úplné zálohování, zálohování protokolů a rozdílové zálohování, i když tato kombinace přidává vaší strategii zálohování a správě záloh určitou složitost. Měli byste také vyhodnotit, kolik dat může být ztraceno po selhání a obnově databáze. Použití strategie úplné obnovy nebo modelu hromadného protokolu namísto jednoduché obnovy vyžaduje více režie na soubor protokolu transakcí a má za následek větší záložní soubory, ale poskytuje větší integritu dat.

Alternativní rezervační strategie

Zálohování v SQL Server není omezeno na úplný, rozdílový a transakční protokol. Složitější strategie zahrnují zálohování souborů nebo skupin souborů, strategii částečného zálohování a zálohování pouze pro kopírování.

Přístup k databázi během zálohování a obnovy

Zálohování databáze SQL Server je online proces, všechna data uložená na SQL Serveru jsou dostupná během operace zálohování. Operace úpravy databáze, příkazy INSERT, UPDATE a DELETE jsou dostupné stejným způsobem jako výběr dat (SELECT). Strukturu databáze nebo strukturu souborů nelze během zálohování změnit – během zálohování nelze provést příkazy ALTER DATABASE, ADD FILE nebo SHRINKFILE. Pokud je vaše databáze nastavena na automatické zmenšování, může během zálohování dojít ke konfliktu. Pokud se tedy během procesu zálohování spustí automatická redukce databázového souboru, mohou selhat obě operace. Operace, která se spustí jako první, uzamkne soubor a další operace bude muset počkat na uvolnění zámku. Pokud první operace uvolní zámek, začne druhá operace. Pokud uplyne časový limit blokování první operace, druhá operace se nezdaří. Tento přístup se může zdát nesprávný z pohledu provedení druhé operace, která je nucena čekat na poruchu a teprve poté vydá poruchu. Pokud ale uvážíme, že práce druhé operace závisí na úspěchu té první, pokud při první operaci dojde k poruše, provedení druhé nedává smysl. Chcete-li tomuto problému předejít, měli byste před provedením zálohy zakázat automatické zmenšování souboru databáze.

Ve většině případů je obnovení databáze SQL Server operací offline, během níž není možný přístup uživatele k databázi. Když používáte SQL Server 2005 Enterprise Edition s modelem úplné obnovy, částečná obnova a obnova menších skupin souborů jsou ve výchozím nastavení online operace. Části databáze, které by neměly být obnoveny, jako jsou skupiny souborů s přístupem pouze pro zápis, mohou být uživatelům přístupné po dobu trvání operace obnovy. Skupiny souborů lze číst/zapisovat, pokud nebyly převedeny do režimu offline za účelem obnovení. Tato funkce je velmi užitečná pro velké databáze běžící 24x7x365. Další informace naleznete v dokumentaci SQL Server 2005 BOL „Provádění online obnovení“ (http://msdn.microsoft.com/en-us/library/ms188671.aspx) a na postranním panelu „Proč selhávají obnovení databáze online“. ."

Pojďme si to shrnout

Data jsou pro podnikání velmi důležitá, takže zajištění jejich bezpečnosti je jedním z nejdůležitějších úkolů. Zálohování dat hraje v tomto procesu hlavní roli. Prvním krokem k zajištění stálého přístupu k datům je vytvoření systému pravidelného zálohování a testovací obnovy databází. Když vytváříte novou databázi, měli byste okamžitě vytvořit zálohovací a obnovovací skripty. SQL Server poskytuje řadu možností zálohování a obnovy, které lze přizpůsobit vašim konkrétním databázovým potřebám.

Kdo může provést rezervaci?

Zálohování databáze je dostupné pro omezený počet lidí. Ve výchozím nastavení je oprávnění uděleno členům určitých skupin správce systému serveru a databázovým rolím db_owner a db_backupoperator. Při používání zálohovacích zařízení, disků nebo pásek musíte věnovat pozornost tomu, kdo je vlastníkem a jaká jsou nastavena oprávnění. SQL Server musí být schopen číst a zapisovat do zařízení. Pokud účet, pod kterým je spuštěn SQL Server, nemá oprávnění pro přístup k zařízení, dozvíte se to pouze v případě, že operace zálohování nebo obnovy selže. Uložená procedura sp_addumpdevice, která přidá položku záložního zařízení do systémových tabulek, neprovádí kontroly oprávnění na úrovni souboru.

Pro vytvoření záložní kopie můžete zadat heslo. V tomto případě musíte při obnově databáze zadat také heslo. Ochrana heslem je volitelné opatření, které je mimochodem považováno za nespolehlivé. Ochrana heslem se používá k zabránění obnovení dat neoprávněnými osobami, které neznají zásady zálohování/obnovy společnosti. Protože data nejsou při zadání hesla šifrována, toto opatření nezabrání čtení zálohovaných dat pomocí speciálních nástrojů. Heslo navíc nebrání přepsání nebo odstranění záložního souboru.

Modely obnovy databáze

Nastavení modelu obnovy určuje, kolik dat lze obnovit v případě havárie databáze. Každá databáze může mít svůj vlastní model obnovy v závislosti na tom, jakou ztrátu dat jste ochotni tolerovat. Chcete-li nastavit model obnovy databáze pomocí SQL Server Management Studio (SSMS), klikněte pravým tlačítkem na požadovanou databázi, otevřete okno Vlastnosti, přejděte na stránku Možnosti a z rozevíracího seznamu vyberte požadovaný model zálohy.

Existují tři typy modelů obnovy: úplná, jednoduchá a hromadně protokolovaná. Model úplné obnovy plně využívá plné možnosti transakčního protokolu a umožňuje obnovit databázi s vysokou mírou přesnosti k danému okamžiku. Všechny operace, jako jsou datové transakce, změny struktury databáze, provozní pokyny, jako je dokončení nebo zrušení transakce, velké objekty a hromadné operace, jsou uloženy v protokolu. Protokol transakcí je aktualizován, dokud není dokončeno zálohování protokolu transakcí.

Jednoduchý model obnovy minimálně využívá protokol transakcí a umožňuje obnovit poslední úplnou zálohu databáze. Stejně jako u modelu úplné obnovy jsou všechny transakce (kromě některých dávkových transakcí) uchovávány v deníku. Na rozdíl od modelu úplné obnovy SQL Server automaticky vymaže protokol od nepoužívaných položek. Z tohoto důvodu nelze provádět zálohy protokolu transakcí při použití jednoduchého modelu obnovy.

Model obnovy s hromadným záznamem spadá někde mezi extrémy úplných a jednoduchých modelů obnovy. Ačkoli vás název bulk-logged může napadnout logování hromadných transakcí, ve skutečnosti jsou protokolovány pouze částečně. Během hromadných operací, které často zahrnují přidání velkého počtu záznamů v krátkém časovém období, SQL Server nastaví bitový příznak pro každý rozsah databáze ovlivněný aktualizací, ale vložené záznamy nejsou ve skutečnosti přidány do souboru protokolu. Během následné zálohy protokolu transakcí SQL Server zkontroluje tento příznak a zapíše do zálohy protokolu transakcí skutečné rozsahy databáze, které byly změněny hromadnou operací, kromě normálního vkládání a odstraňování záznamů. Proto záloha protokolu v modelu hromadně protokolované obnovy obsahuje výsledky hromadných operací spíše než jednotlivé transakce, které byly skutečně dokončeny.

Použití modelu hromadně protokolované obnovy poskytuje stejnou úplnost jako model úplné obnovy, ale bez další režie, která přichází se zálohováním všech hromadných datových vložek. Existují však rizika spojená s používáním modelu obnovy zaznamenaného hromadně. Pokud mezi operacemi zálohování ztratíte zdrojová data hromadné operace, nebude úplná obnova databáze možná. Navíc není možné obnovit databázi do určitého časového bodu ze zálohy tail-log – pokus o obnovu selže.

Přestože modely úplné a hromadné obnovy zahrnují vyšší aktivitu protokolu transakcí a větší velikost záložního souboru, je to kompenzováno úplnější obnovou dat v případě selhání databáze.

Standardní příkazy pro rezervaci

SQL Server 2005 a SQL Server 2000 mají dva příkazy, které provádějí v podstatě totéž: DUMP a BACKUP (tj. DUMP DATABASE nebo BACKUP DATABASE a DUMP LOG nebo BACKUP LOG). Příkaz DUMP existuje již od SQL Serveru 6.5, kdy zálohování databáze jednoduše znamenalo zkopírování databáze do stavu, ve kterém byla před zahájením operace zálohování. Do záložní kopie přitom nebyly zahrnuty změny v databázi, které mohly nastat po spuštění zálohování.

Počínaje verzí 7 může SQL Server provádět skutečné „dynamické“ zálohy, což znamená, že změny provedené po zahájení procesu zálohování jsou zapsány do protokolu transakcí a uloženy do záložního souboru. Záloha je tedy „snímek“ databáze v době, kdy byla operace zálohování dokončena. Příkaz DUMP je zachován kvůli zpětné kompatibilitě, ale společnost Microsoft nedoporučuje jeho použití na nových systémech ve vývoji. Jednoho dne bude tento příkaz odstraněn a vývojáři se ho budou muset zbavit v těch fragmentech kódu, kde se stále používá.

Pro ty, kteří byli vždy opatrní při zálohování databází SQL Server a touží se dozvědět, co je nového v SQL Server 2005, měli byste i nadále věnovat velkou pozornost zálohám: SQL Server 2005 nemá známý příkaz DBCC REPAIR. „Náhradou“ tohoto příkazu je DROP DATABASE.

Výměna databáze

Při obnově databáze na nový server použijte volbu REPLACE, která zakáže běžné bezpečnostní kontroly a umožní přepsání existujících databází, i když se jejich název liší od názvu obnovované databáze. Předpokládejme například, že byla vytvořena záloha databáze D umístěné na serveru A. Tato záloha by měla být obnovena na serveru B. Nejprve by měla být vytvořena prázdná přípravná databáze na serveru B a název a velikost databáze hmota. Dále musíte obnovit databázi D s parametrem REPLACE na serveru B nad nově vytvořenou zprostředkující databází. Pokud musí být obnovení provedeno zpět na server A, do jeho původního umístění, není parametr REPLACE vyžadován. Ve výchozím nastavení operace obnovení databáze provádí vestavěné kontroly zabezpečení, například když obnovení databáze nelze normálně provést přes jinou existující databázi. Podobně je zakázáno obnovování databáze zálohované pomocí režimu zálohování úplného nebo hromadného protokolování, pokud není k dispozici záloha tail-log.

Pokud potřebujete obnovit databázi, která z toho či onoho důvodu neměla zálohu protokolu ocasu (například proto, že byl poškozen záložní soubor protokolu transakcí), může být použití režimu REPLACE jediným způsobem, jak úspěšně obnovit. Dalším příkladem, kdy je potřeba parametr REPLACE, je, pokud je třeba obnovit zálohu produkční databáze v testovacím a vývojovém prostředí. I když jsou názvy databází v produkčním prostředí a vývojovém prostředí stejné, z pohledu SQL Serveru se jedná o různé databáze.

Co jsou zálohy protokolu ocasu?

Záloha protokolu ocasu je nový režim zálohování na serveru SQL Server 2005. Tento režim připojí záznamy protokolu transakcí, které byly přidány do zálohy od poslední zálohy souboru protokolu. Když se pokoušíte obnovit databázi z bodu selhání, proveďte před zahájením obnovy zálohu koncového segmentu. Posledně jmenované zálohování není nutné provádět, pokud se chystáte obnovit databázi do bodu před poslední zálohou protokolu transakcí nebo pokud přesouváte databázi z jedné instance serveru do jiné nebo pokud přepisujete databázi. Je možné, že je poškozen protokol transakcí, v takovém případě nelze koncový fragment zálohovat a obnova bude muset být provedena bez něj.

Jak obnovit databázi k danému bodu v čase

Může nastat situace, kdy potřebujete provést obnovu databáze kvůli chybnému spuštění kódu – například někdo omylem odstranil tabulku v produkční databázi nebo zapomněl zahrnout klauzuli WHERE do klauzule DELETE. V takových případech je nutné obnovit databázi do stavu před okamžikem provedení chybného kódu.

Obnova je sada operací, které uvádějí databázi do konzistentního stavu. Chcete-li obnovit databázi do určitého bodu v čase, musíte provést úplnou nebo částečnou obnovu žurnálu. Jednoduchý model obnovy vede k odříznutí transakčního protokolu ke kontrolnímu bodu bez možnosti opakování a bez možnosti obnovení k danému bodu v čase.

Provádění operací obnovy následovaných „opakováním/vracením změn“ zahrnuje obnovení dat do původního stavu v konkrétním uživatelem zadaném okamžiku – podle názvu dokončené transakce nebo podle pořadového čísla v protokolu. Model hromadně protokolované obnovy má další omezení, že obnova v určitém okamžiku je možná pouze v případě, že od předchozí zálohy protokolu nebyly provedeny žádné hromadné operace. Jinými slovy, úspěšná obnova k určitému bodu v čase vyžaduje, aby posloupnost souborů zálohy protokolu byla nepřetržitá.

Data k bodu v čase, která mají být obnovena, musí být obsažena v záloze transakčního protokolu. Při obnově protokolu můžete obnovit transakce, které nastaly do určitého časového bodu, zadáním tohoto bodu v čase pomocí příkazu STOPAT, STOPATMARK nebo STOPBEFOREMARK.

Při obnově databáze do určitého okamžiku proveďte úplnou zálohu s nastavením NORECOVERY, jak je uvedeno níže:

OBNOVENÍ DATABÁZE AdventureWorks Z DISKU = "E:\SQLdata\BACKUPS\AdventureWorks_FullDbBkup.bak" S NORECOVERY

Poté použijte všechny zálohy protokolů s nastavením RECOVERY a zadáním data a času požadovaného časového bodu v každé klauzuli RESTORE LOG:

OBNOVENÍ LOGU AdventureWorks Z DISKU = "E:\SQLdata\BACKUPS\AdventureWorks_TlogBkup.bak" S OBNOVENÍM, ZASTAVENÍ = ‚10. prosince 2007 20:10‘

Zálohování souborů/skupin souborů

Tato strategie zálohování je vhodná pouze v případě, že se databáze skládá z více souborů nebo skupin souborů. Pokud velikost databáze nebo požadavky na výkon znemožňují úplnou zálohu databáze a pokud je nutná rychlá obnova v případě selhání, může být vhodné zvážit strategie zálohování souborů/skupin souborů.
Tuto strategii lze použít pro SQL Server 2005 nebo SQL Server 2000, kdy každá operace vyžaduje, aby bylo specifikováno, které soubory, skupiny souborů nebo kombinace budou zálohovány. Brzy po vytvoření byste však měli provést úplnou zálohu databáze a poté pravidelně zálohovat soubory nebo skupiny souborů. Pokud chcete použít jednoduchý model obnovy pro konkrétní databázi, musí být všechny soubory pro čtení/zápis a skupiny souborů zálohovány současně. Chcete-li minimalizovat ztrátu dat během obnovy, zvolte model úplné nebo hromadně protokolované obnovy a zahrňte do své strategie zálohu protokolu transakcí.
Obnova databáze stále znamená omezení přístupu k databázi, ale na kratší dobu než při úplné obnově databáze. Během obnovy je přístup omezen pouze na skupiny souborů, které jsou aktuálně obnovovány.
V nejhorším případě, pokud potřebujete obnovit celou databázi a používáte model úplné obnovy, budete potřebovat zálohy všech transakčních protokolů od vytvoření databáze. Pokud navíc potřebujete obnovit databázi do určitého okamžiku, budete potřebovat úplnou sadu záloh protokolu transakcí.

Částečná obnova

Tato strategie představená v SQL Server 2005 je určena pro databáze, které mají více skupin souborů pouze pro čtení a používají jednoduchý model obnovy. Protože tento typ databáze je primárně pouze pro čtení, strategie úplného zálohování a úplné obnovy jsou nadbytečné. Model frakční redundance však lze aplikovat na jakýkoli typ databáze.

Když provádíte částečnou zálohu, nejprve zálohujete hlavní skupinu souborů, všechny skupiny souborů pro čtení/zápis a všechny zadané skupiny souborů pouze pro čtení. Vzhledem k tomu, že tabulky pouze pro čtení nepodléhají častým změnám, teoreticky je není nutné zálohovat tak často jako tabulky, které podléhají změnám.

Před nastavením dílčí redundance je nutné pečlivé plánování. Při vytváření databáze byste měli vytvořit různé skupiny souborů a při vytváření tabulek byste je měli explicitně umístit do příslušných skupin souborů. Tabulky adresářů databází jsou tedy v primární skupině souborů, tabulky jen pro čtení jsou ve skupinách souborů jen pro čtení a tabulky pro čtení/zápis jsou ve skupinách souborů pro čtení/zápis.

Částečné zálohy zkracují čas potřebný k úplné obnově databáze. Pokud je celá databáze pouze pro čtení, bude do částečné zálohy zahrnuta pouze primární skupina souborů, pokud výslovně neurčíte jinak. Kromě toho lze jako základ pro rozdílovou zálohu použít částečnou kopii místo úplné kopie. Částečná redundance poskytuje další možnosti a flexibilitu ve vaší strategii redundance.

Obnova z částečné zálohy stále zahrnuje omezení přístupu k databázi, ale na kratší dobu než úplná obnova databáze – a pouze pro primární skupinu souborů, skupiny pro čtení/zápis a skupiny pouze pro čtení, které byly součástí zálohy. . Další informace naleznete v dokumentaci SQL Server 2005 Books Online „Partial Backups“ http://msdn.microsoft.com/ru-ru/library/ms191539.aspx.

Státní zálohy

Někdy je potřeba provést rezervaci pro speciální úkoly, například vytvořit prezentaci, kterou chcete ukázat klientovi. Nechcete však narušit normální pořadí souborů potřebných k obnovení databáze. V tomto případě můžete využít možnost vytvořit záložní kopii stavu databáze. Takovou kopii lze vytvořit bez ohledu na použitou strategii obnovy databáze – plnou, hromadnou kopii nebo jednoduchou (hromadná kopie nebo jednoduchá).

Stavové zálohy by však neměly být součástí strategie obnovy. Můžete vytvořit kopii stavu, obnovit z ní databázi na ukázkovém notebooku a poté bezpečně odstranit záložní soubor. Ostatní „normální“ zálohy nejsou na stavových kopiích nijak závislé, takže při provádění obnovy nebudou stavové kopie vyžadovány.

Strategie rezervace stavu nemůže být použita jako základ pro rozdílové rezervace, protože vytvoření kopie stavu neaktualizuje rozdílovou bitmapu použitou k určení, které rozsahy zkopírovat a které zachovat. Ve skutečnosti procedura rozdílové kopie nebere v úvahu kopie stavu, které byly vytvořeny, takže takové kopie se nemohou účastnit procesu rozdílové obnovy.

Při zálohování protokolu transakcí stavu databáze se protokol transakcí na rozdíl od normální zálohy nezkrátí. Záloha stavu také nemá žádný vliv na řetězec protokolů, který se používá pro úplnou zálohu s protokolem obnovy. Stavové zálohy nejsou při obnově v seznamu záloh protokolů vůbec zahrnuty. Další informace naleznete v dokumentaci k SQL Server 2005 BOL „State Backups“ na adrese http://msdn.microsoft.com/en-us/library/ms191495.aspx.

Proč nelze obnovu databáze provést online

Správci zálohování jsou často dotazováni, proč je během obnovy databáze zakázán přístup k databázi. Ve skutečnosti je možný částečný přístup k datům v závislosti na typu provedené obnovy. Obecným pravidlem je, že soubory, skupiny souborů nebo stránky, které podléhají automatické obnově, jsou převedeny do režimu offline, protože je to nezbytné pro úspěšné dokončení operací obnovy.

Proces obnovy obvykle začíná zkopírováním dat, protokolů a stránek indexu ze záložního média do databázových souborů. Poté přichází fáze opětovného spuštění - aplikace transakcí uložených v protokolu na data uložená v době zálohování databáze; tento proces se často nazývá „opakování změn“. Tyto zaznamenané transakce představují změny v databázi, ke kterým došlo od poslední zálohy databáze před selháním. SQL Server nejprve zkopíruje data a strukturální změny do protokolu transakcí a poté provede tyto změny ve skutečné databázi. Přehrání změn zajistí, že změny provedené v protokolu budou použity v databázi.

V této fázi databáze obvykle obsahuje nevyřízené transakce a databáze není přístupná. Dále SQL Server 2005 Standard Edition vstupuje do poslední fáze vrácení, která vrátí všechny čekající transakce. Po dokončení této fáze je databáze plně obnovena a připravena k použití. Enterprise Edition funguje trochu jinak – databáze je připravena k použití ihned po zopakování změn, bez čekání na fázi zrušení nevyřízených transakcí.

Přístup k souborům, skupinám souborů a stránkám je během obnovy databáze a fází vrácení/vrácení zpět odepřen, protože data, která lze načíst, jsou neplatná. Pokus o zpracování špinavých dat může způsobit problémy se zmeškanými a neúplnými transakcemi.

Příprava nového serveru k provozu by měla začít nastavením zálohy. Zdá se, že o tom všichni vědí - ale někdy i zkušení správci systému dělají neomluvitelné chyby. A nejde jen o to, že úkol nastavení nového serveru je třeba vyřešit velmi rychle, ale také o to, že není vždy jasné, jakou metodu zálohování použít.

Samozřejmě nelze vytvořit ideální metodu, která by vyhovovala všem: vše má své pro a proti. Ale zároveň se zdá docela reálné zvolit metodu, která nejlépe vyhovuje specifikům konkrétního projektu.

Při výběru způsobu zálohování musíte nejprve věnovat pozornost následujícím kritériím:

1. Rychlost (čas) zálohování do úložiště;
2. Rychlost (čas) obnovy ze záložní kopie;
3. Kolik kopií lze uchovat s omezenou velikostí úložiště (server zálohování);
4. Objem rizik způsobených nekonzistentností záložních kopií, nevyvinutým způsobem provádění záloh, úplnou nebo částečnou ztrátou záloh;
5. Režijní náklady: úroveň zatížení vytvořeného na serveru při provádění kopie, snížení rychlosti odezvy služby atd.
6. Cena pronájmu všech využívaných služeb.

V tomto článku si povíme o hlavních metodách zálohování serverů se systémy Linux a o nejčastějších problémech, se kterými se mohou začátečníci setkat v této velmi důležité oblasti správy systému.

Schéma pro uspořádání úložiště a obnovy ze záložních kopií

Při výběru organizačního schématu metody zálohování byste měli věnovat pozornost následujícím základním bodům:

1. Zálohy nelze ukládat na stejné místo jako zálohovaná data. Pokud zálohu uložíte na stejné diskové pole jako vaše data, při poškození hlavního diskového pole o ni přijdete.
2. Mirroring (RAID1) nelze srovnávat se zálohováním. Raid vás chrání pouze před hardwarovým problémem s jedním z disků (a dříve nebo později k takovému problému dojde, protože diskový subsystém je téměř vždy úzkým hrdlem serveru). Navíc při použití hardwarových raidů hrozí selhání řadiče, tzn. musíte si nechat náhradní model.
3. Pokud zálohy ukládáte v rámci jednoho racku v DC nebo jednoduše v rámci jednoho DC, pak v této situaci existují i ​​určitá rizika (o tom si můžete přečíst např.
4. Pokud ukládáte záložní kopie v různých DC, náklady na síť a rychlost obnovy ze vzdálené kopie se prudce zvýší.

Často je důvodem pro obnovu dat poškození systému souborů nebo disků. Tito. zálohy musí být uloženy někde na samostatném úložném serveru. V tomto případě může být problémem „šířka“ kanálu přenosu dat. Pokud máte dedikovaný server, je velmi vhodné provádět zálohy na samostatném síťovém rozhraní a ne na stejném rozhraní, které si vyměňuje data s klienty. V opačném případě se požadavky vašeho klienta nemusí „vejít“ do omezeného komunikačního kanálu. Nebo z důvodu zákaznického provozu nebudou zálohy provedeny včas.

Dále je třeba se zamyslet nad schématem a dobou obnovy dat z hlediska ukládání záloh. Můžete být docela spokojeni se zálohou dokončenou za 6 hodin v noci na úložišti s omezenou rychlostí přístupu, ale 6hodinová obnova vám pravděpodobně nebude vyhovovat. To znamená, že přístup k záložním kopiím by měl být pohodlný a data by měla být kopírována dostatečně rychle. Takže například obnova 1TB dat s šířkou pásma 1Gb/s zabere téměř 3 hodiny, a to v případě, že nejste limitováni výkonem diskového subsystému v úložišti a serveru. A k tomu nezapomeňte přičíst čas potřebný k odhalení problému, čas potřebný k rozhodnutí o vrácení zpět, čas potřebný ke kontrole integrity obnovených dat a množství následné nespokojenosti mezi klienty/kolegy .

Přírůstkové zálohování

Na přírůstkové záloha zkopíruje pouze soubory, které se od předchozí zálohy změnily. Následné přírůstkové zálohy přidávají pouze soubory, které se od té předchozí změnily. V průměru zaberou přírůstkové zálohy méně času, protože se zkopíruje méně souborů. Proces obnovy dat však trvá déle, protože je nutné obnovit data z poslední úplné zálohy a data ze všech následujících přírůstkových záloh. V tomto případě, na rozdíl od rozdílového kopírování, změněné nebo nové soubory nenahrazují staré, ale jsou přidány na médium nezávisle.

Přírůstkové kopírování se nejčastěji provádí pomocí nástroje rsync. S jeho pomocí můžete ušetřit úložný prostor, pokud počet změn za den není příliš velký. Pokud jsou změněné soubory velké, budou zcela zkopírovány, aniž by byly nahrazeny předchozí verze.

Proces zálohování pomocí rsync lze rozdělit do následujících kroků:

1. Sestaví se seznam souborů na redundantním serveru a v úložišti, pro každý soubor se načtou metadata (oprávnění, čas úpravy atd.) nebo kontrolní součet (při použití klíče —checksum).
2. Pokud se metadata souborů liší, pak se soubor rozdělí do bloků a pro každý blok se vypočítá kontrolní součet. Bloky, které se liší, jsou nahrány do úložiště.
3. Pokud je v souboru provedena změna během výpočtu kontrolního součtu nebo přenosu souboru, jeho záloha se opakuje od začátku.
4. Ve výchozím nastavení rsync přenáší data přes SSH, což znamená, že každý blok dat je navíc šifrován. Rsync lze také spustit jako démona a přenášet data bez šifrování pomocí jeho protokolu.

Podrobnější informace o tom, jak rsync funguje, najdete na oficiálních stránkách.

Pro každý soubor rsync provádí velmi velké množství operací. Pokud je na serveru mnoho souborů nebo je procesor silně zatížen, rychlost zálohování se výrazně sníží.

Ze zkušenosti můžeme říci, že problémy na SATA discích (RAID1) začínají po cca 200G dat na serveru. Ve skutečnosti vše samozřejmě závisí na počtu inodů. A v každém případě se tato hodnota může posunout jedním nebo druhým směrem.

Po určité době bude doba provádění zálohy velmi dlouhá nebo jednoduše nebude dokončena za den.

Aby se neporovnávaly všechny soubory, je tu lsyncd. Tento démon shromažďuje informace o změněných souborech, tzn. jejich seznam již budeme mít pro rsync připravený předem. Je však třeba vzít v úvahu, že to navíc zatěžuje diskový subsystém.

Rozdílová záloha

Na rozdíl V záloze se pokaždé zálohuje každý soubor, který se od poslední úplné zálohy změnil. Rozdílové kopírování urychluje proces obnovy. Vše, co potřebujete, je nejnovější plná a nejnovější rozdílová záloha. Rozdílové zálohování je stále oblíbenější, protože všechny kopie souborů jsou vytvářeny v určitých okamžicích, což je například velmi důležité při infikování viry.

Rozdílové zálohování se provádí například pomocí nástroje, jako je rdiff-backup. Při práci s touto utilitou vznikají stejné problémy jako u přírůstkových záloh.

Obecně platí, že pokud při hledání rozdílů v datech provádíte úplné prohledávání souborů, problémy tohoto druhu zálohování jsou podobné problémům s rsync.

Rádi bychom zvlášť poznamenali, že pokud je ve vašem schématu zálohování každý soubor zkopírován samostatně, pak se vyplatí smazat/vyloučit soubory, které nepotřebujete. Mohou to být například CMS cache. Takové cache obvykle obsahují mnoho malých souborů, jejichž ztráta neovlivní správný chod serveru.

Plná záloha

Úplná záloha obvykle ovlivní celý váš systém a všechny soubory. Týdenní, měsíční a čtvrtletní zálohy zahrnují vytvoření kompletní kopie všech dat. Obvykle se provádí v pátek nebo o víkendu, kdy kopírování velkého množství dat nemá vliv na práci organizace. Následné zálohy, prováděné od pondělí do čtvrtka až do další úplné zálohy, mohou být rozdílové nebo přírůstkové, především z důvodu úspory času a úložného prostoru. Úplné zálohování by mělo být prováděno alespoň jednou týdně.

Většina souvisejících publikací doporučuje provádět úplnou zálohu jednou nebo dvakrát týdně a po zbytek času používat přírůstkové a rozdílové zálohy. Taková rada má svůj důvod. Ve většině případů stačí úplná záloha jednou týdně. Má smysl jej znovu spustit, pokud nemáte možnost aktualizovat plnou zálohu na straně úložiště a zajistit správnost záložní kopie (to může být nutné například v případech, kdy z toho či onoho důvodu nedůvěřujte skriptům, které máte, ani zálohovacímu softwaru.

Ve skutečnosti lze úplnou zálohu rozdělit na 2 části:

1. Úplná záloha na úrovni systému souborů;
2. Úplné zálohování na úrovni zařízení.

Podívejme se na jejich charakteristické rysy na příkladu:
root@komarov:~# df -h Velikost souborového systému Použitá Avail Použití % Namontováno na /dev/mapper/komarov_system-root 3.4G 808M 2.4G 25 % / /dev/mapper/komarov_system-home 931G 439G 493G 3M 48 % /houde 4.0K 383M 1% /dev tmpfs 107M 104K 107M 1% /run tmpfs 531M 0 531M 0% /tmp žádný 5.0M 0 5.0M 0% /run/lock žádný 531M 0% / 531M 0% /1devsh 22M 109M 17% /bot

Budeme pouze rezervovat / domů. Vše ostatní lze rychle obnovit ručně. Můžete také nasadit server se systémem správy konfigurace a připojit k němu náš /home.

Úplná záloha na úrovni souborového systému

Typický představitel: skládka.

Nástroj vytvoří „dump“ systému souborů. Můžete vytvořit nejen plnou, ale i přírůstkovou zálohu. dump pracuje s tabulkou inodů a „rozumí“ struktuře souborů (takže řídké soubory jsou komprimovány).
Vypisování spuštěného systému souborů je „hloupé a nebezpečné“, protože systém souborů se může během vytváření výpisu změnit. Musí být vytvořen ze snímku (o něco později podrobněji probereme funkce práce se snímky), připojeného nebo zmrazeného souborového systému.

Toto schéma také závisí na počtu souborů a doba jeho provádění se prodlužuje s množstvím dat na disku. Dump má zároveň vyšší provozní rychlost než rsync.
Pokud potřebujete obnovit ne celou záložní kopii, ale například pouze několik náhodně poškozených souborů), může načítání takových souborů pomocí nástroje pro obnovu trvat příliš dlouho.

Úplné zálohování na úrovni zařízení

1. mdraid a DRBD
   Ve skutečnosti je RAID1 nakonfigurován s diskem/raidem na serveru a síťovou jednotkou a čas od času (podle frekvence zálohování) je další disk synchronizován s hlavním diskem/raidem na serveru.

   Největší plus je rychlost. Délka synchronizace závisí pouze na počtu změn provedených za poslední den.
   Tento zálohovací systém se používá poměrně často, ale málokdo si uvědomuje, že záložní kopie získané s jeho pomocí mohou být neúčinné a zde je důvod. Po dokončení synchronizace disku se disk obsahující záložní kopii odpojí. Pokud například provozujeme DBMS, který po částech zapisuje data na lokální disk a ukládá mezilehlá data do mezipaměti, není zaručeno, že skončí i na záložním disku. V nejlepším případě přijdeme o některá měněná data. Proto lze takové zálohy jen stěží považovat za spolehlivé.

2. LVM+dd
   Snímky jsou skvělým nástrojem pro vytváření konzistentních záloh. Před vytvořením snímku musíte resetovat mezipaměť FS a vašeho softwaru na diskový subsystém.

Například se samotným MySQL by to vypadalo takto:
$ sudo mysql -e "VYPLACHOVAT TABULKY SE ZÁMEKEM ČTENÍ;" $ sudo mysql -e "FLUSH LOGS;" $ sudo sync $ sudo lvcreate -s -p r -l100%zdarma -n %s_backup /dev/vg/%s $ sudo mysql -e "ODEMKNUTÍ TABULEK;"

* Kolegové vyprávějí příběhy o tom, jak něčí „zámek čtení“ někdy vedl k uváznutí, ale v mé paměti se to nikdy nestalo.

Zálohy DBMS lze vytvářet samostatně (například pomocí binárních protokolů), čímž se eliminují prostoje při resetování mezipaměti. Můžete také vytvořit výpisy v úložišti spuštěním instance DBMS tam. Zálohování různých DBMS je téma pro samostatné publikace.

Snímek můžete zkopírovat pomocí obnovení (například rsync s opravou pro kopírování blokových zařízení bugzilla.redhat.com/show_bug.cgi?id=494313), můžete blokovat po bloku a bez šifrování (netcat, ftp). Bloky můžete přenášet v komprimované podobě a připojit je do úložiště pomocí AVFS a na server připojit oddíl se zálohami přes SMB.

Komprese odstraňuje problémy s přenosovou rychlostí, přetížením kanálů a úložným prostorem. Pokud však nepoužíváte AVFS v úložišti, pak vám obnovení pouze části dat zabere spoustu času. Pokud používáte AVFS, setkáte se s jeho „vlhkostí“.
Alternativou k blokové kompresi je squashfs: k serveru můžete připojit například oddíl Samba a spustit mksquashfs, ale tento nástroj pracuje i se soubory, tzn. závisí na jejich množství.

Při vytváření squashfů se navíc plýtvá poměrně hodně RAM, což může snadno vést k volání oom-killer.

Bezpečnost

Je nutné se chránit před situací, kdy dojde k napadení úložiště nebo vašeho serveru. Pokud je server hacknutý, je lepší, aby uživatel, který tam zapisuje data, neměl práva na mazání/změnu souborů v úložišti.
Pokud je úložiště hacknuto, pak je také vhodné maximálně omezit práva uživatele zálohování na serveru.

Pokud lze záložní kanál odposlouchávat, je nutné šifrování.

Závěr

Každý zálohovací systém má svá pro a proti. V tomto článku jsme se pokusili zdůraznit některé nuance při výběru zálohovacího systému. Doufáme, že pomohou našim čtenářům.

V důsledku toho musíte při výběru zálohovacího systému pro váš projekt provést testy vybraného typu zálohování a věnovat pozornost:

• čas zálohování v aktuální fázi projektu;
• doba zálohování v případě, že je dat mnohem více;
• zatížení kanálu;
• zatížení diskového subsystému na serveru a v úložišti;
• čas na obnovení všech dat;
• doba obnovy pro dvojici souborů;
• potřeba konzistence dat, zejména databází;
• spotřeba paměti a přítomnost volání oom-killer;

Jako zálohovací řešení můžete použít supload a naše cloudové úložiště.
Čtenáři, kteří zde nemohou zanechat komentáře, jsou zváni, aby se k nám přidali na blogu.

Štítky:

• zálohy
• záloha
• selectel

Přidat štítky