Zálohování SQL. Zálohování databází Microsoft SQL Server

Rozsáhlá funkčnost Bacula Enterprise Edition vám mimo jiné umožňuje rychle a snadno vytvářet zálohy databází pro. Mluvíme například o nástroji, pomocí kterého můžete zálohovat MS SQL Server. Uživatel může provést zálohu MS SQL vytvořením záloh konkrétních databází MS SQL velkých objemů používaných platformou Windows, za nižší náklady na software třetích stran, se schopností obnovit data do určitého časového bodu (PITR obnovení) na síť a místní disk.

Skript Bacula Systems pro vytváření záloh MS SQL Server se vyznačuje extrémní efektivitou dosaženou implementací moderní, vysoce spolehlivé architektury. Software navíc umožňuje zálohovat MS SQL Server, používat celou řadu možností pro vytváření záloh MS SQL.

Záložní skript MS SQL Bacula Systems funguje nezávisle na VSS. To znamená, že nástroj pro zálohování MS SQL nepoužívá k vytváření záloh snímky VSS. Uživatel proto může v sadě Bacula FileSet nastavit následující hodnotu „Enable VSS = no“. Efektivního vytváření záloh MS SQL Server a jejich obnovy pomocí tohoto řešení je dosaženo použitím rozhraní Microsoft API pro SQL Server. To umožňuje Bacula Systems podporovat mechanismy zabezpečení a všechny typy ověřování dostupné na Microsoft SQL Serveru.

Zálohování protokolu transakcí MS SQL a obnova v určitém čase MS SQL: Software Bacula Enterprise Edition vám umožňuje obnovit datové bloky MS SQL nebo konkrétní nastavení až do okamžiku. Implementací modelů úplné a hromadně protokolované obnovy můžete obnovit MS SQL pomocí obnovy PITR nebo pomocí LSN obnovit systém do konkrétního stavu. Můžete obnovit konkrétní stav databáze MS SQL do libovolného konkrétního bodu v čase s přesností na sekundu. V případě zálohy protokolu transakcí MS SQL bude při obnově obnoven stav databáze z různých vybraných záloh.

Přehled funkcíautomatické zálohování a obnova MS SQL s Bacula Enterprise

Společnost Bacula Systems vytvořila záložní modul MS SQL Server pro použití s ​​Bacula Enterprise Edition. Zálohování MS SQL Server s Bacula má následující funkce:

  • Podporuje plné a rozdílové zálohy MS SQL
  • Podpora přírůstkových záloh MS SQL
  • Zálohování MS SQL na síť a lokální disk
  • Plánované zálohování MS SQL
  • Vytváření záloh na úrovni databáze MS SQL Server
  • Možnost zahrnout / vyloučit databázi z postupu pro vytváření záloh
  • Podpora pro vytváření záloh pouze pro čtení
  • Obnovení záloh MS SQL na disk
  • Odeslání záložního streamu přímo démonu úložiště
  • Obnova MS SQL v čase

Přehled a konfigurace záloh MS SQL 2008, 2008 R2, 2012 a 2014

Tento dokument poskytuje řešení pro Bacula Enterprise Edition 8.4 a novější, která nejsou podporována dřívějšími verzemi softwaru. Zálohování databáze MS SQL bylo testováno a podporováno MS SQL 2003 R2, MS SQL 2008 R2, MS SQL 2012, MS SQL 2005, MS SQL 2008, MS SQL 2014. Zálohování MS SQL z Bacula s SQL Express je možné.

Glosář zálohování MS SQL 2008, 2008 R2, 2012 a 2014

  • MS SQL znamená Microsoft SQL Server.
  • Protokol transakcí Jakákoli databáze MS SQL Server má protokol transakcí, který zaznamenává všechny transakce a úpravy databáze provedené během takových transakcí. Protokol transakcí je důležitým prvkem databáze. V případě selhání systému může být vyžadován protokol transakcí k obnovení databáze do funkčního stavu. Další informace naleznete na stránce https://msdn.microsoft.com/en-us/library/ms190925.aspx.
  • Diferenciální zálohování databáze MS SQL Server. Diferenciální zálohování je založeno na poslední úplné záloze. Během rozdílové zálohy jsou zachycena pouze data, která se od poslední úplné zálohy změnila. Více informací naleznete na https://msdn.microsoft.com/en- us/library/ms175526.aspx.
  • Plná záloha databáze MS SQL Server. Během úplné zálohy databáze je zálohována celá databáze. Záloha obsahuje část protokolu transakcí za účelem obnovení kompletní databáze ze zálohy. Úplné zálohy databáze obsahují databázi v době, kdy je záloha dokončena. Více informací naleznete na https://msdn.microsoft.com/en- us/library/ms186289.aspx.
  • Zálohování „pouze pro kopírování“ (CopyOnly). Zálohy pouze pro kopírování jsou zálohy MS SQL, které jsou nezávislé na normální sekvenci tradičních záloh serveru SQL. Někdy je užitečné vytvořit zálohy pro speciální potřeby, aniž by to ovlivnilo celkový proces zálohování a obnovy databáze. Další informace naleznete na stránce https://msdn.microsoft.com/en-us/library/ms191495.aspx.
  • VDI(Virtual Appliance Interface) je technologie společnosti Microsoft, která vám umožňuje vytvářet pojmenovaná dýmka mezi programy.
  • standardní masky určují sady řetězců zástupných znaků. Výchozí maska ​​produkce * by například obsahovala řádky production1 a production2.
  • čára
  • celé číslo.
  • LSN Každá položka v protokolu transakcí MS SQL Server je označena jedinečným registračním číslem transakce (LSN). Další informace naleznete na adrese https://technet.microsoft.com/en-us/library/ms190411%28v=sql.105%29.aspx.

Zálohujte MS SQL Server 2008, 2008 R2, 2012 a 2014

Plná záloha databází MS SQL Server 2008, 2008 R2, 2012 a 2014

Během úplné zálohy databáze MS SQL se ukládají databázové soubory a protokol transakcí, což vám umožňuje plně chránit databázi MS SQL v případě selhání média. V případě poškození jednoho nebo více souborů obnovením databáze MS SQL ze zálohy obnovíte všechny potvrzené transakce. Všechny probíhající transakce budou také vráceny zpět. V tomto režimu se vytvářejí zálohy databází master a mbdb.

Diferenční záloha databází MS SQL Server 2008, 2008 R2, 2012 a 2014

Diferenciální zálohování databáze MS SQL Server je založeno na nejnovější úplné záloze databáze MS SQL. Při vytváření rozdílové zálohy MS SQL byla vytvořena pouze data, která se změnila od poslední úplné zálohy MS SQL. Pro funkci rozdílového zálohování MS SQL je posloupnost záloh nesmírně důležitá. Pokud z nějakého důvodu není k dispozici úplná záloha, na kterou odkazuje MS SQL, nelze použít rozdílové zálohy databáze MS SQL Server. Bacula's MS SQL Backup používá k vyřešení tohoto problému specifické techniky. V případě potíží lze tedy stav rozdílové zálohy databáze automaticky upgradovat na plnou zálohu.

Zálohování protokolu transakcí MS SQL 2008, 2008 R2, 2012 a 2014

Nastavení zálohování MS SQL a konfigurace databáze

Obnovení databáze MS SQL ze zálohy

