Rozsáhlá funkčnost Bacula Enterprise Edition mimo jiné umožňuje rychle a snadno vytvářet zálohy databáze 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 velkoobjemových záloh konkrétních databází MS SQL používaných platformou Windows, při nižších nákladech na software třetích stran, s možností obnovy dat do určitého okamžiku (obnovení PITR ) v síti a lokální disk.
Skript Bacula Systems pro vytváření záloh MS SQL Server se vyznačuje extrémní efektivitou, dosažené implementací moderní, vysoce spolehlivé architektury. Kromě toho vám software umožňuje zálohovat MS SQL Server a využívat různé možnosti pro vytváření záloh MS SQL.
Zálohovací skript MS SQL Bacula Systems funguje nezávisle na VSS. To znamená, že nástroj Rezervovat kopii MS SQL nepoužívá snímky VSS k vytváření záloh. Proto může uživatel nastavit následující hodnotu „Enable VSS = no“ v Bacula FileSet. Tímto řešením je dosaženo efektivní tvorby záloh MS SQL Server a jejich obnovy pomocí Microsoftu API pro SQL Server. To umožňuje Bacula Systems podporovat bezpečnostní mechanismy a všechny typy autentizace implementované v Microsoft SQL Server.
Zálohování protokolu transakcí MS SQL a obnova MS SQL v určitém okamžiku: Software Bacula Enterprise Edition vám umožňuje obnovit bloky dat MS SQL nebo specifická nastavení do určitého okamžiku. S implementací úplných a hromadně protokolovaných modelů obnovy můžete obnovit MS SQL pomocí obnovy PITR nebo použít LSN k obnovení systému do určitého stavu. Konkrétní stav databáze MS SQL můžete obnovit v libovolném konkrétním okamžiku, až po sekundu. V případě zálohy transakčního protokolu MS SQL bude při obnově obnoven stav databáze z různých vybraných záloh.
Rysy na první pohledautomatické zálohování a obnova MS SQL s Bacula Enterprise
Společnost Bacula Systems vytvořila zásuvný modul pro zálohování MS SQL Server pro použití s Bacula Enterprise Edition. Záloha MS SQL Server pomocí Bacula má následující funkce:
- Podporuje plné a rozdílové zálohy MS SQL
- Podpora přírůstkového zálohování MS SQL
- Zálohování MS SQL na síťový a lokální disk
- Plánovaná záloha MS SQL
- Vytváření záloh na úrovni databáze MS SQL Server
- Schopnost zahrnout/vyloučit databáze z procedury vytváření zálohy
- Podpora pro vytváření záloh databáze pouze pro čtení
- Obnovení záloh MS SQL na disk
- Odesílání streamu záložní kopie přímo na Storage Daemon
- MS SQL bod v čase zotavení
Kontrola a konfigurace zálohy MS SQL 2008, 2008 R2, 2012 a 2014
V tento dokumentřešení jsou prezentována 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 je podporováno MS SQL 2003 R2, MS SQL 2008 R2, MS SQL 2012, MS SQL 2005, MS SQL 2008, MS SQL 2014. Záloha MS SQL od Bacula umí pracovat s SQL Express.
MS SQL Backup Glossary 2008, 2008 R2, 2012 a 2014
- MS SQL znamená Microsoft SQL Server.
- Transakční protokol. Každá databáze MS SQL Server má transakční log, který zaznamenává všechny transakce a změny databáze provedené během těchto transakcí. Transakční protokol je důležitým prvkem databáze. V případě selhání systému může být protokol transakcí vyžadován k obnovení databáze do funkčního stavu. Více detailní informace najdete na https://msdn.microsoft.com/en-us/library/ms190925.aspx.
- Rozdílová záloha databáze MS SQL Server. Rozdílová záloha je založena na poslední plné. Během rozdílové zálohy jsou zachycena pouze data, která se změnila od vytvoření poslední plné zálohy. 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 se vytvoří záložní kopie celé databáze. Záloha obsahuje část transakčního protokolu pro účely obnovení kompletní databáze ze zálohy. Úplné zálohy databáze obsahují databázi v době, kdy byla záloha dokončena. Více informací naleznete na https://msdn.microsoft.com/en-us/library/ms186289.aspx.
- Záloha „pouze kopírování“ (CopyOnly). Zálohy pouze pro kopírování jsou zálohy MS SQL, které jsou nezávislé na běžném toku tradičních záloh SQL Serveru. Někdy je užitečné vytvořit zálohy pro speciální potřeby bez ovlivnění obecný proces zálohování a obnova databáze. Více informací naleznete na https://msdn.microsoft.com/en-us/library/ms191495.aspx.
- VDI(Virtual Device Interface) je technologie společnosti Microsoft, což vám umožní vytvořit pojmenované potrubí mezi programy.
- LSN Každý záznam v transakčním protokolu MS SQL Server je identifikován jedinečným sériovým číslem transakce (LSN). Podrobnější informace naleznete na https://technet.microsoft.com/en-us/library/ms190411%28v=sql.105%29.aspx.
Zálohování 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ž umožňuje plnou ochranu databáze MS SQL v případě selhání média. Pokud je poškozen jeden nebo více souborů, obnovení databáze MS SQL ze zálohy vám umožní obnovit všechny dokončené transakce. Všechny probíhající transakce budou také vráceny zpět. V tento režim jsou vytvořeny zálohy databáze master a mbdb.
Rozdílové zálohování databází MS SQL Server 2008, 2008 R2, 2012 a 2014
Rozdílová záloha databáze MS SQL Server je založena na nejnovější plné záloze databáze MS SQL. Při vytváření rozdílové zálohy MS SQL jsou zachycena pouze data, která byla změněna od vytvoření poslední plné zálohy MS SQL. Pro funkci rozdílového zálohování MS SQL je nesmírně důležité pořadí záloh. 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. Záloha MS SQL společnosti Bacula používá k vyřešení tohoto problému specifické techniky. Pokud se tedy vyskytnou potíže, stav rozdílové zálohy databáze lze automaticky upgradovat na plnou zálohu.
Záloha 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šechno standardních metod spuštění procedury pro obnovu databáze MS SQL ze zálohy. Musíte však zajistit, že v případě obnovy rozdílových dat bude obnovena i plná předchozí záloha databáze MS SQL. V tomto případě dojde k obnovení automaticky, pokud jej spustíte v konzole bconsole pomocí možností obnovy 5 nebo 12. Ve vygenerované struktuře souborů je třeba označit obnovu úplných databází nebo instancí DB.
Možnosti obnovení databáze MS SQL ze zálohy
Software Bacula Enterprise Edition umožňuje uživatelům používat více možností obnovy MS SQL a aplikovat je co nejvíce různé cesty"rollback" databáze. Nejčastěji používané možnosti obnovení jsou popsány níže:
- Parametr Where: V případě Bacula Enterprise Edition tento parametr umožňuje správci obnovit databázi do konkrétního umístění.
- Nahradit parametr: Používá se k definování, jak se má Bacula chovat s aktuální databází při obnově. Záloha MS SQL společnosti Bacula vám také umožňuje použít několik dalších možností při obnově, jako například:
- Instance: Vzhledem k tomu, že MS SQL používá více instancí, záloha databáze MS SQL z Bacula vám umožňuje vybrat si, kterou instanci chcete obnovit. Tento parametr je volitelný, a pokud není zadán, bude při obnově použita 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, která se má obnovit, a používá hodnotu zadanou v době vytvoření databáze. Tento parametr je volitelný. Ve výchozím nastavení zálohy databáze SQL Server používají parametr Where k určení názvu nové databáze. Pokud mají parametry Kde i Databáze přiřazen platný název databáze, použije se parametr Databáze.
- Uživatel. Uživatelské jméno používané pro připojení k instanci databáze MS SQL. Tento parametr je volitelný, a pokud není zadán, bude při obnově použita hodnota zadaná při vytváření zálohy.
- Heslo. Heslo používané pro připojení k instanci databáze MS SQL. Tento parametr je volitelný, a pokud není zadán, bude při obnově použita hodnota zadaná při vytváření zálohy.
- Doména. Doména použitá pro připojení k instanci databáze MS SQL. Tento parametr je volitelný, a pokud není zadán, bude při obnově použita hodnota zadaná při vytváření zálohy.
- Zotavení. Tento parametr umožňuje určit, zda bude databáze během obnovy vrácena zpět do předchozího stavu či nikoli. Ve výchozím nastavení se při obnově databáze vrátí zpět do předchozího stavu.
- Stop_before_mark. Stav SE ZASTAVENÍM PŘED ZNAČKOU =
Používá se k označení, že záznam protokolu transakcí bezprostředně před příznakem je bod obnovení. Bod obnovy může být datum a čas, LSN nebo příznak mark_name. - Stop_at_mark. Stav S STOPATZNAKEM =
Používá se k označení, že označená transakce je bod obnovy. STOPATMARK se přesune vpřed na příznak a přehraje označenou transakci. Bod obnovy může být datum a čas, LSN nebo příznak mark_name. - Stop_at=
. Stav SE ZASTAVENÍM = se používá k označení, že bod obnovení je datum/čas. - Omezit_uživatele. Klauzule WITH RESTRICT_USER se používá k omezení přístupu k obnovené databázi. Výchozí hodnota je ne.
Obnovení MS SQL do určitého bodu v čase lze provést přímo ze zálohovacího pluginu MS SQL. Můžete také lokálně obnovit soubory a provádět operace z konzoly Microsoft SQL Server Management Console, abyste získali více funkcí.
LSN
Číslo LSN záznamu protokolu, u kterého došlo k určité události zálohování a obnovy, lze zobrazit jedním z následujících způsobů:
- Při zobrazení popisu úloh pro vytváření záloh pomocí softwaru Bacula
- V názvu souboru protokolu
- V tabulce msdb.backupset
- V tabulce msdb.backupfile
Při provádění úlohy na vytvoření zálohy databáze MS SQL se při zobrazení popisu úlohy zobrazí následující informace o číslech LSN:
Číslo První LSN odpovídá poslednímu číslu LSN poslední zálohy protokolu transakcí. Takovou zálohou může být úplně první plná záloha nebo poslední záloha (přírůstková).
Číslo Poslední LSN odpovídá poslední transakci zaznamenané v deníku.
V případě zálohy protokolu transakcí (přírůstkové) bude název souboru přidruženého k této databázi v úloze pro vytvoření přírůstkové zálohy vypadat takto:
V našem případě číslo v názvu 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ímu LSN číslu 14, lze provést následující kroky:
- V nabídce obnovy databáze použijte volbu 5
- Vybrat poslední souborúplná záloha „data.bak“ (LSN: 10)
- Vyberte přírůstkovou zálohu „log-10.trn“
Nebo pokud není k dispozici nejnovější plná záloha MS SQL Server, ale předchozí plná záloha je k dispozici, pak:
- Použijte volbu obnovení 3, vyberte vhodné hodnoty id úloh
- 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
Obnovovací skripty MS SQL
| Popis | Kde | Databáze | Příklad |
| Obnovte soubory na disk | Cesta | kde=c:/tmp | |
| Obnovit původní databázi | kde=/ | ||
| Obnovit s novým názvem | název | kde=newdb | |
| Obnovit s novým názvem | název | databáze=newdb | |
| Obnovit s novým názvem a přesunout 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, možnost Kde nesmí být zadáno (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 zdrojovou 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, možná budete muset nejprve přesunout soubory databáze na disk. Vše závisí na tom, zda původní databáze stále existuje.
Pokud zdrojová databáze již není k dispozici, pak parametr kde, nebo pole „Možnosti pluginu“ může obsahovat název nové databáze. MS SQL Backup od Bacula automaticky vytvoří databázi s novým názvem.
Pokud je stále potřeba původní databáze, použije se parametr where k přesunutí souborů na disk a novou databázi budete muset pojmenovat pomocí nabídky Možnosti pluginu. Ve stromu obnovy musíte vybrat soubor layout.dat.
Použití Můj katalog
Spusťte úlohu obnovení MS SQL:
Pomocí Můj katalog spusťte úlohu obnovení databáze MS SQL:
Obnovte MS SQL na místní disk
Pokud upřesníte kde=c:/cesta/, soubory budou obnoveny na místní disk a správce databáze MS SQL bude moci k obnově databáze použít procedurální rozšíření TSQL pro konzolu Microsoft SQL Server Management Console. Příkazy SQL potřebné k obnovení databáze jsou uvedeny v popisu Výstup úlohy jak je znázorněno na obrázku níže.
Uvažujme o nežádoucí situaci. Konkrétně: z nějakého důvodu selhala databáze. co máme? Úplná kopie, rozdílová kopie za včerejšek, ale jsou tam i data pro dnešek, bylo opravdu nutné dělat rozdílovou kopii každou hodinu? - Ne! Jíst Transakční protokol.
Transaction log – Protokol, který zaznamenává všechny transakce a všechny změny databáze provedené každou transakcí. Tito. jakákoliv akce s databází se zaznamenává krok za krokem do logu. Každý záznam je označen systémem DBMS, aby se zjistilo, zda je transakce dokončena, zda je dokončena nebo ne. S jeho pomocí můžete obnovit stav databáze nejen po výpadku, ale i v případě neočekávaných akcí s daty. Vraťte se zpět do určité doby. Stejně jako u databáze je třeba protokol transakcí zálohovat, je úplný, rozdílový, přírůstkový. Chcete-li obnovit část transakčního protokolu po selhání v intervalu mezi vytvářením záloh, musíte zálohovat poslední fragment protokolu, který je ve skutečnosti konečným bodem zálohy. Provedeno po selhání jako bod odpočítávání.
Takže k obnovení databáze po selhání potřebujeme aktuální úplnou kopii databáze, rozdílovou kopii databáze a kopii protokolu transakcí.
Existují 3 modely obnovy pro samotnou databázi – jednoduchý, úplný a hromadně protokolovaný. Zvážit:
- Jednoduchý model – využívá se pouze plná redundance. Žádný rozdíl. zálohy a také zálohy protokolu transakcí. Úplné kopie by měly být vytvářeny co nejčastěji. Relevantní pro databáze používané „pouze pro čtení“.
- Model úplné obnovy je nejpoužívanějším modelem, ve kterém jsou dostupné všechny funkce zálohování a obnovy dat. Podporuje obnovu jednotlivé stránky data. Transakce jsou plně protokolovány a protokol transakcí je uložen.
- Model Bulk-Logged je určen jako doplněk k modelu plné obnovy. Většina hromadných operací nepodporuje protokolování, a proto nepodporuje obnovu databáze do určitého bodu v čase.
Podívejme se na nejaktuálnější řetězec záloh: Úplná záloha – jednou týdně, Rozdílová záloha – jednou denně, Záloha 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í jazyka Transact-SQL
- Pomocí sqlcmd a OS Task Scheduler
- Ručně (což nám nevyhovuje, protože pracující administrátor musí neustále makat)
První možnost považujme za nejpoužitelnější. K tomuto účelu se používá Windows Server 2008 R2 Enterprise a MS SQL Server 2008 Ing.
Řekněme tedy, že máme databázi TECH:
Pojďme k nástroji pro vytváření úloh:
Stiskněte pravé tlačítko myši a zavolejte Mistra Joba:
Zaškrtněte políčko „Provést každou úlohu samostatně“, provedeme pouze jednu akci
Mistr je bez turbanu, ale velikost turbanu není hlavní věc)) Vybíráme typ touhy, v našem případě - plná rezervace:
Mistr Joba, jak se ukázalo, je tak trochu Žid, a tak se znovu ptá:
"Stojí za to zvolit další parametry, mladý paddawan!":
Zde vybereme databázi, dobu uložení zálohy, adresu (páska nebo disk), cestu uložení a hlavně - plánovač úloh!
"Při výběru své databáze byste neměli zapomínat. Soustřeďte své síly a vyberte si databázi":
"Spěcháte na vytvoření úkolu příliš rychle, klikněte na tlačítko v dolní části s názvem Rozvrh - Definovat."
Vlastně plánovač úloh, kde vybíráme typ (opakovat, jednou atd.), den, čas, typ začátku:
To je ono, my jsme to vytvořili. Mistr Joba je chladný a zelený. Podíváme se na stav v plánech údržby:
Pro paranoiky, nebojte se to přiznat před zrcadlem, vyplatí se nahlédnout do duše SQL Server Agent - Job Activity Monitor, Job Wizard vám vše podrobně ukáže:
Nyní, pokud jsou splněny zadané podmínky, by měla být vytvořena úplná záloha databáze. Na stejném principu se vytvoří rozdílová záloha a záloha transakčního protokolu (tyto podpoložky se nacházejí pod „Plná záloha“ ve výběrovém seznamu úloh).
Kroutte si ušima MSSQL, jak chcete, neodšroubujte je
V dalším článku - tvorba pomocí Transact-SQL a pár příkladů.
Obnovme databázi „Test _Recovery“ do „ t 4».
Začněme obnovením databáze z úplné zálohy "Full2_Test_Recovery.bak" pomocí "SQL Server Management Studio" " Klikněte klikněte pravým tlačítkem myši myš založená na " Test_Recovery ", v nabídce, která se zobrazí, vyberte "Úkoly“, poté „Obnovit“ a poté „Databáze“.
V okně, které se objeví " Obnovit databázi“ v části „Zdroj“ vyberte „Zařízení“. Další « Přidat ", zadejte 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 Recovery"
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“ a ze zobrazené nabídky 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 "REPLACE":
Obnova obvykle zabraňuje náhodné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 GUID rodiny pro zadanou databázi se liší od GUID rodiny pro databázi zaznamenanou v záložní sadě, databáze nebude obnovena.
Volba REPLACE potlačí několik důležitých kontrol, které se obvykle provádějí operací obnovy. Následující kontroly jsou zrušeny.
- Kontrola pro obnovení vytvořené zálohy přes existující databázi pro jinou databázi.Když použijete volbu REPLACE, obnova může 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 toho, co bylo zapsáno v sadě záloh. To může vést k náhodnému přepsání databáze jinou databází.
- Testování obnovy databáze, která používá model úplné obnovy nebo model hromadně protokolované obnovy, pro kterou nebyla provedena záloha tail-log a nebyla použita volba STOPAT.Když použijete volbu NAHRADIT, můžete ztratit potvrzená data, protože poslední zaznamenaná data ještě nebyla zkopírována do zálohy.
- Přepsat existující soubory.
Správci databází se dělí na ty, kteří zálohují, a na ty, kteří budou zálohovat.
Úvod
Tento článek popisuje nejběžnější zálohu 1C IB 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 vyvrací několik mýtů. Článek obsahuje poměrně hodně odkazů na dokumentaci MS SQL, tento článek je spíše přehledem zálohovacích mechanismů než komplexním průvodcem. Ale pro ty, kteří stojí před tímto úkolem poprvé, jednoduché a pokyny krok za krokem, které se vztahují na jednoduché situace. Článek není určen pro administrační guru, guruové toto vše již vědí, ale předpokládá se, že čtenář je schopen si MS SQL Server nainstalovat sám a donutit tento zázrak nepřátelské technologie k vytvoření databáze v jejích hloubkách, kterou je zase on schopen vynutit uložení 1C dat.
Příkaz TSQL BACKUP DATABASE (a jeho bratr BACKUP LOG) považuji v podstatě za jediný prostředek pro zálohování 1C databází pomocí MS SQL Serveru jako DBMS. Proč? Podívejme se, jaké metody obecně máme:
| Jak | Pokuta | Špatně | Celkový |
| Nahrát do dt | Velmi kompaktní formát. | Dlouho se tvoří, vyžaduje výhradní přístup, neukládá některá nedůležitá data (například uživatelská nastavení v dřívějších verzích) a dlouho trvá, než se nasadí. | Není to ani tak metoda zálohování, jako spíše způsob přesunu dat z jednoho prostředí do druhého. Ideální pro úzké kanály. |
| Kopírování souborů mdf a ldf | Velmi jasný způsob pro začínající administrátory. | Vyžaduje uvolnění souborů databáze ze zamykání, a to je možné, pokud je databáze offline (příkaz take offline kontextová nabídka), je odpojen (detach) nebo je server jednoduše zastaven. Je zřejmé, že uživatelé v tuto chvíli nebudou moci pracovat. | Tuto metodu má smysl používat tehdy a jen tehdy, když již došlo k nehodě, abyste při pokusu o zotavení měli alespoň možnost vrátit se k možnosti, ze které obnova začala. |
| Zálohování pomocí OS nebo hypervizoru | Pohodlný způsob pro vývojová a testovací prostředí. | Ne vždy přátelské k integritě dat. Metoda náročná na zdroje. | Může mít omezené použití pro vývoj. V potravinářském prostředí nemá praktický význam. |
| Zálohování pomocí MS SQL | Nejsou vyžadovány žádné prostoje. Umožňuje vám obnovit úplný stav v libovolném okamžiku, pokud se o to předem obáváte. Výborná automatizace. Úsporné na čas a další zdroje. | Ne příliš kompaktní formát. Ne každý ví, jak tuto metodu používat v potřebné míře. | Pro potravinářská prostředí - hlavní nástroj. |
Hlavní potíže při použití zálohování pomocí vestavěných nástrojů MS SQL vyplývají ze základního nepochopení principů fungování. Částečně je to vysvětlováno velkou leností, částečně chybějícím jednoduchým a srozumitelným vysvětlením na úrovni „hotových receptů“ (hmm, řekněme, na žádný jsem nenarazil) a situace je také vyhrocená mytologickými radami „underguru“ na fórech. Nevím, co dělat s leností, ale pokusím se vysvětlit základy zálohování.
Co a proč šetříme?
Před dlouhou dobou, ve vzdálené galaxii, existoval takový produkt inženýrského a účetního myšlení jako 1C: Enterprise 7.7. Zřejmě kvůli tomu, že první verze 1C:Enterprise byly vyvinuty pro použití populárního formátu dbf soubory, jeho SQL verze neuchovávala v databázi dostatek informací, aby bylo možné považovat zálohu MS SQL za kompletní a i při každé změně struktury byly porušeny provozní podmínky modelu plné obnovy, takže bylo nutné sáhnout po různých triky, jak donutit záložní systém, aby vykonával svou hlavní funkci. Od té doby, co vyšla verze 8, si ale DBA konečně mohli odpočinout. Standardní zálohovací nástroje umožňují vytvořit kompletní a holistický systém zálohování. Do zálohy není zahrnuta pouze kniha jízd a některé drobnosti jako nastavení polohy formulářů (ve starších verzích), ale ztráta těchto dat nemá vliv na funkčnost systému, i když je jistě správné a užitečné vytvořit záložní kopie deníku.
Proč vůbec potřebujeme zálohu? Hm. Na první pohled zvláštní otázka. No, pravděpodobně, za prvé, aby bylo možné nasadit kopii systému a za druhé, obnovit systém v případě selhání? S tím prvním souhlasím, ale druhým účelem je první záložní mýtus.
Záloha je poslední linií zabezpečení systému. Pokud musí správce databáze obnovit systém produktu ze záložních kopií, je pravděpodobné, že došlo k mnoha vážným chybám v organizaci práce. Zálohování nelze považovat za hlavní způsob zajištění integrity dat, ne, je spíše blíže k hasicímu systému. Je vyžadován hasicí systém. Musí být nakonfigurován, otestován a funkční. Ale pokud to fungovalo, pak je to samo o sobě vážná nouzová situace 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í výkonu jiné prostředky:
- Zajistěte fyzickou bezpečnost svých serverů: požáry, záplavy, špatné zdroje energie, čističe, stavební dělníci, meteority a divoká zvířata čekají za rohem, aby zničili vaši serverovnu.
- Přistupujte zodpovědně k hrozbám zabezpečení informací.
- Změny v systému provádějte obratně a předem se ujistěte, že tyto změny nepovedou ke zhoršení. Kromě plánu na provádění změn je vhodné mít plán „co dělat, když se všechno pokazí“.
- Aktivně využívat technologie ke zvýšení dostupnosti a spolehlivosti systému namísto pozdějšího řešení následků nehod. U MS SQL byste měli věnovat pozornost následujícím funkcím:
- Použití MS SQL clusterů (i když, abych byl upřímný, myslím, že je to jeden z nejdražších a zbytečných způsobů, jak zaměstnat správce databáze pro systémy, které nevyžadují 24x7)
- Zrcadlení databáze (synchronní a asynchronní v závislosti na dostupnosti, výkonu a požadavcích na cenu)
- Doručení protokolu transakcí
- Replikace pomocí nástrojů 1C (distribuované databáze)
V závislosti na požadavcích na dostupnost systému a rozpočtu přiděleném pro tyto účely je docela možné zvolit řešení, která zkrátí prostoje a dobu zotavení po selhání o 1-2 řády. Technologie přístupnosti se není třeba bát: jsou natolik jednoduché, že se se základními znalostmi MS SQL naučíte za pár dní.
Ale bez ohledu na to je zálohování stále nutné. Jedná se o stejný záložní padák, který můžete použít, když všechny ostatní prostředky záchrany selžou. Ale jako skutečný záložní padák pro toto:
- tento systém musí být předem správně a odborně nakonfigurován,
- specialista používající systém musí mít teoretické a praktické dovednosti v jeho používání (pravidelně posilované),
- systém by se měl skládat 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 jen FD - běžně nepoužívaná zkratka; v tomto článku bude ještě několik nepříliš obvyklých zkratek) s příponami mdf nebo ndf. Kromě těchto souborů existují také transakční protokoly (TL), které jsou uloženy v souborech s příponou .ldf. Začínající administrátoři jsou často nezodpovědní a frivolní, pokud jde o VT, a to jak z hlediska výkonu, tak spolehlivosti úložiště. To je velmi závažná chyba. Ve skutečnosti je to spíše naopak, pokud existuje spolehlivě fungující zálohovací systém a na obnovu systému lze vyčlenit spoustu času, pak můžete data ukládat na rychlý, ale extrémně nespolehlivý RAID-0, ale pak data musí být uložen na samostatném spolehlivém a produktivním zdroji (ačkoli by byl na RAID-1). proč tomu tak je? Pojďme se na to podívat blíže. Hned si dovolím výhradu, že prezentace je poněkud zjednodušená, ale pro prvotní pochopení dostačující.
FD ukládá data ve stránkách o velikosti 8 kilobajtů (které jsou kombinovány do rozsahů 64 kilobajtů, ale to není podstatné). MS SQL nezaručuježe ihned po provedení příkazu změny dat se tyto změny přenesou do FD. Ne, jen je stránka v paměti označena jako „vyžaduje uložení“. Pokud má server dostatek prostředků, brzy budou tato data na disku. Server navíc funguje „optimisticky“ a pokud k těmto změnám dojde v transakci, mohou skončit na disku dříve, než je transakce potvrzena. Tedy v obecném případě, kdy aktivní práce FD obsahuje roztroušené kusy nedokončených dat a nedokončené transakce, u kterých není známo, zda budou zrušeny nebo potvrzeny. Existuje speciální příkaz "CHECKPOINT", který říká serveru, že potřebuje vyprázdnit všechna neuložená data na disk "hned", ale rozsah tohoto příkazu je zcela specifický. Stačí říct, že 1C to nepoužívá (nesetkal jsem se s tím) a pochopit, že za provozu FD většinou nebývá v neporušeném stavu.
Abychom se s tímto chaosem vyrovnali, potřebujeme VT. Jsou v něm zaznamenány následující události:
- Informace o zahájení transakce a její identifikátor.
- Informace o provedení nebo zrušení transakce.
- Informace o všech změnách v datech v FD (zhruba řečeno, co se stalo a co se stalo).
- Informace o změnách samotného FD nebo struktury 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 množství, 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 model obnovy částečného protokolování) .
Je důležité, aby byly tyto informace okamžitě zapsány na disk. Dokud nejsou informace zaznamenány do VT, příkaz se nepovažuje za provedený. V běžné situaci, kdy je velikost VT dostatečná a kdy není příliš fragmentovaná, se do ní zapisují záznamy postupně v malých záznamech (nemusí to být násobky 8 kb). Do protokolu transakcí jsou zahrnuta pouze data, která jsou skutečně nezbytná pro obnovu. Zejména Ne jsou získávány informace o tom, který text požadavku vedl k úpravám, jaký měl tento požadavek plán provádění, který uživatel jej spustil a další informace nepotřebné pro obnovu. Dotaz může poskytnout určitý přehled o struktuře dat protokolu transakcí
Vyberte * z::fn_dblog(null,null)
Kvůli pevné disky Se sekvenčním zápisem pracují mnohem efektivněji než s chaotickým proudem příkazů pro čtení a zápis a vzhledem k tomu, že SQL příkazy počkají až na konec zápisu do VT, vyvstává následující doporučení:
Pokud existuje byť jen sebemenší možnost, pak by v produktovém prostředí měly být VT umístěny na samostatných (od všeho ostatního) fyzických médiích, nejlépe s minimální dobou přístupu pro sekvenční nahrávání a s maximální spolehlivostí. Pro jednoduché systémy RAID-1 je docela vhodný.
Pokud je transakce zrušena, server vrátí všechny již provedené změny do předchozího stavu. To je proč
Zrušení transakce v MS SQL Serveru obvykle trvá srovnatelně s celkovou dobou trvání operací změny dat samotné transakce. Snažte se nerušit transakce nebo se rozhodnout pro zrušení co nejdříve.
Pokud server z nějakého důvodu nečekaně přestane fungovat, tak při jeho restartu bude analyzováno, která data v FD neodpovídají integrálnímu stavu (nezaznamenané, ale potvrzené transakce a zaznamenané, ale zrušené transakce) a tato data budou opravena. Pokud jste tedy například začali přestavovat indexy velké tabulky a restartovali server, pak při jeho restartování bude trvat značnou dobu, než se tato transakce vrátí zpět, a neexistuje 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 volné místo na začátku souboru na obsazené místo. Jako smyčková magnetická páska. Pokud na začátku není místo, server se obvykle pokusí rozbalit soubor protokolu transakcí, zatímco pro server je novým přiděleným dílem nový soubor virtuálního protokolu transakcí, kterých může být ve fyzickém souboru transakcí mnoho. , ale to má se zálohováním pramálo společného. Pokud se serveru nepodaří rozbalit soubor (došel prostor na disku nebo nastavení nedovoluje rozbalení souboru), bude aktuální transakce zrušena s chybou 9002.
Jejda. Co je potřeba udělat pro to, aby bylo na železnici vždy místo? Zde se dostáváme k modelům zálohovacího systému a obnovy. Pro zrušení transakcí a obnovení správného stavu serveru v případě náhlého vypnutí je nutné ukládat záznamy do JT, počínaje zahájením nejdříve otevřené transakce. Toto minimum je zapsáno a uloženo v ZhT Nezbytně. Bez ohledu na počasí, nastavení serveru a přání admina. Server nemůže dovolit, aby tyto informace neexistovaly. Proto pokud otevřete transakci v jedné relaci a provedete různé akce v jiných, může protokol transakcí neočekávaně skončit. Nejstarší transakci lze identifikovat pomocí příkazu DBCC OPENTRAN. Ale to je jen nezbytné minimum informací. Co se stane dál, záleží na tom modely obnovy. Na serveru SQL Server jsou tři z nich:
- Jednoduchý— je uložen pouze zbytek VT nezbytný pro život.
- Plný— je uložena celá VT od poslední zálohy transakční protokol. Pozor, ne od okamžiku úplné zálohy!
- Hromadně přihlášen— část (obvykle velmi malá část) operací je zaznamenávána ve velmi kompaktním formátu (v podstatě jen záznam, že byla změněna ta a ta stránka datového souboru). Jinak totožné s Full.
S modely obnovy je spojeno několik mýtů.
- Jednoduché umožňuje snížit zatížení diskového subsystému. To je špatně. píše se přesně stejná částka jako u Bulk log, jen je mnohem dříve považována za volnou.
- Hromadné protokolování umožňuje snížit zatížení diskového subsystému. U 1C to téměř neplatí. Ve skutečnosti jednou z mála operací, které mohou spadat pod minimální protokolování bez dalších tanečků s tamburínou, je načítání dat z nahrávání ve formátu dt a restrukturalizační tabulky.
- Při použití modelu hromadného protokolování nejsou některé transakce zahrnuty do zálohy protokolu transakcí a neumožňuje obnovit stav v době této zálohy. Není to tak úplně pravda. Je-li operace minimálně protokolována, budou aktuální stránky s daty zahrnuty do záložní kopie a bude možné „přehrát“ transakční protokol až do konce (ačkoli to není možné v libovolném okamžiku, pokud existují minimálně protokolované operace).
Je téměř zbytečné používat Bulk logovaný model pro 1C databáze, takže to dále neuvažujeme. Volbu mezi Full a Simple ale zvážíme podrobněji v příštím díle.
- Struktura protokolu transakcí
-
- Modely obnovy a správa protokolu transakcí
- Správa protokolu transakcí
- Použití záloh protokolu transakcí
Jak funguje zálohování v modelech jednoduché a úplné obnovy
V závislosti na typu formace jsou záložní kopie tří typů:
- Plný(Plný)
- Rozdíl(rozdíl, rozdíl)
- Log(Záložní kopie protokolů transakcí, vzhledem k tomu, jak často se tento termín používá, jej zkrátíme na RKZhT)
Nenechte se zde zmást: model úplné obnovy a plná záloha jsou výrazně odlišné věci. Abychom si je nepletli, níže budu používat anglické termíny pro model obnovy a ruské termíny pro typy záloh.
Úplná a rozdílová kopie fungují stejně pro Simple a Full. Záloha protokolu transakcí v Simple zcela chybí.
Plná záloha
Umožňuje obnovit stav databáze k určitému časovému bodu (do toho, kdy bylo zálohování spuštěno). Skládá se z kopie stránky po stránce použité části datových souborů a aktivní části protokolu transakcí během vytváření zálohy.
Diferenční zálohování
Ukládá stránky dat, které se od poslední úplné zálohy změnily. Při obnově musíte nejprve obnovit plnou záložní kopii (v režimu NORECOVERY budou příklady uvedeny níže), poté můžete na výslednou „prázdnou“ použít kteroukoli z následujících rozdílových kopií, ale samozřejmě pouze z těch vytvořených dříve další plná záloha. Díky tomu můžete výrazně snížit hlasitost místo na disku pro uložení záložní kopie.
Důležité body:
- Bez předchozí úplné zálohy je rozdílová kopie k ničemu. Proto je vhodné skladovat je někde blízko sebe.
- Každá následující rozdílová záloha zachová všechny stránky zahrnuté v předchozí rozdílové záloze pořízené po předchozí plné záloze (i když možná s jiným obsahem). Každá následující rozdílová kopie je tedy větší než předchozí, dokud není znovu vytvořena úplná kopie (pokud je toto porušeno, je to pouze kvůli kompresním algoritmům)
- Pro zotavení v určitém okamžiku to stačí poslední v tomto okamžiku plná záloha a poslední v tomto bodě rozdílová kopie. Mezilehlé kopie nejsou pro obnovu potřeba (ačkoli mohou být potřeba k výběru okamžiku obnovy)
RKZhT
Obsahuje kopii VT za určité období. Obvykle od okamžiku posledního RKZhT do vytvoření aktuálního RKZhT. RKZHT vám umožňuje obnovit stav z kopie obnovené v režimu NORECOVERY v kterémkoli časovém okamžiku zahrnutém do období obnovené kopie ZHT v jakémkoli následujícím časovém okamžiku zahrnutém do intervalu obnovené záložní kopie. Při vytváření zálohy se standardními parametry se uvolní místo v souboru protokolu transakcí (až do doby poslední otevřené transakce).
Je zřejmé, že RKZhT nedává v jednoduchém modelu smysl (pak ZhT obsahuje pouze informace od okamžiku poslední neuzavřené transakce).
Při použití RKZhT vzniká důležitý koncept - nepřetržitý řetězec RKZhT. Tento řetězec může být přerušen buď ztrátou některých záložních kopií tohoto řetězce, nebo převodem databáze na Simple a zpět.
Pozor: sada RKZhT je v podstatě k ničemu, pokud se nejedná o souvislý řetězec a počáteční bod poslední úspěšné úplné nebo rozdílové zálohy musí být uvnitř období tohoto řetězce.
Časté mýty a mylné představy:
- "RKZhT obsahuje data protokolu transakcí od okamžiku předchozí úplné nebo rozdílové zálohy." Ne, to není pravda. RKZhT také obsahuje na první pohled zbytečná data mezi předchozím RKZhT a následnou plnou zálohou.
- "Plná nebo rozdílová záloha by měla uvolnit místo v protokolu transakcí." Ne, to není pravda. Úplné a rozdílové zálohy nemají vliv na řetězec RKZhT.
- VT je třeba pravidelně ručně čistit, zmenšovat a skartovat. Ne, není to nutné a naopak je to nežádoucí. Pokud uvolníte VT mezi RCVT, řetězec RCVT potřebný pro obnovu se přeruší. A neustálé zmenšování/rozšiřování souboru povede k jeho fyzické i logické fragmentaci.
Jak to funguje jednoduše
Nechť je databáze 1000 GB. Každý den se databáze 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 z 0:00 1. února (objem 1000 GB, komprese se pro jednoduchost obrázku nebere v úvahu)
- Rozdílová kopie D1.1 z 0:00 2. února (svazek 12 GB)
- Diferenciální kopie D1.2 z 0:00 3. února (svazek 19 GB)
- Diferenciální kopie D1.3 z 0:00 4. února (svazek 25 GB)
- Diferenciální kopie D1.4 z 0:00 5. února (svazek 31 GB)
- Rozdílová kopie D1.5 od 0:00 6. února (svazek 36 GB)
- Diferenciální kopie D1.6 z 0:00 7. února (svazek 40 GB)
- Úplná kopie F2 z 00:00 8. února (svazek 1014 GB)
- Diferenciální kopie D2.1 z 0:00 9. února (svazek 12 GB)
- Diferenciální kopie D2.2 z 0:00 10. února (svazek 19 GB)
- Diferenciální kopie D2.3 z 0:00 11. února (svazek 25 GB)
- Diferenciální kopie D2.4 z 0:00 12. února (svazek 31 GB)
- Rozdílová kopie D2.5 od 0:00 13. února (svazek 36 GB)
- Diferenciální kopie D2.6 z 0:00 14. února (svazek 40 GB)
Pomocí této sady můžeme obnovit data v 0:00 v kterýkoli den od 1. února do 14. února. Abychom to mohli udělat, musíme vzít plnou kopii F1 pro týden od 1. do 7. února nebo úplnou kopii F2 pro 8. a 14. února, obnovit ji v režimu NORECOVERY a poté použít rozdílovou kopii požadovaného dne.
Jak to funguje naplno
Mějme stejnou sadu plných a rozdílových záloh jako v předchozím příkladu. Kromě toho existují následující RKZhT:
- RKZhT 1 na období od 31. ledna 12:00 do 2. února 12:00 (asi 30 GB)
- RKZhT 2 na období od 2. února 12:00 do 4. února 12:00 (asi 30 GB)
- RKZhT 3 na období od 4. února 12:00 do 6. února 12:00 (asi 30 GB)
- RKZhT 4 na období od 6. února do 12:00 (asi 30 GB)
- RKZhT 5 na období od 8. února 12:00 do 10. února 12:00 (asi 30 GB)
- RKZhT 6 na období od 10. února 12:00 do 12. února 12:00 (asi 30 GB)
- RKZhT 7 na období od 12. února 12:00 do 14. února 12:00 (asi 30 GB)
- RKZhT 8 na období od 14. února 12:00 do 16. února 12:00 (asi 30 GB)
Poznámka:
- Velikost RKZhT bude přibližně konstantní.
- Můžeme vytvářet zálohy méně často než rozdílové nebo plné, nebo je můžeme dělat častěji, pak budou menší.
- Nyní můžeme obnovit stav systému do libovolného bodu od 0:00 1. února, kdy máme nejdříve kompletní kopii, do 12:00 16. února.
Ve velmi jednoduchý případ K obnovení potřebujeme:
- Poslední úplná kopie před obnovením
- Poslední rozdílová kopie před obnovením
- Všechny RKZhT, od okamžiku poslední rozdílové kopie až do okamžiku restaurování
- Úplná kopie F2 od 0:00 8. února
- Rozdílová kopie D2.2 od 0:00 10. února
- RKZhT 6 na období od 12:00 10. ledna do 12:00 12. února
Nejprve bude obnovena F2, poté D2.2, poté RKZhT 6 až do 13:13:13 10. února. Významnou výhodou modelu Full je ale to, ž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řebovali bychom ji obnovit do okamžiku před 13:13:13 10. února, pak by to pro model Simple znamenalo, že bychom mohli obnovit pouze údaje k okamžiku D2.1. S Full - "DON"T PANIC" máme následující možnosti:
- Obnovte F2, pak D2.1, pak RKZHT 5, poté RKZHT 6 až do 13:13:13 10. února.
- Obnovte F2, poté RKZHT 4, poté RKZHT 5 a poté RKZHT 6 až do 10. února 13:13:13.
- Nebo dokonce obnovit F1 a spustit všechny RKZhT až do RKZhT 6 do 13:13:13 10. února.
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 selháním (13:13:13 10. února) víme, že k selhání dojde. Obnovujeme databázi na sousedním serveru z plné zálohy a ponecháváme možnost srolovat následující stavy s rozdílovými kopiemi nebo RKZhT, tedy ponechali jsme ji v režimu NORECOVERY. A pokaždé, ihned po vytvoření RKZhT, ji aplikujeme na tuto rezervní základnu a necháme ji v režimu NORECOVERY. Páni! Obnovení databáze nám nyní zabere pouze 10-15 minut místo obnovy obrovské databáze! Gratulujeme, znovu jsme objevili přepravu protokolů, jeden ze způsobů, jak zkrátit prostoje. Pokud tímto způsobem přenášíte data ne jednou za periodu, ale neustále, pak získáte zrcadlení, a pokud zdrojová základna čeká na aktualizaci zrcadlové základny, pak se jedná o synchronní zrcadlení, pokud nečeká, pak je 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ší úvahy o zálohování
Pokud vás teorie nudí a máte chuť vyzkoušet nastavení zálohování, můžete tuto část bezpečně přeskočit.
Skupiny souborů
1C:Enterprise v podstatě neví, jak pracovat se skupinami souborů. Existuje jedna skupina souborů a to je vše. 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šší verzi - do samostatné soubory). To je nutné buď pro urychlení přístupu k některým datům (umístěním na velmi rychlá média), nebo naopak obětováním rychlosti a umístěním na levnější média (například málo využívaná, ale objemná data). Při práci se skupinami souborů je možné vytvářet jejich záložní kopie samostatně a můžete je také samostatně obnovovat, ale musíte počítat s tím, že všechny skupiny souborů bude nutné do jednoho bodu „dohnat“ rolováním RKZhT.
Datové soubory
Pokud osoba spravuje umístění dat v různých skupinách souborů, pak když je ve skupině souborů několik souborů, MS SQL Server do nich vloží data nezávisle (pokud je objem souborů stejný, bude se snažit rovnoměrně). Z aplikačního hlediska se to používá k paralelizaci I/O operací. Ale z pohledu záloh je tu ještě jeden bod. U velmi velkých databází v éře před SQL 2008 bylo typickým problémem alokace souvislého okna pro plnou zálohu a cílový disk pro tuto zálohu to prostě nemusel pojmout. Nejvíc jednoduchým způsobem v tomto případě to bylo zálohování každého souboru (nebo skupiny souborů) do vlastního okna. Nyní, s aktivním šířením komprese záloh, se tento problém zmenšil, ale tuto techniku lze stále mít na paměti.
Komprese zálohy
MS SQL Server 2008 představil super-mega-ultra funkci. Od nynějška a navždy lze zálohy komprimovat, když jsou generovány za chodu. To snižuje velikost zálohy databáze 1C 5-10krát. A vzhledem k tomu, že výkon diskového subsystému je obvykle úzkým hrdlem DBMS, snižuje to nejen náklady na úložiště, ale také výrazně zrychluje zálohování (sice se zvyšuje zátěž procesorů, ale obvykle je výkon procesoru na procesoru zcela dostačující). server DBMS).
Jestliže ve verzi 2008 byla tato funkce dostupná pouze pro edici Enterprise (která je velmi drahá), tak v roce 2008 R2 tuto funkci dostala verze Standard, což je velmi potěšující.
Níže uvedené příklady nepokrývají nastavení komprese, ale důrazně doporučuji používat kompresi záloh, pokud neexistuje konkrétní důvod ji deaktivovat.
Jeden záložní soubor – mnoho interních
Ve skutečnosti záloha není jen soubor, je to poměrně složitý kontejner, do kterého lze uložit mnoho záloh. Tento přístup má velmi starou historii (osobně jej sleduji od verze 6.5), ale v tuto chvíli pro správce „běžných“ databází, zejména databází 1C, neexistují žádné vážné důvody, proč nepoužívat „jedna záložní kopie - jedna soubor“ přístup . Pro obecný vývoj Je užitečné prozkoumat možnost vložení několika záložních kopií do jednoho souboru, ale s největší pravděpodobností to nebudete muset použít (nebo pokud ano, bude to řešit trosky případného správce, který tuto funkci nekvalifikovaně používal ).
Více zrcadlových kopií
SQL Server má další skvělou funkci. Záložní kopii můžete vytvořit paralelně v několika přijímačích. Jak nejjednodušší příklad, můžete jednu kopii uložit na místní disk a zároveň ji umístit síťový zdroj. Lokální kopie je výhodná, protože obnova z ní je mnohem rychlejší, vzdálená kopie mnohem lépe snese fyzické zničení hlavního databázového serveru.
Příklady záložních systémů
Dost teorie. Je čas dokázat praxí, že celá tato kuchyně funguje.
Nastavení typické rezervace serveru prostřednictvím plánů údržby
Tato část je strukturována do podoby hotových receptů s vysvětlivkami. Tato část je díky obrázkům velmi nudná a dlouhá, takže ji můžete přeskočit.
Pomocí průvodce vytvořením servisního plánu
Nastavení zálohování serveru pomocí TSQL skriptů, příklady některých funkcí
Okamžitě se nabízí otázka, co je ještě potřeba? Zdá se, že jste právě vše nastavili a vše funguje jako hodinky? Proč se obtěžovat s nejrůznějšími skripty? Servisní plány neumožňují:
- Použijte zrcadlovou zálohu
- Použijte jiná nastavení komprese než nastavení serveru
- Neumožňuje flexibilní reakci na vznikající situace (žádné možnosti zpracování chyb)
- Neumožňuje flexibilní použití nastavení zabezpečení
- Plány služeb jsou velmi nepohodlné nasadit (a udržovat stejné). velké množství servery (dokonce možná již 3-4)
Níže jsou uvedeny typické příkazy pro zálohování
Plná záloha
Úplná záloha s přepsáním existujícího souboru (pokud existuje) a kontrolou kontrolních součtů stránek před zápisem. Při vytváření zálohy se počítá každé procento pokroku
ZÁLOHA DATABÁZE NA DISK = N"C:\Backup\mydb.bak" S INIT, FORMÁT, STATS = 1, KONTROLNÍ SOUČET
Diferenční zálohování
Podobně - rozdílová kopie
ZÁLOHA DATABÁZE NA DISK = N"C:\Backup\mydb.diff" S ROZDÍL, INIT, FORMAT, STATS = 1, KONTROLNÍ SOUČET
RKZhT
Záloha protokolu transakcí
ZÁLOHA LOGU NA DISK = N"C:\Backup\mydb.trn" S INIT, FORMÁT
Zrcadlová záloha
Často je vhodné vytvořit ne jednu záložní kopii najednou, ale dvě. Jeden může být například uložen lokálně na serveru (tak, aby byl po ruce), a druhý se okamžitě zformuje do fyzicky vzdáleného úložiště chráněného před nepříznivými vlivy:
ZÁLOHA DATABÁZE NA DISK = N"C:\Backup\mydb.bak", ZRCADLO DO DISK = N"\\safe-server\backup\mydb.bak" S INIT, FORMÁT
Důležitý bod, který je často opomíjen: uživatel, jehož jménem je proces MSSQL Server spuštěn, musí mít přístup ke zdroji "\\safe-server\backup\", jinak se kopírování nezdaří. Pokud je MSSQL Server spuštěn jménem systému, pak by měl být udělen přístup uživateli domény "server_name$", ale stále je lepší správně nakonfigurovat MS SQL tak, aby běžel jménem speciálně vytvořeného uživatele.
Pokud nezadáte MIRROR TO , pak nepůjde o 2 zrcadlené kopie, ale o jednu kopii rozdělenou do 2 souborů podle principu prokládání. A každý z nich zvlášť bude k ničemu.
sqlcmd -S DECLSERVER\SQLGTD -E -Q "deklaruje @s varchar(255) set @s='E:\backup\GTD_' + convert(varchar(1), datepart(dw, getdate())) + '. bak' záloha 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ů příkazový řádek do editoru dotazů v režimu SQLCMD,
- -S - určuje název serveru, server[\název_instance];
- DECLSERVER\SQLGTD - název serveru/název instance, na které databáze běží;
- -E - používá důvěryhodné připojení pro připojení k SQL serveru namísto uživatelského jména a hesla;
- -Q "cmdlinequery" - při spuštění programu sqlcmd vykoná požadavek, ale neukončí program po dokončení jeho provedení. Lze provést více dotazů oddělených středníkem. Uzavřete dotaz do uvozovek, jak je uvedeno výše;
- prohlásit - deklarujte proměnnou s, název proměnné vždy začíná @, 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á čára n, v příkladu 255 znaků;
- soubor - nastavuje hodnotu proměnné @s, v příkladu je to záložní složka na jednotce E ( E:\záloha\), pak se zadá název záložního souboru, kde je sada funkcí convert(varchar(1), datepart(dw, getdate())) se vrací do textový formát o délce 1 znaku aktuální den v týdnu (pondělí - 1 , úterý - 2 atd.) a přidá se přípona bak. Výstupem bude soubor s názvem GTD_číslo dne v týdnu.bak;
- záloha - vytvoří zálohu;
- databáze - označuje vytvoření zálohy celé databáze;
- GTD - v našem příkladu název databáze na SQL serveru;
- na disk - označuje typ zálohovacího úložného zařízení, souboru pevný disk a proměnná je zadána @s, kterému je přiřazena cesta a název vytvářeného souboru;
- s init, noformat, skip, nounload - označuje, že je nutné přepsat data do kruhu s předefinováním hlaviček, což nám umožní mít 7 záložních souborů na každý den v týdnu přepsaných do kruhu.
Podle potřeby můžete použít další funkce, jako je komprese, 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 musíte spustit ze stroje, kde je nainstalována databáze MS SQL.
Krok 3. Automatizujte tento proces
Zvažme tento krok na příkladu MS Windows Server 2008: Server Manager -> Configuration -> Job Scheduler -> Job Scheduler Library.