Můžete použít všechny standardní metody spuštění postupu pro obnovu databáze MS SQL ze zálohy. Měli byste se však ujistit, že v případě obnovení rozdílových dat bude obnovena také úplná předchozí záloha databáze MS SQL. V takovém případě dojde k obnovení automaticky, pokud jej spustíte v konzole bconsole pomocí možností obnovy 5 nebo 12. Ve generované struktuře souborů je třeba označit obnovu úplných databází nebo databázových instancí.

Možnosti obnovení databáze MS SQL ze zálohy

Software Bacula Enterprise Edition umožňuje uživatelům používat různé možnosti obnovy MS SQL a širokou škálu metod vrácení databáze. Nejčastěji používané možnosti obnovy jsou popsány níže:

  • Kde parametr: V případě Bacula Enterprise Edition tento parametr umožňuje správci obnovit databázi na konkrétní místo.
  • Nahradit parametr: Používá se k určení, jak se má Bacula chovat s aktuální databází při obnově. Bacula's MS SQL Backup také umožňuje několik dalších možností při obnově, například:
  • Instance: Protože MS SQL používá více instancí, zálohování databáze MS SQL společnosti Bacula vám umožňuje vybrat, kterou instanci chcete obnovit. Tento parametr je volitelný, a pokud není zadán, použije se při obnově hodnota zadaná při vytváření zálohy. Ve výchozím nastavení se používá instance s názvem „MSSQLSERVER“.
  • Databáze. Tato volba určuje název databáze, kterou chcete obnovit, a používá hodnotu nastavenou v době, kdy byla databáze vytvořena. Tento parametr je volitelný. Ve výchozím nastavení používá zálohování databází SQL Server parametr Where k určení názvu nové databáze. Pokud jsou parametrům Where a Database přiřazen platný název databáze, bude použit parametr Database.
  • Uživatel. Uživatelské jméno používané k připojení k instanci databáze MS SQL. Tento parametr je volitelný, a pokud není zadán, použije se při obnově hodnota zadaná při vytváření zálohy.
  • Heslo. Heslo používané k připojení k instanci databáze MS SQL. Tento parametr je volitelný, a pokud není zadán, použije se při obnově hodnota zadaná při vytváření zálohy.
  • Doména. Doména sloužící k připojení k instanci databáze MS SQL. Tento parametr je volitelný, a pokud není zadán, použije se při obnově hodnota zadaná při vytváření zálohy.
  • Zotavení. Tento parametr vám umožňuje určit, zda bude databáze během obnovy vrácena zpět do předchozího stavu, nebo ne. Ve výchozím nastavení se při obnově databáze vrátí do předchozího stavu.
  • Stop_before_mark. Podmínka S STOPBEFOREMARK = Slouží k označení, že položka protokolu transakcí bezprostředně před příznakem je bod obnovení. Bodem obnovení může být datum a čas, LSN nebo mark_name.
  • Stop_at_mark. Podmínka SE STOPATMARKEM = Slouží k označení, že označená transakce je bodem obnovení. STOPATMARK se přesune dopředu k vlajce a spustí přehrání označené transakce. Bodem obnovení může být datum a čas, LSN nebo mark_name.
  • Stop_at = ... Podmínka WITH STOPAT = slouží k označení, že bod obnovení je datum / čas.
  • Restrict_user. Klauzule WITH RESTRICT_USER se používá k omezení přístupu k obnovené databázi. Výchozí hodnota je no.

Obnovení MS SQL v určitém okamžiku lze provést přímo ze záložního pluginu MS SQL. Můžete také lokálně obnovit soubory a provádět operace z konzoly Microsoft SQL Server Mangement Console, abyste mohli využívat další funkce.

LSN

Číslo LSN položky protokolu, na které došlo ke konkrétní události zálohování a obnovy, lze zobrazit jedním z následujících způsobů:

  • Při zobrazení popisu úkolů pro vytvoření zálohy pomocí softwaru Bacula
  • V názvu souboru protokolu
  • V tabulce msdb.backupset
  • V tabulce msdb.backupfile

Při provádění úkolu k vytvoření zálohy databáze MS SQL se při zobrazení popisu úkolu zobrazí následující informace o číslech LSN:

Číslo První LSN odpovídá poslednímu číslu LSN poslední zálohy protokolu transakcí. Tato záloha může být první úplnou zálohou nebo poslední zálohou (přírůstkovou).

Číslo Poslední LSN odpovídá poslední zaznamenané transakci.

V případě zálohy protokolu transakcí (přírůstkové) bude název souboru přidruženého k této databázi v úkolu pro vytvoření přírůstkové zálohy vypadat takto:

Číslo v názvu, v našem případě 42000162001, odpovídá poslednímu číslu LSN předchozí úlohy (pro vytvoření úplné nebo přírůstkové zálohy).

Obrázek 2: První LSN, poslední LSN a LSN v názvech souborů

Jak ukazuje příklad na obrázku 2, pokud správce potřebuje obnovit databázi MS SQL do stavu odpovídajícího LSN číslo 14, lze provést následující akce:

  • V nabídce obnovení DB použijte volbu 5
  • Vyberte nejnovější úplný záložní soubor „data.bak“ (LSN: 10)
  • Vyberte přírůstkové zálohování „log-10.trn“

Nebo pokud není k dispozici poslední úplná záloha MS SQL Server, ale je k dispozici předchozí úplná záloha, pak:

  • Použijte možnost obnovení 3, vyberte příslušné hodnoty jobids
  • Vyberte adresář databáze „ / @ mssql / db29187“
  • Vyberte úplný záložní soubor „data.bak“ (LSN: 2)
  • Vyberte přírůstkové zálohy „log-2.trn“, „log-3.trn“, „log-10.trn“
  • Nastavte parametr stop_at_mark na „lsn: 14“
  • Spuštěním úlohy obnovte zálohu

Skripty pro obnovení MS SQL

Popis Kde Databáze Příklad
Obnovte soubory na disk Způsob kde = c: / tmp
Obnovte původní databázi kde = /
Obnovte s novým názvem název kde = newdb
Obnovte s novým názvem název databáze = newdb
Obnovte s novým názvem a přesouvejte soubory název

Tabulka 1: Scénáře obnovy MS SQL

2.3.1 Obnovení databáze MS SQL s původním názvem

Chcete -li obnovit databázi s původním názvem, parametrem Kde nesmí být zadán (prázdná hodnota) nebo musí být zadána hodnota „/“ a parametr Nahradit musí být přiřazena hodnota Vždy, nebo musíte nejprve odstranit původní databázi.

Obnovení zálohy MS SQL s novým názvem

Chcete -li obnovit zálohu databáze MS SQL s novým názvem, bude pravděpodobně nutné nejprve přesunout soubory databáze na disk. Vše závisí na tom, zda původní DB stále existuje.

Pokud původní databáze již není k dispozici, pak parametr kde nebo pole „Možnosti pluginu“ může obsahovat název nové databáze. Zálohování Bacula MS SQL automaticky vytvoří databázi s novým názvem.

Pokud je původní databáze stále požadována, parametr where se použije k přesunu souborů na disk a název nové databáze bude nutné zadat pomocí nabídky Možnosti pluginu. Ve stromu obnovy vyberte soubor layout.dat.

Pomocí mého katalogu

Spusťte úlohu opravy MS SQL:

Pomocí mého katalogu spusťte úlohu obnovení databáze MS SQL:

Obnova MS SQL na lokální disk

Pokud zadáte kde = c: / cesta /, soubory budou obnoveny na místní disk a správce databáze MS SQL bude moci k obnovení databáze použít procedurální rozšíření TSQL pro konzolu Microsoft SQL Server Mangement Console. Příkazy SQL potřebné k obnovení databáze jsou uvedeny v popisu Výstup práce jak je znázorněno na obrázku níže.

Uvažujme o nežádoucí situaci. Totiž: databáze z nějakého důvodu selhala. Co máme? Plná kopie, rozdílová kopie ke včerejšku, ale dnes existují i ​​data, bylo opravdu nutné dělat rozdílovou kopii každou hodinu? - Ne! Tady je Protokol transakcí.
Protokol transakcí - Protokol, který zaznamenává všechny transakce a všechny změny databáze provedené každou transakcí. Tito. každá akce s databází se zaznamenává krok za krokem. Každý záznam je DBMS označen pro dokončení transakce, dokončeno nebo ne. S jeho pomocí můžete obnovit stav databáze nejen po selhání, ale také v případě nepředvídaných akcí s daty. Vraťte se zpět na určitý čas. Stejně jako u databáze je třeba protokol transakcí zálohovat, plný, rozdílový, přírůstkový. Chcete -li obnovit část protokolu transakcí po selhání v intervalu mezi zálohami, musíte zálohovat konečný fragment protokolu, který je ve skutečnosti bodem dokončení zálohy. Provedeno po selhání jako odpočítávací bod.
K obnovení databáze po selhání tedy potřebujeme aktuální úplnou kopii databáze, rozdílovou kopii databáze a kopii protokolu transakcí.

Pro samotnou databázi existují 3 modely obnovy - jednoduché, úplné a hromadně protokolované. Zvážit:

  1. Jednoduchý model - používá se pouze plná redundance. Žádný rozdíl. zálohy i zálohy protokolu transakcí. Úplné kopie by měly být vytvářeny tak často, jak je to možné. Relevantní pro databáze pouze pro čtení.
  2. Model úplné obnovy je nejběžnějším modelem, ve kterém jsou k dispozici všechny funkce zálohování a obnovy dat. Podporuje obnovu jednotlivých datových stránek. Dojde k úplnému protokolování transakcí a protokol transakcí se uloží.
  3. Hromadně protokolovaný model - navržen tak, aby doplňoval model úplného úplného obnovení. Většina hromadných operací nepodporuje protokolování, proto nepodporuje obnovu databáze do určitého časového bodu.

Zvažme nejrelevantnější záložní řetězec: Úplné zálohování - jednou týdně, Diferenční zálohování - jednou denně, Zálohování protokolu transakcí - jednou za hodinu.
Existuje několik možností pro vytváření záloh:

  • Pomocí vestavěného plánovače úloh MS SQL
  • Použití Transact-SQL
  • Pomocí sqlcmd a Plánovače úloh OS
  • Ručně (což nám nevyhovuje, protože skutečný administrátor se musí neustále motat)

Uvažujme první možnost jako nejpoužitelnější. K tomu se používají Windows Server 2008 R2 Enterprise a MS SQL Server 2008 Eng.

Řekněme, že máme databázi TECH:

Přechod na nástroj pro vytváření Joba:

Tři pravé tlačítko myši a volání Master to Job:
Zaškrtneme políčko „Oddělit provádění každého úkolu“, koneckonců provádíme pouze jednu akci

Master je bez turban, ale hlavní věc není ve velikosti turban)) Vyberte typ touhy, v našem případě - plná rezervace:

Mistr Job, jak se ukázalo, je trochu Žid, a tak se znovu ptá:

„Stojí za to zvolit další parametry, mladý paddawane!“:
zde vybereme databázi, dobu uložení zálohy, adresu (pásku nebo disk), cestu pro uložení a hlavně plánovač úloh!

„Při výběru své vlastní nezapomeňte na databázi. Soustřeďte svou sílu a vyberte si databázi“:

„Příliš rychle spěcháš na vytvoření úkolu, stojí za to stisknout tlačítko níže s názvem Rozvrh - Definovat.“
Sobsno, plánovač úloh, kde vybereme typ (opakování, jednou atd.), Den, čas, typ spuštění:

To je vše, vytvořeno. Job Master je skvělý a zelený. Podíváme se na stav v Plánech malování:

Pro paranoiky, nebojte se to přiznat do zrcadla, stojí za to nahlédnout do duše SQL Server Agenta - Job Activity Monitor, Job Wizard vše podrobně ukáže:

Nyní, když jsou splněny stanovené podmínky, by měla být vytvořena úplná záloha databáze. Na stejném principu se vytvářejí zálohy rozdílových a transakčních protokolů (tyto podpoložky jsou v seznamu výběru úkolů umístěny pod „Úplnou zálohou“).
Otočte uši MSSQL, jak chcete, neodšroubujte

Další článek je vytváření pomocí Transact-SQL a několik příkladů.

Obnovme databázi „Test _Recovery“ do stavu „ t 4».

Začněme obnovovat databázi z úplné zálohy „Full2_Test_Recovery.bak“ pomocí „SQL Server Management Studio “. Klikněte pravým tlačítkem na databázi " Test _ Obnovení ", V zobrazené nabídce vyberte"Úkoly “, poté„ Obnovit “a poté„ Databáze “.

V zobrazeném okně „ Obnovit databázi “v části„ Sourse “vyberte„ Zařízení “. Další „Přidat ", Napište cestu" \\ vniz - tst - bkp 01. test. local \ Backup _ SQL \ Full 2_ Test _ Recovery. bak “, klikněte na„ Ok “. V části „Cíl“ vyberte Databáze "Test obnovy"

Klikněte na „Ok“

Základna bude úspěšně obnovena.

Podívejme se na obnovu databáze pomocí Transact-SQL.

Klikněte pravým tlačítkem na databázi „Test_Recovery“, v zobrazené nabídce vyberte „Nový dotaz“:

V zobrazeném okně zadejte:

POUŽITÍ mistr

OBNOVIT DATABASE Test_Recovery

Z DISK = "\\ vniz-tst-bkp01.test.local \ Backup_SQL \ Full2_Test_Recovery.bak"

S NAHRADIT

Základna bude úspěšně obnovena.

V tomto příkladu jsme použili parametr „VYMĚNIT“:

Obnovení obvykle zabrání nechtěnému přepsání databáze jinou databází. Pokud databáze zadaná v příkazu RESTORE již na aktuálním serveru existuje a identifikátor GUID rodiny pro uvedenou databázi se liší od identifikátoru GUID rodiny databází zaznamenaného v sadě záloh, nebude obnovena.

Volba REPLACE přepíše několik důležitých kontrol, které se obvykle provádějí operací obnovy. Následující kontroly jsou zrušeny.

  • Zkontrolujte, zda je možné obnovit existující databázi ze zálohy vytvořené pro jinou databázi.Při použití parametru REPLACE během obnovy můžete zapisovat data přes existující databázi bez ohledu na to, které databáze jsou obsaženy v sadě záloh, i když se zadaný název dat liší od názvu zapsaného v sadě záloh. To může vést k náhodnému přepsání jiné databáze přes databázi.
  • Vyhledejte obnovení v databázi pomocí modelu úplné nebo hromadně protokolované obnovy, který nebyl zálohován na konec protokolu a neaplikoval možnost STOPAT.Pokud použijete možnost VYMĚNIT, můžete přijít o potvrzená data, protože poslední zaznamenaná data ještě nebyla zálohována.
  • Přepsat existující soubory.

Správci databází jsou rozděleni na ty, kteří vytvářejí zálohy, a na ty, kteří budou zálohovat.

Úvod

Tento článek popisuje nejběžnější zálohování zabezpečení informací 1C pomocí nástrojů MS SQL Server 2008 R2, vysvětluje, proč byste to měli dělat tímto způsobem, a ne jinak, a vyvrátil několik mýtů. Článek obsahuje poměrně málo odkazů na dokumentaci MS SQL, tento článek je spíše přehledem záložních mechanismů než komplexním průvodcem. Ale pro ty, kteří stojí před tímto úkolem poprvé, jsou uvedeny jednoduché a podrobné pokyny, které platí pro jednoduché situace. Článek není určen pro správu guruů, guruů a tak to každý ví, ale předpokládá se, že čtenář je schopen nainstalovat MS SQL Server sám a přinutit tento zázrak nepřátelské technologie k vytvoření databáze ve svých hlubinách, což zase on je schopen vynutit uložení 1C dat.

Příkaz TSQL BACKUP DATABASE (a jeho bratr BACKUP LOG) považuji v podstatě za jediný zálohovací nástroj pro 1C databáze využívající MS SQL Server jako DBMS. Proč? Podívejme se, jaké metody obecně máme:

Jak Dobrý Špatně Celkový
Nahrát do dt Velmi kompaktní formát. Trvá dlouho, než se vytvoří, vyžaduje výhradní přístup, neukládá některá nepodstatná data (například uživatelská nastavení v dřívějších verzích), nasazení trvá dlouho. Nejde ani tak o způsob zálohování, jako o způsob přenosu dat z jednoho prostředí do druhého. Ideální pro úzké kanály.
Kopírování souborů mdf a ldf Zcela jasný způsob pro začínající administrátory. Vyžaduje uvolnění blokování souborů databáze, což je možné, pokud je databáze offline (příkaz offline převzít z kontextové nabídky), odpojena (odpojit) nebo je server jednoduše zastaven. Je zřejmé, že uživatelé v tuto chvíli nebudou moci pracovat. Má smysl používat tuto metodu tehdy a jen tehdy, pokud již došlo k nehodě, takže při pokusu o zotavení se alespoň budete moci vrátit k možnosti, ze které obnovení začalo.
Zálohování pomocí OS nebo hypervisoru Pohodlný způsob pro vývojová a testovací prostředí. Ne vždy přátelský s integritou dat. Způsob náročný na zdroje. Lze použít v omezené míře pro vývoj. V potravinovém prostředí to nedává žádný praktický smysl.
Zálohování pomocí MS SQL Nevyžadují se žádné prostoje. Umožňuje obnovit integrální stav v libovolném okamžiku, pokud si s tím předem děláte starosti. Dokonale automatizované. Ekonomický čas a další zdroje. Není to příliš kompaktní formát. Ne každý ví, jak tuto metodu použít v nezbytném rozsahu. Pro prostředí s potravinami - hlavní nástroj.

Hlavní potíže při používání zálohování pomocí vestavěných nástrojů MS SQL vyplývají z elementárního nepochopení principů fungování. Je to částečně způsobeno velkou leností, částečně nedostatkem jednoduchého a srozumitelného vysvětlení na úrovni „hotových receptů“ (hmm, řekněme, že jsem se nesetkal), a dokonce situaci zhoršují mytologické rady “ poddimenzováno “na fórech. Nevím, co dělat s leností, ale pokusím se vysvětlit základy zálohování.

Co šetříme a proč?

Kdysi dávno, ve vzdálené galaxii, existoval takový produkt inženýrství a účetnictví jako 1C: Enterprise 7.7. Zjevně kvůli tomu, že první verze 1C: Enterprise byly vyvinuty pro použití populárního formátu souboru dbf, jeho verze SQL neukládala do databáze dostatek informací, aby zálohu MS SQL považovala za plnohodnotnou, a dokonce s každou změnou ve struktuře byly porušeny pracovní podmínky modelu úplného obnovení, takže jste museli jít na různé triky, aby záložní systém splnil svou hlavní funkci. Ale protože vyšla verze 8, DBA si konečně mohli odpočinout. Standardní zálohovací nástroje vám umožňují vytvořit kompletní a kompletní zálohovací systém. Do zálohy není zahrnut pouze deník a některé drobnosti, jako je nastavení polohy formulářů (ve starších verzích), ale tato ztráta těchto dat nemá vliv na funkčnost systému, i když zálohovat je určitě správné a užitečné deníku.

Proč vůbec potřebujeme zálohu? HM. Na první pohled je to zvláštní otázka. Pravděpodobně za prvé, aby bylo možné nasadit kopii systému a za druhé obnovit systém v případě selhání? Souhlasím s tím prvním, ale to druhé je první záložní mýtus.

Zálohy jsou poslední úrovní zabezpečení vašeho systému. Pokud má správce databáze obnovit systém produktů ze záloh, je pravděpodobné, že při organizaci práce došlo k mnoha hrubým chybám. Zálohu nemůžete považovat za hlavní způsob zajištění integrity dat, ne, je spíše bližší hasicímu systému. Je vyžadován hasicí systém. Musí být nakonfigurován, testován a funkční. Pokud to ale fungovalo, pak je to samo o sobě vážnou mimořádnou událostí se spoustou negativních důsledků.

Chcete -li zajistit, aby se záloha používala pouze pro „mírové“ účely, použijte k zajištění provozuschopnosti jiné prostředky:

  • Udržujte své servery fyzicky v bezpečí: požáry, záplavy, špatné napájecí zdroje, čističe, stavitelé, meteority a divoká zvěř jsou hned za rohem a čekají na zničení vaší serverovny.
  • Odpovědný za hrozby zabezpečení informací.
  • Proveďte obratně změny v systému a co nejdříve se ujistěte, že tyto změny nepovedou ke zhoršení stavu. Kromě plánu provádění změn je žádoucí mít také plán „co dělat, když se něco pokazí“.
  • Místo pozdějšího odstraňování následků nehod aktivně využívejte technologie ke zlepšení dostupnosti a spolehlivosti systému. U MS SQL byste měli věnovat pozornost následujícím funkcím:
    • Používání klastrů MS SQL (i když, abych byl upřímný, myslím, že toto je jeden z nejdražších a nejužitečnějších způsobů, jak zaměstnat DBA pro systémy, které nevyžadují nepřetržitý provoz)
    • Zrcadlení databáze (synchronní a asynchronní v závislosti na dostupnosti, výkonu a nákladových požadavcích)
    • Protokoly o přepravních transakcích
    • Replikace pomocí 1C (distribuované databáze)

V závislosti na požadavcích na dostupnost systému a na rozpočtu přiděleném pro tyto účely je docela možné zvolit řešení, která sníží prostoje a dobu převzetí služeb při selhání o 1-2 řády. Technologií přístupnosti se není třeba bát: jsou dostatečně jednoduché, aby se naučily za pár dní se základními znalostmi MS SQL.

Navzdory všemu je záloha stále nezbytná. Jedná se o stejný záložní padák, který můžete použít, když selže všechno ostatní záchranné vybavení. Ale jako skutečný záložní padák k tomu:

  • tento systém musí být předem správně a profesionálně nakonfigurován,
  • specialista používající systém musí mít teoretické a praktické dovednosti v jeho aplikaci (pravidelně posilován),
  • systém by měl sestávat z nejspolehlivějších a nejjednodušších komponent (to je naše poslední naděje).

Základní informace o ukládání a zpracování dat MS SQL

Data v MS SQL jsou obvykle uložena v datových souborech (dále FD je zkratka, která se běžně nepoužívá, tento článek bude obsahovat několik dalších nepříliš obvyklých zkratek) s příponami mdf nebo ndf. Kromě těchto souborů existují ještě transakční protokoly (TT), které jsou uloženy v souborech s příponou ldf. Není neobvyklé, že začínající správci berou VT nezodpovědně a bezstarostně, a to jak z hlediska výkonu, tak spolehlivosti úložiště. To je velmi hrubá chyba. Ve skutečnosti spíše naopak, pokud existuje spolehlivě fungující záložní systém a můžete vyhradit spoustu času na obnovu systému, pak můžete ukládat data na rychlý, ale extrémně nespolehlivý RAID-0, ale pak by měl být VT uloženy na samostatném spolehlivém a produktivním zdroji (i když by byly na RAID-1). Proč je to tak? Podívejme se blíže. Hned udělám rezervaci, že prezentace je poněkud zjednodušená, ale pro počáteční pochopení dostačující.

FD ukládá data na 8 kilobajtových stránkách (které jsou kombinovány do 64 kilobajtových rozsahů, ale to není podstatné). MS SQL nezaručuježe bezprostředně po provedení příkazu ke změně dat tyto změny spadnou do FD. Ne, pouze stránka v paměti je označena jako „k uložení“. Pokud má server dostatek prostředků, budou tato data brzy na disku. Server navíc funguje „optimisticky“ a pokud k těmto změnám dojde v transakci, pak se mohou dostat na disk ještě před potvrzením transakce. To znamená, že v obecném případě během aktivní operace obsahuje FD rozptýlené kusy neúplných dat a nedokončené transakce, u nichž není známo, zda budou zrušeny nebo potvrzeny. Existuje speciální příkaz „CHECKPOINT“, který serveru říká, aby „právě teď“ vyprázdnil všechna neuložená data na disk, ale rozsah tohoto příkazu je zcela specifický. Stačí říci, že 1C jej nepoužívá (na to jsem nenarazil) a pochopte, že během provozu není FD obvykle v integrálním stavu.

Abychom se s tímto chaosem vyrovnali, potřebujeme pouze VT. K tomu jsou zapsány následující události:

  • Informace o začátku transakce a její identifikátor.
  • Informace o tom, že transakce byla spáchána nebo zrušena.
  • Informace o všech změnách údajů v FD (zhruba řečeno, co bylo a co bylo).
  • Informace o změnách v samotném FD nebo struktuře databáze (zvětšování souborů, zmenšování souborů, přidělování a uvolňování stránek, vytváření a mazání tabulek a indexů)

Všechny tyto informace jsou zapsány s uvedením identifikátoru transakce, ve které k ní došlo, a v dostatečném objemu, aby bylo možné pochopit, jak přejít ze stavu před touto operací do stavu po této operaci a naopak (výjimkou je hromadně protokolovaný model obnovy).

Je důležité, aby tyto informace byly okamžitě zapsány na disk. Dokud nejsou informace zaznamenány ve VT, příkaz není považován za provedený. V normální situaci, kdy je velikost VT dostatečného objemu a když není příliš roztříštěná, se do ní zapisují záznamy postupně v malých záznamech (ne nutně násobky 8 kb). Do protokolu transakcí se dostanou pouze data, která jsou skutečně potřebná pro obnovu. Zejména ne jsou přijímány informace o tom, který text dotazu vedl k úpravám, jaký plán provádění měl tento dotaz, který uživatel jej spustil a další informace nepotřebné k obnovení. Dotaz může poskytnout určitou představu o datové struktuře transakčního protokolu

Vyberte * z :: fn_dblog (null, null)

Vzhledem k tomu, že pevné disky pracují se sekvenčními zápisy mnohem efektivněji než s chaotickým proudem příkazů pro čtení a zápis a protože příkazy SQL budou čekat až do konce zápisu do VT, vyvstává následující doporučení:

Pokud existuje i ta nejmenší možnost, pak by v produkčním prostředí měly být VT umístěny na samostatných (od všeho ostatního) fyzickém médiu, nejlépe s minimální dobou přístupu pro sekvenční nahrávání a s maximální spolehlivostí. Pro jednoduché systémy je RAID-1 v pořádku.

Pokud je transakce zrušena, server vrátí všechny již provedené změny do předchozího stavu. Proto

Zrušení transakce na serveru MS SQL Server obvykle trvá srovnatelně s celkovou dobou trvání operací, které mění data samotné transakce. Pokuste se nezrušit transakce nebo učinit rozhodnutí o zrušení co nejdříve.

Pokud server z nějakého důvodu neočekávaně přestane fungovat, bude po restartu analyzováno, která data ve FD neodpovídají integrálnímu stavu (nezaznamenané, ale potvrzené transakce a zaznamenané, ale zrušené transakce) a tato data budou opravena. Pokud jste například začali znovu sestavovat indexy velké tabulky a restartovali server, pak po restartování bude trvat značné množství času vrátit tuto transakci zpět a neexistuje žádný způsob, jak tento proces přerušit .

Co se stane, když VT dosáhne konce souboru? Je to jednoduché - pokud je na začátku volné místo, pak začne zapisovat do volného místa na začátku souboru na obsazené místo. Jako páska se zpětnou vazbou. Pokud na začátku není místo, server se obvykle pokusí rozšířit soubor protokolu transakcí, zatímco přidělený nový blok pro server je nový soubor protokolu virtuálních transakcí, kterých může být mnoho v souboru fyzických transakcí, to však neplatí pro zálohování. Pokud se serveru nepodaří soubor rozbalit (došlo mu místo na disku nebo je nastavení zakázáno rozbalit JT), bude aktuální transakce zrušena s chybou 9002.

Jejda. A co je třeba udělat, aby v ZhT vždy bylo místo? Zde se dostáváme k modelům záložního systému a obnovy. Chcete -li zrušit transakce a obnovit správný stav serveru v případě náhlého vypnutí, je nutné ukládat záznamy do ZhT, počínaje okamžikem zahájení nejdříve otevřené transakce. Toto minimum je zapsáno a uloženo ve VT nezbytně... Bez ohledu na počasí, nastavení serveru a přání administrátora. Server nemůže dovolit, aby tyto informace chyběly. Pokud tedy otevřete transakci v jedné relaci a v jiných provedete různé akce, protokol transakcí může neočekávaně skončit. Nejranější transakci lze identifikovat pomocí příkazu DBCC OPENTRAN. To je ale jen nezbytné minimum informací. Další závisí na zotavovací modely... Na serveru SQL Server jsou tři:

  • Jednoduchý- je uložena pouze zbytková VT nezbytná pro život.
  • Úplný- celý VT je uložen od poslední zálohy transakční protokol... Upozorňujeme, že ne od okamžiku úplné zálohy!
  • Hromadně přihlášen- část (obvykle velmi malá část) operací je zaznamenána ve velmi kompaktním formátu (ve skutečnosti jde pouze o záznam, že byla změněna taková a taková stránka datového souboru). Zbytek je totožný s Full.

S modely obnovy souvisí několik mýtů.

  • Jednoduché vám umožňuje snížit zatížení diskového subsystému... To není pravda. je napsán úplně stejně jako u Bulk logged, jen je mnohem dříve považován za bezplatný.
  • Hromadné protokolování snižuje zatížení diskového subsystému... U 1C tomu tak téměř není. Ve skutečnosti je to jedna z mála operací, které bez dalšího tancování s tamburínou mohou spadat pod minimální protokolování - načítání dat z vykládky ve formátu dt a restrukturalizační tabulky.
  • Při použití modelu s hromadným přihlášením nejsou některé operace zahrnuty v záloze protokolu transakcí a neumožňuje vám obnovit stav v době této zálohy. Není to tak úplně pravda. Pokud je operace jednou z minimálně přihlášených, budou aktuální stránky s daty zálohovány a bude možné „přehrát“ protokol transakcí až do konce (i když to není možné v libovolném časovém okamžiku, pokud existuje minimálně zaznamenané operace).

Je téměř zbytečné používat model Bulk logging pro 1C databáze, takže se jím nebudeme dále zabývat. V další části ale podrobněji zvážíme volbu mezi Full a Simple.

  • Struktura protokolu transakcí
    • Modely obnovy a správa protokolu transakcí
    • Správa protokolu transakcí
  • Použití záloh transakčních protokolů

Jak funguje zálohování v modelech pro jednoduchou a úplnou obnovu

Podle typu formace existují tři typy záloh:

  • Úplný(Úplný)
  • Rozdíl(Diferenciál, diferenciál)
  • Záznam(Záložní kopie protokolů transakcí bude vzhledem k tomu, jak často se tento výraz používá, zkrácena na RCT)

Nenechte se zmást: úplný model obnovy a plná záloha jsou zásadně odlišné věci. Abych je nepletl, použiji níže anglické termíny pro model obnovy a ruské termíny pro typy záloh.

Úplné a rozdílové kopie fungují stejně pro Jednoduché i Úplné. V Simple neexistuje žádné zálohování protokolu transakcí.

Plná záloha

Umožňuje obnovit stav databáze do určitého časového bodu (ve kterém byla spuštěna záloha). Skládá se z kopie stránky po stránce použité části datových souborů a aktivní části transakčního protokolu po dobu, kdy byla vytvořena záloha.

Diferenciální zálohování

Ukládá datové stránky, které se od poslední plné zálohy změnily. Při obnově musíte nejprve obnovit úplnou zálohu (v režimu NORECOVERY budou příklady uvedeny níže), poté můžete na výsledný „pahýl“ použít libovolnou z následujících rozdílových kopií, ale samozřejmě pouze ty, které byly vytvořeny před dalším plná záloha. To může výrazně snížit množství místa na disku pro uložení zálohy.

Důležité body:

  • Diferenční kopie je k ničemu bez předchozí plné zálohy. Proto je vhodné je uložit někam blízko sebe.
  • Každá další rozdílová záloha uloží všechny stránky zahrnuté v předchozí rozdílové záloze vytvořené po předchozí úplné záloze (i když s jiným obsahem). Proto je každá následující rozdílová kopie větší než předchozí, dokud není znovu vytvořena úplná kopie (pokud je toto porušeno, je to způsobeno pouze kompresními algoritmy)
  • Na zotavení to na okamžik stačí poslední plná záloha v tomto bodě a poslední rozdílová kopie v tomto bodě. Mezilehlé kopie nejsou k obnovení potřeba (i když mohou být potřebné k výběru, kdy se mají obnovit)

RCWT

Obsahuje kopii VT za určité období. Obvykle od okamžiku předchozího RCWT do vytvoření aktuálního RCWT. FCZHT umožňuje obnovit stav z obnovené kopie v režimu NORECOVERY do libovolného časového bodu, zahrnutého do období obnovené kopie VT, do jakéhokoli dalšího časového bodu zahrnutého v intervalu obnovené zálohy. Při vytváření zálohy se standardními parametry se uvolní místo v souboru protokolu transakcí (až do okamžiku poslední otevřené transakce).

FCLT v jednoduchém modelu zjevně nedává smysl (pak LT obsahuje pouze informace od poslední neuzavřené transakce).

Při používání RCWT vzniká důležitý koncept - spojitý řetěz RKZHT... Tento řetězec lze přerušit buď ztrátou některých záloh tohoto řetězce, nebo přepnutím databáze na Simple a zpět.

Upozornění: Sada RCST je v podstatě k ničemu, pokud se nejedná o souvislý řetězec, a čas zahájení poslední úspěšné plné nebo rozdílové zálohy musí být uvnitř období tohoto řetězce.

Časté mylné představy a mýty:

  • "RCZT obsahuje data protokolu transakcí z předchozí úplné nebo rozdílové zálohy." Ne, není to tak. FCWT obsahuje zdánlivě zbytečná data mezi předchozím FCWT a následnou plnou zálohou.
  • "Plná nebo rozdílová záloha by měla uvolnit místo v protokolu transakcí." Ne, není to tak. Plné a rozdílové zálohy se nedotýkají řetězce RKZHT.
  • VT by měly být pravidelně čištěny ručně, redukovány, zmenšovány. Ne, není to nutné, a dokonce naopak - je to nežádoucí. Pokud jsou mezi FCLT uvolněny VT, dojde k narušení řetězce FCLT potřebného pro obnovu. A neustálé snižování / rozšiřování souboru povede k jeho fyzické a logické fragmentaci.

Jak to funguje jednoduše

Řekněme, že existuje databáze o velikosti 1 000 GB. Databáze se každý den rozroste o 2 GB, přičemž se změní 10 GB starých dat. Byly provedeny následující zálohy

  • Plná kopie F1 od 0:00 1. února (objem 1000 GB, komprese pro jednoduchost obrázku není brána v úvahu)
    • Delta kopie D1.1 od 0:00 2. února (velikost 12 GB)
    • Kopie Delta D1.2 ze dne 3. února 00:00 (19 GB)
    • Kopie Delta D1.3 ze dne 4. února 0:00 (velikost 25 GB)
    • Kopie Delta D1.4 z 5. února 0:00 (31 GB)
    • Delta kopie D1.5 od 0:00 6. února (36 GB)
    • Kopie Delta D1.6 ze 7. února 0:00 (40 GB)
  • Úplná kopie F2 od 0:00 8. února (svazek 1014 GB)
    • Kopie Delta D2.1 ze dne 9. února 0:00 (velikost 12 GB)
    • Kopie Delta D2.2 ze dne 10. února 00:00 (19 GB)
    • Delta kopie D2.3 od 0:00 11. února (velikost 25 GB)
    • Kopie Delta D2.4 od 12. února 12:00 (31 GB)
    • Kopie Delta D2.5 ze dne 13. února 0:00 (36 GB)
    • Kopie Delta D2.6 ze 14. února 0:00 (40 GB)

Pomocí této sady můžeme obnovit data v čase 0:00 v kterýkoli z dnů od 1. února do 14. února. K tomu musíme vzít plnou kopii F1 na týden od 1. do 7. února nebo plnou kopii F2 na 8. až 14. února, obnovit ji v režimu NORECOVERY a poté použít rozdílovou kopii požadovaného dne.

Jak to funguje v plném rozsahu

Předpokládejme, že máme stejnou sadu úplných a rozdílových záloh jako v předchozím příkladu. Kromě toho existují následující FCWT:

  • RCWT 1 za období od 12:00 31. ledna do 12:00 2. února (asi 30 GB)
  • RCWT 2 na období od 12:00 2. února do 12:00 4. února (asi 30 GB)
  • RCWT 3 pro období od 12:00 4. února do 12:00 6. února (asi 30 GB)
  • RCWT 4 pro období od 12:00 6. února do 12:00 7. února (asi 30 GB)
  • RCWT 5 pro období od 12:00 8. února do 12:00 10. února (asi 30 GB)
  • RCWT 6 na období od 12:00 10. února do 12:00 12. února (asi 30 GB)
  • RCWT 7 pro období od 12:00 12. února do 12:00 14. února (asi 30 GB)
  • RCWT 8 na období od 12:00 14. února do 12:00 16. února (asi 30 GB)

Poznámka:

  1. Velikost FCTC bude přibližně konstantní.
  2. Můžeme provádět zálohy méně často než rozdílové nebo úplné zálohy, nebo je můžeme provádět častěji, pak budou menší.
  3. Nyní můžeme obnovit stav systému do libovolného bodu od 0:00 1. února, kdy máme nejdříve úplnou kopii do 12:00 16. února.

V nejjednodušším případě pro obnovu potřebujeme:

  1. Poslední úplná kopie před obnovením
  2. Poslední kopie delta před obnovením
  3. Všechny RCST, od okamžiku poslední rozdílové kopie do okamžiku obnovení
  • Úplná kopie F2 od 0:00 8. února
  • Delta kopie D2.2 od 0:00 10. února
  • RCWT 6 na období od 12:00 10. ledna do 12:00 12. února

Nejprve bude obnoven F2, poté D2.2, poté RCWT 6 do 13:13:13 10. února. Významnou výhodou modelu Full však je, že máme na výběr - použít poslední úplnou nebo rozdílovou kopii nebo NE poslední. Pokud by se například zjistilo, že kopie D2.2 byla poškozena, a potřebujeme obnovit do 10. února 13:13:13, pak by to pro jednoduchý model znamenalo, že můžeme obnovit pouze data v tuto chvíli D2.1. S Full - „DON“ T PANIC „máme následující možnosti:

  1. Obnovte F2, poté D2.1, poté RKZhT 5, poté RKZhT 6 do 13:13:13 10. února.
  2. Obnovte F2, pak RKZhT 4, pak RKZhT 5, pak RKZhT 6 do 13:13:13 10. února.
  3. Nebo obecně obnovte F1 a najeďte všechny RCWT na RCWT 6 do 13. února 13:13:13.

Jak vidíte, plný model nám dává větší výběr.

Nyní si představme, že jsme velmi mazaní. A pár dní před neúspěchem (13:13:13 10. února) víme, že dojde k selhání. Obnovujeme databázi z plné zálohy na sousedním serveru a ponecháváme možnost pokračovat v navazování následných stavů s rozdílovými kopiemi nebo RCZHT, to znamená, že jsme ji nechali v režimu NORECOVERY. A pokaždé, bezprostředně po vzniku RKZHT, ji použijeme na tuto rezervní základnu a ponecháme ji v režimu NORECOVERY. Páni! Koneckonců, obnovení databáze nám zabere jen 10–15 minut, místo abychom obnovili obrovskou databázi! Blahopřejeme, znovu jsme objevili mechanismus přepravy protokolů, což je jeden ze způsobů, jak zkrátit prostoje. Pokud tímto způsobem přenášíte data více než jednou za období, ale neustále, pak již bude získáno zrcadlení, a pokud zdrojová základna čeká na aktualizaci základny zrcadlení, jedná se o synchronní zrcadlení, pokud nečeká, pak asynchronní.

Více o nástrojích vysoké dostupnosti si můžete přečíst v nápovědě:

  • Vysoká dostupnost (databázový stroj)
    • Pochopení řešení vysoké dostupnosti
    • Vysoká úroveň dostupnosti. Interakce a spolupráce

Další aspekty zálohování

Tuto sekci můžete bezpečně přeskočit, pokud vás nudí teorie a svědění, abyste vyzkoušeli nastavení zálohování.

Skupiny souborů

1C: Společnost ve skutečnosti neví, jak pracovat se skupinami souborů. Existuje jedna skupina souborů a je to. Ve skutečnosti je programátor nebo správce databáze MS SQL schopen umístit některé tabulky, indexy nebo dokonce části tabulek a indexů do samostatných skupin souborů (v nejjednodušší formě, do samostatných souborů). To je nezbytné buď pro zrychlení přístupu k některým datům (tím, že je umístíte na velmi rychlá média), nebo naopak, obětování rychlosti pro jejich umístění na levnější média (například málo používaná, ale objemná data). Při práci se skupinami souborů je možné provádět jejich zálohy samostatně, můžete je také samostatně obnovit, ale musíte počítat s tím, že všechny skupiny souborů budou muset být do jednoho okamžiku „dohnány“ srolováním RKZHT.

Datové soubory

Pokud osoba ovládá umístění dat v různých skupinách souborů, pak když je uvnitř skupiny souborů více souborů, pak MS SQL Server na ně tlačí data nezávisle (se stejným objemem souborů se to pokusí rovnoměrně). Z hlediska aplikace se toto používá k paralelizaci I / O operací. A z pohledu záloh je tu ještě jeden bod. U velmi velkých databází v éře „před SQL 2008“ bylo běžným problémem přidělit souvislé okno pro úplnou zálohu a cílový disk pro tuto zálohu jej jednoduše nemohl pojmout. V tomto případě bylo nejjednodušší vytvořit záložní kopii každého souboru (nebo skupiny souborů) do jeho vlastního okna. Nyní, s aktivním šířením zálohy komprese, se tento problém zmenšil, ale tuto techniku ​​můžete mít stále na paměti.

Komprimace záloh

V MS SQL Server 2008 je funkce super-mega-ultra. Od nynějška lze zálohy při generování za běhu komprimovat. Tím se zmenší velikost zálohy databáze 1C o 5-10krát. A vzhledem k tomu, že výkon diskového subsystému je obvykle překážkou DBMS, přináší to nejen snížení nákladů na úložiště, ale také silné zrychlení zálohování (i když se zvyšuje zatížení procesorů, ale obvykle kapacita procesoru je na serveru DBMS zcela dostačující).

Pokud ve verzi 2008 byla tato funkce pouze pro edici Enterprise (která je velmi drahá), pak v roce 2008 R2 byla tato funkce dána verzi Standard, což je velmi potěšující.

Nastavení komprese není popsáno v níže uvedených příkladech, ale vřele doporučuji použít kompresi zálohy, pokud neexistuje konkrétní důvod pro její deaktivaci.

Jeden záložní soubor - mnoho interních

Záložní kopie ve skutečnosti není jen soubor, je to poměrně složitý kontejner, do kterého lze uložit mnoho záloh. Tento přístup má velmi dávnou historii (osobně jej pozoruji od verze 6.5), ale v tuto chvíli pro správce „běžných“ databází, zejména databází 1C, neexistuje žádný vážný důvod, proč nepoužívat přístup „jedna záloha - jeden soubor“ ... Pro obecný vývoj je užitečné prostudovat možnost přidání několika záloh do jednoho souboru, ale s největší pravděpodobností jej nebudete muset použít (nebo, pokud budete muset, pak třídění v troskách rádoby administrátora, který nekvalifikovaně použil tato příležitost).

Více zrcadlových kopií

Na serveru SQL Server je další skvělá funkce. Záložní kopii můžete vytvořit paralelně v několika přijímačích. Jako jednoduchý příklad můžete jednu kopii vypsat na místní disk a současně přidat do sdílené síťové složky. Lokální kopie je výhodná, protože obnova z ní je mnohem rychlejší, vzdálená kopie naopak mnohem lépe snáší fyzické zničení hlavního databázového serveru.

Příklady záložních systémů

Dost teorie. Je načase praxí dokázat, že celá tato kuchyně funguje.

Konfigurace typické redundance serveru pomocí plánů údržby

Tato část je postavena ve formě hotových receptů s vysvětlením. Tato sekce je díky obrázkům velmi nudná a dlouhá, takže ji můžete přeskočit.

Pomocí průvodce vytvořením plánu služby

Konfigurace redundance serveru pomocí skriptů TSQL, příklady některých funkcí

Okamžitě vyvstává otázka, co je ještě potřeba? Vypadá to, že je vše právě nastaveno a vše funguje jako hodiny? Proč se trápit se všemi druhy skriptů? Plány údržby neumožňují:

  • Použijte zrcadlenou redundanci
  • Použijte nastavení komprese odlišné od nastavení serveru
  • Neumožňuje flexibilní reakci na vznikající situace (žádné možnosti zpracování chyb)
  • Nepovoluje flexibilní používání nastavení zabezpečení
  • Plány údržby je velmi nepohodlné nasadit (a udržovat stejné) na velkém počtu serverů (dokonce i 3-4)

Následují typické příkazy pro zálohování

Plná záloha

Úplná záloha přepíše stávající soubor (pokud existuje) a před zápisem zkontrolujte kontrolní součty stránky. Při vytváření zálohy se počítá každé procento postupu

ZÁLOHOVÁNÍ DATABÁZE NA DISK = N "C: \ Backup \ mydb.bak" S INIT, FORMAT, STATS = 1, KONTROLA

Diferenciální zálohování

Podobně - rozdílová kopie

ZÁLOHOVÁNÍ DATABÁZE NA DISK = N "C: \ Backup \ mydb.diff" S ROZDÍL„INIT, FORMAT, STATS = 1, KONTROLA

RCWT

Zálohování protokolu transakcí

ZÁLOHOVACÍ ZÁZNAM NA DISK = N "C: \ Backup \ mydb.trn" S INIT, FORMAT

Zrcadlová redundance

Často je vhodné vytvořit ne jednu záložní kopii najednou, ale dvě. Jeden může být například umístěn lokálně na serveru (aby byl po ruce) a druhý se okamžitě vytvoří ve fyzicky vzdáleném úložišti chráněném před nepříznivými vlivy:

ZÁLOHOVÁNÍ DATABÁZE NA DISK = N "C: \ Backup \ mydb.bak", ZRCADLENÍ NA DISK = N "\\ safe-server \ backup \ mydb.bak" S INIT, FORMAT

Důležitý bod, který je často přehlížen: uživatel, jehož jménem je spuštěn proces MSSQL Server, musí mít přístup ke zdroji „\\ safe-server \ backup \“, jinak kopírování skončí chybou. Pokud MSSQL Server běží jménem systému, měl by být přístup udělen uživateli domény „server_name $“, ale je lepší správně nakonfigurovat spuštění MS SQL jménem speciálně vytvořeného uživatele.

Pokud nezadáte MIRROR TO, pak to nebudou 2 zrcadlené kopie, ale jedna kopie, rozdělená na 2 soubory, podle principu střídání. A každý z nich jednotlivě bude k ničemu.

sqlcmd -S DECLSERVER \ SQLGTD -E -Q "deklarovat @s varchar (255) set @ s = 'E: \ backup \ GTD_' + převést (varchar (1), datepart (dw, getdate ())) + '. bak 'záložní databáze GTD na disk = @s s init, noformat, skip, nounload "

sqlcmd umožňuje zadávat příkazy Transact-SQL, systémové procedury a soubory skriptů z příkazového řádku do editoru dotazů v režimu SQLCMD,

  • -S - nastavuje název serveru, server [\ instance_name];
  • DECLSERVER \ SQLGTD - název serveru / název instance, na které je databáze spuštěna;
  • -E - používá k připojení k serveru SQL místo uživatelského jména a hesla důvěryhodné připojení;
  • -Q "cmdlinequery" - při spuštění programu sqlcmd provede požadavek, ale ukončí program, když ho dokončí. Lze provést více dotazů oddělených středníkem. Svůj dotaz uzavřete do uvozovek, jak je uvedeno výše;
  • prohlásit - deklarujeme proměnnou s, název proměnné vždy začíná na @, takže @s... V našem případě @s- toto je složka (disk) pro ukládání záloh;
  • varchar (n) - nastavuje typ proměnné @s jako řetězec s dlouhým řetězcem n, v příkladu 255 znaků;
  • soubor - nastavuje hodnotu proměnné @s, v tomto případě se jedná o záložní složku na jednotce E ( E: \ záloha \), pak je nastaven název záložního souboru, kde je sada funkcí převést (varchar (1), datepart (dw, getdate ())) vrací v textovém formátu o délce 1 znak aktuální den v týdnu (pondělí - 1 , Úterý - 2 atd.) a přidá se rozšíření bak... Na výstupu dostaneme soubor s názvem GTD_WeekDayNumber.bak;
  • záloha - vytvoří zálohu;
  • databáze - indikuje vytvoření zálohy celé databáze;
  • GTD - v našem příkladu název databáze na serveru SQL;
  • na disk - udává typ zadaného záložního paměťového zařízení, soubor na pevném disku a proměnnou @s, kterému je přiřazena cesta a název souboru, který má být vytvořen;
  • s init, noformat, skip, nounload - označuje, že je nutné přepsat data do kruhu s předefinováním záhlaví, což nám umožní mít 7 záložních souborů pro každý den v týdnu, přepisovatelných v kruhu.

Podle potřeby můžete používat další funkce, například kompresi, viz nápověda k dotazům a funkcím Transact-SQL.

Krok 2. Změňte příponu textového souboru na .cmd

V důsledku toho získáme soubor backupGTD.cmd... Vytvořený dávkový soubor je nutné spustit z počítače, kde je nainstalována databáze MS SQL.

Krok 3. Tento proces zautomatizujeme

Zvažme tento krok na příkladu MS Windows Server 2008: Správce serveru -> Konfigurace -> Plánovač úloh -> Knihovna plánovače úloh.