Sdílet prostřednictvím

Zálohovací aplikace SQL Serveru – Služba stínové kopie svazku (VSS) a Zapisovač SQL

Platí pro:SQL Server pro Windows

SQL Server zajišťuje podporu pro službu Stínová kopie svazku (VSS) tím, že poskytuje zapisovač (zapisovač SQL), aby zálohovací aplikace třetí strany mohla použít architekturu VSS k zálohování databázových souborů. Tento dokument popisuje komponentu zapisovače SQL a její roli při vytváření a obnovování snímků VSS pro databáze SQL Serveru. Zaznamenává také podrobnosti o tom, jak nakonfigurovat a používat zapisovač SQL k práci se zálohovanými aplikacemi v rozhraní VSS.

Infrastruktura VSS

VSS poskytuje systémovou infrastrukturu pro spouštění aplikací VSS v systémech Windows. I když je pro uživatele i vývojáře z velké části transparentní, VSS:

  • Koordinuje aktivity poskytovatelů, zapisovačů a žadatele při vytváření a používání stínových kopií.
  • Poskytuje výchozího poskytovatele systému.
  • Implementuje funkci ovladače nízké úrovně, která je nezbytná pro fungování libovolného poskytovatele.

Služba VSS se spouští na vyžádání, proto musí být tato služba povolená, aby operace VSS byly úspěšné.

Komponenty VSS

VSS koordinuje činnosti následujících spolupracujících komponent:

  • Zprostředkovatelé vlastní data stínové kopie a zálohují stínové kopie.

  • Zapisovače jsou aplikace, které mění data a účastní se procesu synchronizace stínové kopie.

  • Žadatelé zahajují vytváření a odstranění stínových kopií. Návrh se zaměřuje na scénář, ve kterém je žadatel záložní aplikací.

Služba VSS zajišťuje koordinaci mezi těmito stranami:

Diagram znázorňující, jak VSS zajišťuje koordinaci mezi stranami

Tento diagram znázorňuje všechny komponenty, které se účastní typické aktivity snímků VSS. V takovém scénáři SQL Server (včetně zapisovače SQL) funguje jako zapisovač v jednom z polí zapisovače. Další takové zapisovače můžou být Exchange Server atd.

  • Rozhraní virtuálního zařízení: SQL Server poskytuje aplikační programovací rozhraní s názvem VDI (Virtual Device Interface), které pomáhá nezávislým dodavatelům softwaru integrovat SQL Server do svých produktů tím, že poskytuje podporu operací zálohování a obnovení. Tato rozhraní API jsou navržena tak, aby poskytovala maximální spolehlivost a výkon a podporovala celou řadu funkcí zálohování a obnovení SQL Serveru, včetně celé řady funkcí horkého zálohování a zálohování snímků. Další informace naleznete v tématu SQL Server 2005 Virtual Backup Device Interface Specification.

  • Žadatel: Proces (automatizovaný nebo grafický uživatelské rozhraní), který požaduje, aby jedna nebo více sad snímků byla pořízena z jednoho nebo více původních svazků. V tomto článku se slovo "žadatel" používá k označení záložní aplikace, která vytváří snímek databází SQL Serveru.

Další informace viz služba stínové kopie svazku.

Zapisovač SQL

Zapisovač SQL je zapisovač VSS poskytovaný instancí SQL Serveru. Zpracovává interakci VSS s SQL Serverem. Zapisovač SQL se dodává s SQL Serverem jako samostatná služba a je nainstalován jako součást instalace SQL Serveru.

Role zapisovače SQL v operaci zálohování snímků VSS:

Snímek obrazovky se snímkem VSS

Konfigurace zapisovače SQL

Služba zápisu SQL je nainstalována v systému jako součást instalace SQL Serveru a je nakonfigurována tak, aby se spustila automaticky při spuštění Systému Windows.

Účet služby zápisu SQL

Během instalace se účet zapisovače SQL nainstaluje pro použití místního systémového účtu. Vzhledem k tomu, že zapisovač SQL potřebuje komunikovat s SQL Serverem pomocí výhradních rozhraní API VDI, musí mít účet zapisovače SQL dostatečná přístupová práva pro SQL Server i VSS. Konfigurace služby jako účtu místního systému poskytuje dostatečná práva, aby služba fungovala správně.

Důležité

Ujistěte se, že služba zápisu SQL běží pod místním systémovým účtem a že účet SQL Serveru NT SERVICE\SQLWriter je členem role správce systému .

Opětovné povolení a spuštění zapisovače SQL

Ve výchozím nastavení je služba zápisu SQL povolená a spouští se automaticky. Pokud byla tato konfigurace změněna, je potřeba provést následující kroky, abyste se vrátili k výchozímu nastavení:

Službu zápisu SQL lze povolit tak, že tuto službu označíte jako automatickou. Chcete-li otevřít služby prostřednictvím ovládacích panelů, vyberte Start, vyberte Ovládací panely, poklepejte na položku Nástroje pro správu a potom poklepejte na položku Služby. V podokně Služby poklikejte na službu zapisovače SQL a upravte vlastnost Typ spouštění na Hodnotu Automaticky.

Služba by se pak měla spustit výběrem tlačítka Start pod vlastností Stav služby na obrazovce vlastností služby uvedené výše.

Poznámka:

V některých případech, kdy je nainstalována instance SQL Server Express a aplikace používá funkci Uživatelské instance, může být zapisovač SQL automaticky spuštěn SQL Serverem. To se provádí kvůli usnadnění výčtu těchto instancí uživatelů během operace zálohování služby VSS.

Funkce podporované zapisovačem SQL

  • Plnotextový: Zapisovač SQL uvádí kontejnery plnotextového katalogu se specifikacemi rekurzivního souboru pod součástmi databáze v dokumentu metadat zapisovače. Když je vybraná součást databáze, automaticky se zahrnou do zálohy.

  • Rozdílové zálohování a obnovení: Zapisovač SQL podporuje rozdílové zálohování a obnovení prostřednictvím dvou rozdílových mechanismů VSS:

    • Částečný soubor: SQL zapisovač používá mechanismus částečného souboru VSS k hlášení změněných rozsahů bajtů v jeho databázových souborech.

    • Rozdílový soubor podle času poslední úpravy: Zapisovač SQL používá mechanismus VSS Differenced File by Last Modify Time (souborů modifikovaných naposledy) pro hlášení změněných souborů v fulltextových katalogech.

  • Obnovení s přesunutím: Zapisovač SQL během obnovení podporuje specifikaci nového cíle služby VSS. Specifikace New Target umožňuje přesunout kontejner databáze, soubor protokolu nebo fulltextového katalogu jako součást operace obnovení.

  • Přejmenování databáze: Žadatel může potřebovat obnovit databázi SQL Serveru s novým názvem, zejména pokud se má databáze obnovit vedle původní databáze. Zapisovač SQL podporuje přejmenování databáze během operace obnovení, pokud databáze zůstane v původní instanci SQL.

  • Zálohování jen pro kopírování: Někdy je nutné vytvořit zálohu, která je určená pro zvláštní účely, například když potřebujete vytvořit kopii databáze pro účely testování. Tato záloha by neměla mít vliv na celkové postupy zálohování a obnovení databáze. COPY_ONLY Použití možnosti určuje, že se zálohování provádí mimo pásmo a nemělo by mít vliv na normální sekvenci záloh. Zapisovač SQL podporuje typ zálohování jen pro kopírování s instancemi SQL Serveru.

  • Automatické obnovení snímku databáze: Snímek databáze SQL Serveru získané pomocí architektury VSS je obvykle v neobnoveném stavu. Data ve snímku se nedají bezpečně získat, než projdou fází obnovení, aby se vrátila zpět do testovacích transakcí a umístila databázi do konzistentního stavu. V rámci procesu vytváření snímků je možné, aby zálohovací aplikace VSS požadovala automatické obnovení snímků.

Tyto nové funkce a jejich použití jsou podrobněji popsány v podrobnostech možností zálohování a obnovení v tomto článku.

Co se nepodporuje

  • Zapisovač SQL nepodporuje zálohování protokolů.
  • Zálohování souborů a skupin souborů se nepodporuje.
  • Obnovení stránky se nepodporuje.
  • Snímky databáze nejsou podporovány a jsou ignorovány při vytváření komponentových i nekomponentových snímků VSS.
  • Automatické vytváření databází nebo databází s povoleným vypnutím
  • Linux neposkytuje architekturu VSS, a proto není zapisovač SQL dostupný v Linuxu.

Následující tabulka uvádí typy záloh snímků podporované zapisovačem SQL nebo SQL Serverem, které pracují s architekturou VSS pro všechny edice SQL Serveru ve Windows.

Operace zálohování a obnovení Založené na komponentách Bez komponent
Úplné zálohování dat
(Včetně plnotextového katalogu)		 Ano Ano
Úplné obnovení Ano Ano
Úplné obnovení (bez obnovení) Ano Ne
Rozdílové zálohování Ano Ne
Rozdílové obnovení Ano Ne
Obnovení s přesunem Ano Ne
Přejmenování databáze Ano Ne
Kopírovat pouze zálohu Ano Ne
Automaticky obnovené snímky Ano Ne
Zálohování logu Ne Ne
Snímky databáze Ne Ne
Automatické zavírání databází
Databáze s vypnutím		 Ano Ne
Databáze skupin dostupnosti Ano Ne na sekundární

Operace zálohování

SQL Server (pomocí zapisovače SQL) podporuje následující režimy operací zálohování založeného na VSS:

  • Bez komponent
  • Založené na komponentách

Podpora verzí

Zapisovač SQL se dodává jako součást SQL Serveru a podporuje pouze instance SQL Serveru. Zapisovač SQL vytvoří výčet instancí SQL Serveru Express, včetně uživatelských instancí spuštěných edicí SQL Server Express.

Operace zálohování, které nejsou založené na komponentách

Zálohy, které nejsou založené na komponentách, implicitně vybírají databáze pomocí seznamu svazků v sadě snímků. Zapisovač SQL prověřuje, zda databáze nejsou vytržené, a při nalezení vyvolá chybu. Roztrhaná databáze je databáze, ve které je vybrána podmnožina souborů v seznamu svazků.

V modelu, který není založený na komponentách, jsou podporovány pouze databáze s jednoduchým modelem obnovení. Pokračování po obnovení není podporováno.

Operace zálohování založené na komponentách

Zálohování založené na komponentách se upřednostňuje a doporučuje pro zapisovač SQL, protože aplikace (zálohovací aplikace VSS) explicitně vybere databáze z metadat vrácených ze zapisovače SQL. Sada snímků by měla obsahovat všechny svazky potřebné k zálohování těchto databází. Infrastruktura VSS automaticky nepřidá svazky, které jsou nezbytné pro požadovanou sadu databází. Všechny podpůrné svazky by měly být součástí sady snímků svazku. Je zodpovědností zálohovací aplikace, aby se zajistilo, že všechny záložní svazky jsou součástí sady snímků. Zapisovač SQL detekuje roztrhané databáze (se záložními svazky mimo sadu snímků) a zálohování selže.

Zbytek této části předpokládá, že se zálohy založené na komponentách používají jako součást procesu vytváření snímků VSS pro SQL Server.

Proces vytvoření snímku

Architektura VSS koordinuje aktivity žadatele (zálohovací aplikace) a zapisovače SQL během vytváření snímků SQL Serveru. Aby bylo možné tuto koordinaci povolit, architektura VSS definuje rozhraní žadatele a zapisovače. Tato rozhraní by měla implementovat aplikace a autoři žádající o účast. Zapisovač SQL implementuje potřebná rozhraní pro zápis. V rámci procesu vytváření snímků jsou rozhraní zapisovače SQL volána rámcem VSS. Zapisovač SQL komunikuje s instancemi SQL Serveru v systému za účelem usnadnění vytváření snímků.

Architektura VSS definuje sadu rozhraní API pro použití žadatelem nebo zálohovací aplikací. Vývojář zálohovací aplikace musí postupovat podle těchto vzorců volání rozhraní API, aby fungoval s procesem vytváření snímků architektury VSS. Další části popisují proces vytváření snímků z pohledu zapisovače SQL. Také podrobně uvádějí některé interní interakce mezi žadatelem, architekturou VSS, zapisovačem SQL a instancemi SQL Serveru.

Další informace o těchto krocích a podrobnosti o rozhraních rámce VSS naleznete v Služba stínové kopie svazku (VSS).

Poznámka:

Předpokládá se, že obecně znáte architekturu VSS a proces vytváření záloh. Tyto části jsou k dispozici jako doplňující informace o tom, jak se zapisovač SQL účastní procesu vytváření zálohování VSS.

Pracovní postup vytvoření snímku

Následující obrázek znázorňuje diagram toku dat během operace vytvoření nebo zálohování snímku založeného na komponentách.

Snímek obrazovky s tokem dat

Abyste lépe porozuměli základním úkolům, které jsou součástí zálohování, je užitečné tento přehled rozdělit do následujících fází:

Inicializace zálohování

Během této fáze zálohování se žadatel (zálohovací aplikace) naváže na rozhraní snímku IvssBackupComponents a inicializuje ho při přípravě na zálohování. Volá také rozhraní API IVssGatherWriterMetadata VSS, které informuje framework VSS, aby shromáždilo metadata ze všech zapisovačů.

Architektura VSS volá každého z registrovaných modulů, včetně modulu SQL, pro metadata zapisovače pomocí události OnIdentify. Zapisovač SQL se dotazuje instancí SQL Serveru, aby získal informace o zálohovaných metadatech pro každou databázi a vytvořil dokument metadat zapisovače. Tato fáze se také označuje jako výčet metadat.

Dokument metadat zapisovače je dokument obsahující informace, které jsou předávány zapisovačem žadateli zálohování (zálohovací aplikaci). Dokument metadat autora obsahuje následující informace:

  • ID aplikace a přátelský název
  • Kde existují soubory a komponenty
  • Které soubory je potřeba zahrnout a vyloučit do zálohy
  • Jaké možnosti by se měly použít při obnovení

To se předává zpět žadateli prostřednictvím rámce VSS.

Zjišťování záloh

V této fázi žadatel prozkoumá dokument metadat autora a vytvoří a vyplní dokument komponent zálohy každou komponentou, která je potřeba zálohovat. Určuje také potřebné možnosti zálohování a parametry v rámci tohoto dokumentu. Pro zapisovač SQL je každá instance databáze, kterou je potřeba zálohovat, samostatnou komponentou.

Dokument zálohovaných komponent

Jedná se o dokument XML vytvořený žadatelem (pomocí IVssBackupComponents rozhraní) v průběhu nastavování operace obnovení nebo zálohování. Dokument zálohovaných komponent obsahuje seznam explicitně zahrnutých komponent od jednoho nebo více zapisovačů, kteří se účastní operace zálohování nebo obnovení. Neobsahuje implicitně zahrnuté informace o komponentách. Naproti tomu dokument metadat writeru obsahuje pouze komponenty writeru, které se mohou účastnit zálohování. Strukturální podrobnosti dokumentu komponenty zálohování jsou popsány v dokumentaci k rozhraní API VSS.

Předzálohové úkoly

Předzálohové úlohy v rámci VSS se zaměřují na vytvoření stínové kopie svazků obsahujících data pro zálohování. Aplikace zálohování ukládá data ze stínové kopie, nikoli ze skutečného svazku.

Žadatelé obvykle čekají na zapisovače během přípravy na zálohování a během vytváření stínové kopie. Pokud se zapisovač SQL účastní operace zálohování, musí nakonfigurovat své soubory a také sám, aby byl připravený na zálohování a stínovou kopii.

Příprava na zálohování

Žadatel musí nastavit typ operace zálohování, kterou je potřeba provést (IVssBackupComponents::SetBackupState) a pak upozorní zapisovače prostřednictvím VSS, aby se připravila na operaci zálohování pomocí IVssBackupComponents::PrepareForBackup.

Zapisovač SQL má přístup k dokumentu zálohované komponenty, který podrobně popisuje, jaké databáze je potřeba zálohovat. Všechny podpůrné svazky by měly být součástí sady snímků svazku. Zapisovač SQL detekuje roztrhané databáze (se záložními svazky mimo sadu snímků) a při události PostSnapshot zálohování nebude úspěšné.

Skutečné zálohování souborů

V této fázi může žadatel v případě potřeby přesunout data na záložní médium. Interakce v této fázi jsou mezi žadatelem a architekturou VSS. Zapisovač SQL není zapojen.

  1. Získejte status spisovatele. Vrátí stav autorů. Žadatel možná bude muset zpracovávat případné chyby.
  2. Proveďte zálohování.

Žadatel může v tuto chvíli přesunout data k zálohování médií v případě potřeby.

Zálohování dokončeno

Tato událost označuje, že zálohování bylo úspěšně dokončeno.

Toto je také čas, kdy může SQL záznamník potvrdit zálohu jako základ pro diferenciální zálohy, pokud je aktuální záloha úplnou zálohou databáze (nikoli pouze kopírovací záloha).

Poznámka:

Žadatel by měl tuto událost (událost dokončení zálohování) odeslat explicitně, aby zapisovač SQL mohl potvrdit rozdílové základní zálohy. Pokud tato událost není přijata, vytvořená záloha není způsobilá jako základní záloha pro rozdílové zálohování.

Uložit metadata autora

Žadatel by měl uložit dokument komponenty zálohování a metadata zálohování jednotlivých komponent spolu s daty zálohovanými ze snímku. Tato metadata zapisovače jsou potřebná zapisovačem SQL nebo SQL Serverem pro operace obnovení.

Ukončení zálohování

Žadatel ukončí stínovou kopii uvolněním IVssBackupComponents rozhraní nebo voláním IVssBackupComponents::DeleteSnapshots.

Dokument zápisu metadat SQL

Jedná se o dokument XML vytvořený zapisovačem (v tomto případě zapisovačem SQL) pomocí IVssCreateWriterMetadata rozhraní a obsahující informace o stavu a komponentách zapisovače. Strukturální detaily zápisu metadat jsou popsány v dokumentaci k rozhraní API VSS. Tady jsou některé podrobnosti dokumentu metadat zápisu SQL.

  • Identifikační informace autora

    • Writer name – L"SqlServerWriter"
    • ID třídy Writer – 0xa65faa63, 0x5ea8, 0x4ebc, 0x9d, 0xbd, 0xa0, 0xc4, 0xdb, 0x26, 0x91, 0x2a
    • ID instance zapisovače – L"SQL Server:SQLWriter"
    • VSSUsageType – VSS_UT_USERDATA
    • VSSSourceType – VSS_ST_TRANSACTEDDB

  • Informace o úrovni zapisovače – VSS_APP_BACK_END

  • Specifikace metody obnovení – VSS_RME_RESTORE_IF_CAN_REPLACE.

  • Podporované schéma zálohování (IVssCreateWriterMetadata::SetBackupSchema API)

    • VSS_BS_DIFFERENTIAL – rozdílové zálohování
    • VSS_BS_TIMESTAMPED – založené na časovém razítku – pro soubory fulltextového katalogu.
    • VSS_BS_LAST_MODIFY – rozdílové zálohování na základě času poslední úpravy
    • VSS_BS_WRITER_SUPPORTS_NEW_TARGET – podporuje novou možnost cílového umístění.
    • VSS_BS_WRITER_SUPPORTS_RESTORE_WITH_MOVE – podporuje obnovení "s přesunem".
    • VSS_BS_COPY – podporuje možnost zálohování jen pro kopírování.

  • Informace o úrovni komponenty (obsahuje informace specifické pro jednotlivé komponenty poskytované zapisovačem SQL)

    • Typ – VSS_CT_FILEGROUP
    • Název – název komponenty (název databáze)
    • Logická cesta – instance serveru (ve formě "server\název_instance" pro pojmenované instance a "server" pro výchozí instanci.)
    • Příznaky komponent
    • VSS_CF_APP_ROLLBACK_RECOVERY – označuje, že snímky SQL Serveru vždy vyžadují fázi obnovení, aby soubory byly konzistentní a použitelné pro scénáře bez zálohování (tj. vrácení aplikace).
    • Vybratelné – Pravda
    • Vybratelné pro obnovení – True
    • Podporované metody obnovení – VSS_RME_RESTORE_IF_CAN_REPLACE

Jediným rozšířením struktury sady komponent v SQL Serveru je zavedení fulltextových katalogů. Fulltextové katalogy jsou adresáře kontejnerů, které nelze vyjádřit jako databáze VSS nebo soubory protokolů, protože databáze VSS a soubory protokolů nemají rekurzivní specifikaci. Proto zapisovač SQL používá komponentu VSS filegroup (VSS_CT_FILEGROUP) k reprezentaci komponenty na úrovni databáze a souborů skupiny souborů, aby představovala soubory databáze, protokolu a fulltextového katalogu.

Na konci tohoto dokumentu je k dispozici ukázkový dokument zapisovače metadat.

Spustit snímek

Žadatel zahájí proces vytvoření snímku voláním rozhraní VSS Framework DoSnapshotSet.

Vytvořit snímek

Tato fáze zahrnuje řadu interakcí mezi architekturou VSS a zapisovačem SQL.

  1. Příprava na snímek SQL zapisovač volá SQL Server, aby se připravil na vytvoření snímku.

  2. Ukotvit. Zapisovač SQL volá SQL Server, aby zmrazil veškeré databázové vstupně-výstupní operace pro každou z databází zálohovaných ve snímku. Jakmile se událost ukotvení vrátí do architektury VSS, vytvoří VSS snímek.

  3. Rozmrzlý. Při této události zapisovač SQL volá instance SQL Serveru k rozmrazování nebo obnovení normálních vstupně-výstupních operací.

Fáze vytvoření snímku trvá méně než 60 sekund, aby se zabránilo blokování všech zápisů do databáze.

Po snímku

Pokud je pro snímek nutné automatické obnovení, zapisovač SQL provede automatické obnovení pro každou databázi, která byla vybrána, aby byla ve snímku. Podrobné vysvětlení najdete v tématu Automaticky obnovené snímky.

Proces obnovení

Tato část popisuje pracovní postup operace obnovení a různé kroky.

Pracovní postup operace obnovení

Následující obrázek znázorňuje diagram toku dat během operace obnovení VSS.

Snímek obrazovky s tokem procesu obnovení

Pokud chcete lépe porozumět základním úkolům, které jsou součástí provádění obnovení, je užitečné tento přehled rozdělit do následujících částí:

Ve všech scénářích obnovení založeném na komponentách VSS zajišťuje obnovení databáze zapisovač SQL ve dvou různých fázích.

  • Předběžné obnovení: Zapisovač SQL zpracovává ověřování, zavírání popisovačů souborů atd.
  • Po obnovení: Zapisovač SQL připojí databázi a v případě potřeby provede obnovu po pádu systému.

Mezi těmito dvěma fázemi zodpovídá zálohovací aplikace za přesun relevantních dat pod SQL.

Obnovení inicializace

Během fáze inicializace obnovení musí žadatel mít přístup k dokumentům uložených komponent zálohování.

Dokument komponenty zálohování, který je generován během operace zálohování, je uložen jako součást zálohovaných dat. Aplikace zálohování musí tato data předat zpět do architektury VSS. Zapisovač SQL získá přístup k datům na začátku procesu obnovení.

Příprava na obnovení

Když žadatel připraví obnovení, použije dokument uložených komponent zálohování k určení, co se má obnovit a jak. Žadatel vybere komponenty, které se mají obnovit, a podle potřeby nastaví odpovídající možnosti obnovení.

Pokud aplikace zálohování hodlá použít rozdílové zálohy nebo zálohy protokolů nad aktuální operací obnovení (tj. obnovení s norecovery je potřeba), měla by být v rámci vytváření součástí pro každou obnovenou databázi nastavena následující možnost.

IVssBackupComponents::SetAdditionalRestores(true)

Jakmile jsou v dokumentu zálohované komponenty nastaveny všechny potřebné podrobnosti, žadatel provede IVssBackupComponents::PreRestore volání k vygenerování události předběžného obnovení prostřednictvím VSS, která je zpracována zapisovači.

Zapisovač SQL zkontroluje zadaný dokument komponenty zálohování a identifikuje příslušné databáze a odstraní všechny další soubory vytvořené od doby zálohování. Kontroluje také místo na disku a zavře všechny otevřené databázové soubory, aby žadatel mohl zkopírovat potřebná data během fáze obnovení. Tato fáze umožňuje zjištění jakýchkoli počátečních chybových podmínek předtím, než žadatel provede kopírování skutečného souboru. SQL Server také umístí databázi do stavu obnovení. Od tohoto okamžiku nelze databázi spustit, dokud nebude úspěšné obnovení.

Obnovení souborů

Jedná se pouze o akci specifickou pro žadatele. Žadatel (zálohovací aplikace) zodpovídá za kopírování potřebných databázových souborů (nebo kopírování příslušných oblastí dat pro rozdílové obnovení) na příslušná místa. Do této operace není zapojen zapisovač SQL.

Vyčištění a ukončení

Jakmile se všechna data obnoví na správná místa, volání žadatele s oznámením, že operace obnovení byla dokončena IvssBackupComponents::PostRestore, umožní zapisovači SQL vědět, že lze spustit akce po obnovení. Zapisovač SQL v tomto okamžiku provede fázi redo obnovy po havárii. Pokud není požadováno obnovení (tj SetAdditionalRestores(true) . není určeno žadatelem), provede se během této fáze také fáze vrácení zpět kroku obnovení.

Podrobnosti o možnosti zálohování a obnovení

Tato část podrobně popisuje všechny možnosti zálohování a obnovení podporované zapisovačem SQL.

Žadatel vytvoří stínovou kopii svazku.

Zapisovač SQL může být zapojen do procesu vytváření stínové kopie svazku (mimo kontext zálohování a obnovení), protože záložní svazky pro soubory databáze byly přidány do sady snímků svazku. V tomto případě se zapisovač SQL účastní pouze výčtu metadat, Freeze, Thaw, PrepareForSnapshota PostSnapshot koordinace (podrobnosti viz diagram toku dat).

Úplné zálohování a obnovení

Zapisovač SQL podporuje operace úplného zálohování a obnovení v režimu bez komponent i v režimu založeném na komponentách.

Zálohování a obnovení nezaložené na komponentách

Při zálohování a obnovování nezaloženém na komponentách žadatel určuje svazek nebo strom složek, které se mají zálohovat a obnovit. Všechna data v zadaném svazku a složce se zálohuje a obnoví.

Backup

Při zálohování nezaloženém na komponentách zapisovač SQL implicitně vybírá databáze pomocí seznamu svazků v sadě snímků. Autor kontroluje poškozené databáze a v případě nalezení vyvolá chybu. Roztrhaná databáze je databáze, ve které je vybrána podmnožina souborů v seznamu svazků. Roll-forward (rozdílové obnovení nebo obnovení protokolu) po obnovení není podporováno prostřednictvím zapisovače SQL.

Obnovit

Žadatel obnoví databáze zálohované v režimu, který není založený na komponentách. Po takových obnoveních nelze provést navazující obnovení, jako je obnovení protokolu nebo rozdílové obnovení.

V případě operací obnovení, které nejsou založené na komponentách, je nutné provést obnovení s instancí SQL Serveru offline nebo jsou cílové databáze vyřazeny nebo odpojeny, aby se zajistilo, že jsou soubory offline. Soubory se zkopírují na místo a poté se databáze připojí. K tomu dochází mimo rozsah zapisovače SQL.

Zálohování a obnovení založené na komponentách

V zálohování založeném na komponentách žadatel explicitně vybere databázové komponenty (z metadat, která zapisovač SQL vrátí klientovi), aby se zálohovaly nebo obnovily.

Backup

Při zálohování založeném na komponentách by měly být všechny záložní svazky pro vybrané databáze zahrnuty do sady snímků svazků. Jinak zapisovač SQL detekuje databáze roztrhané (se záložními svazky mimo sadu snímků) a zálohování selže. Úplná záloha zálohuje data databáze a všechny soubory protokolu potřebné k tomu, aby databáze byla v době obnovy transakčně konzistentní.

Úplné obnovení bez vrácení vpřed

Úplné obnovení zálohy databáze se někdy provádí bez dalšího postupného obnovení. Důvodem může být to, že neexistuje žádné metadat, které by usnadnilo posun vpřed, nebo v některých případech není potřeba provést rolování vpřed. Tato část se stručně věnuje těmto dvěma situacím.

Žádná metadata/žádný posun vpřed

Pokud během operace zálohování nejsou uložena žádná metadata zápisu (metadata zálohování založená na komponentách), je nutné provést obnovení s instancí SQL Serveru offline nebo se cílové databáze zahodí nebo odpojí, aby se zajistilo, že jsou soubory offline. Soubory se zkopírují na místo a poté se databáze připojí. K tomu dochází mimo rozsah zapisovače SQL.

Metadata existují, ale není potřeba provést další posun vpřed.

Žadatel obnoví databáze, které byly zálohovány v režimu založeném na komponentách, ale není požadováno žádné pokračování procesu obnovy. V takovém případě SQL Server provádí obnovení databáze při selhání v rámci obnovení.

Úplné obnovení s dodatečným pokročením vpřed

Žadatel může vydat příkaz obnovit s možností SetAdditionalRestores(true). Tato možnost značí, že žadatel bude pokračovat v dalších obnoveních (například obnovení protokolů, rozdílové obnovení atd.). To dává SQL Serveru pokyn, aby na konci operace obnovení neprovádí krok obnovení.

To je možné pouze v případě, že se metadata zápisu uložila během zálohování a je k dispozici pro zapisovač SQL v době obnovení. Služba SQL Serveru musí být spuštěná, než žadatel směruje službu VSS k provedení aktivity obnovení.

Zapisovač SQL očekává následující sekvenci:

  1. Příprava na obnovení každé databáze Tato aktivita zahrnuje zavření všech popisovačů souborů, aby žadatelská aplikace mohla zkopírovat nebo připojit databázové soubory.

  2. Soubory jsou zkopírovány nebo připojeny aplikací žadatele.

  3. Dokončete obnovení (pomocí NORECOVERY). Databáze jsou online, ale ve stavu obnovení.

Běžné zálohy, rozdílové zálohování nebo logy SQL Serveru je pak možné použít k postupné obnově databáze pomocí VDI nebo Transact-SQL, nebo uplatněním rozdílové obnovy pomocí rámce VSS.

Podpora celotextového hledání

Zapisovač SQL hlásí kontejnery fulltextového katalogu s rekurzivními specifikacemi souborů v dokumentu metadat zapisovače mezi komponentami databáze. Když je vybraná součást databáze, automaticky se zahrnou do zálohy.

Rozdílové zálohování a obnovení

Rozdílová operace zálohování zálohuje pouze data, která se od poslední základní úplné zálohy změnila. Rozdílové zálohování obsahuje pouze ty části souborů databáze, které se změnily. Aby bylo možné provést takovou zálohu, žadatel (zálohovací aplikace) by potřeboval informace o umístění změn v souborech databáze, aby bylo možné zálohovat příslušné části souborů. Během rozdílové operace zálohování zapisovač SQL poskytuje tyto informace ve formátu určeném částečnými informacemi o souboru VSS. Tyto informace lze použít k zálohování pouze změněné části databázových souborů.

Backup

Žadatel může vydat rozdílovou zálohu nastavením možnosti DIFFERENTIAL v dokumentu komponenty zálohování VSS_BT_DIFFERENTIAL při zahájení operace zálohování se službou VSS IVssBackupComponents::SetBackupState. Zapisovač SQL předává částečné informace o souboru (vrácené sql Serverem) službě VSS. Žadatel může získat informace o tomto souboru voláním rozhraní API IVssComponent::GetPartialFileslužby VSS . Tyto částečné informace o souborech umožňují žadateli zvolit pouze změněné rozsahy bajtů, které se mají zálohovat pro soubory databáze.

Během fáze úloh před zálohováním zapisovač SQL zajistí, aby pro každou vybranou databázi existoval jeden rozdílový základ.

PostSnapshot Během události zapisovač SQL získá částečné informace o souboru z SQL Serveru a přidá ho do záložního dokumentu komponenty pomocí IVssComponent::AddPartialFile volání.

Poznámka:

Zapisovač SQL podporuje pouze jednu základní úroveň pro rozdílové zálohy. Více základních linií není podporováno.

Částečný formát informací o souboru

Pro každou databázi, která je zálohována během rozdílového zálohování, ukládá SQL zapisovač informace o částečných souborech pro každý soubor databáze. Tyto informace používá žadatel nebo zálohovací aplikace ke kopírování pouze relevantních částí souboru do záložního média během skutečného zálohování souborů.

Další informace o formátu pro tyto částečné informace o souboru naleznete v tématu Služba stínová kopie svazku (VSS).

Žadatel může tyto soubory určit voláním IVssComponent::GetPartialFileCount a IVssComponent::GetPartialFile. IVssComponent::GetPartialFile vrátí cestu a název souboru odkazující na soubor a řetězec rozsahů označující, co je potřeba zálohovat v souboru.

Další informace o načítání částečných informací o souboru najdete v dokumentaci VSS.

Zálohování souborů

Během této fáze by se aplikace zálohování měla podívat na metadata zapisovače uložená v dokumentu záložní komponenty a zálohovat pouze relevantní části souborů. (U souborů fulltextového katalogu by se tato záloha měla provést na základě časových razítek souboru. Toto je popsáno dále v tomto článku).

Rozdílové zálohování vždy souvisí s nejnovější základní zálohou, která existuje pro databázi. V době obnovení SQL Server detekuje neshodné základní a rozdílové zálohy. Proto je odpovědností správce zálohovací aplikace nebo systému, aby byl rozdíl vzhledem k očekávanému úplnému zálohování relativní. Pokud některá procedura mimo pásmo vytvořila další úplnou zálohu, aplikace zálohování nemusí být schopná obnovit rozdílové zálohování, protože nevlastní základní zálohu.

Pokud jsou informace o bajtovém rozsahu (částečné informace o souboru) příliš velké (větší než 64 kB ve velikosti vyrovnávací paměti), SQL Server vyvolá chybu s pokynem, aby uživatel provedl úplné zálohování.

Řešení problémů

Přidání, odstranění, zmenšení, zvětšení, logické přejmenování a fyzické přejmenování představují zajímavé případy při řízení potíží se zálohováním.

Nově přidané soubory po vytvoření základu

Tyto soubory jsou součástí částečné specifikace, protože každá hlavička souboru databáze musí být v částečné specifikaci. Kromě stránky záhlaví musí být všechny přidělené stránky zahrnuty do částečné specifikace.

Soubory ztracené po obsazení základny

Po vytvoření základu je možné datové soubory vynechat. Tyto soubory nejsou součástí dokumentu metadat zapisovače během rozdílové zálohy. Kromě toho nejsou k vyřazeným souborům přidruženy žádné částečné informace.

Soubory se zmenšily po provedení základu.

Částečné informace se ze souborů neshromažďují, dokud není na serveru zakázáno zmenšování souborů. Tím se zajistí, že služba VSS nikdy neobsahuje žádné částečné informace, které odpovídají oblasti shrunkování datového souboru.

Soubory zvětšené po vytvoření základní kopie

Pokud došlo k růstu před shromážděním částečných informací, měly by částečné informace zahrnovat přidělené stránky v rozšířené oblasti. Pokud se růst uskutečnil po shromáždění částečných informací, částečné informace nezahrnují změny v rostoucí oblasti. V následujících částech uvidíte, že tyto změny jsou obnovovány převíjením protokolu dopředu.

Soubor se po vytvoření základu logicky přejmenoval.

Logické přejmenování souboru nemá vliv na zálohování ani obnovení, protože na logický název souboru se neodkazuje nikde v dokumentu metadat zápisu nebo v dokumentu zálohované komponenty.

Další informace najdete v dokumentu metadat writeru: Příklad dále v tomto článku.

Soubor byl fyzicky přejmenován po provedení základního kroku.

Přejmenování fyzického souboru databáze se neprojeví, dokud se databáze nerestartuje. Proto informace o konfiguraci databáze nebo informace o cestě k souboru v částečné vyrovnávací paměti informací jsou stále založené na starých fyzických cestách, což jsou jediné platné cesty k těmto souborům databáze na snímku.

Obnovit

Během rozdílového obnovení obsahuje metadata zálohování, která žadatel vrátí zapisovači SQL, informace o typu zálohování. Proto není zapotřebí žádné zvláštní zacházení se zapisovačem SQL. SQL Server automaticky zjistí, že se jedná o diferenciální obnovení. SQL Server zpracovává takové rozdílové obnovení stejným způsobem jako nativní rozdílové obnovení, které není prováděno pomocí VSS.

Fáze předběžného obnovení

Během této fáze SQL Server změní velikost všech souborů na odpovídající velikost na základě metadat souborů rozdílového zálohování. Pokud se soubor rozšíří, SQL Server vynuluje rozšířenou část. Pokud se musí vytvořit nový soubor (byl vytvořen po vytvoření základního souboru), SQL Server vynuluje nový soubor. Zavře také všechny popisovače souborů, aby zálohovací aplikace mohla přepsat soubory obnovenými daty ze záložního média.

Obnovení souborů

Klient by měl obnovit soubory na základě částečné specifikace souboru. Data by se měla obnovit do stejného posunu nebo rozsahu souboru databáze, jak je uvedeno ve specifikaci částečného souboru uloženého v metadatech zapisovače.

Operace s databázovými soubory jako přidání/odstranění/růst/zmenšení/logické přejmenování/fyzické přejmenování opět vytváří zajímavé situace při řešení problémů během obnovy.

Pokud byl po provedení úplné zálohy přidán soubor databáze.

Tyto soubory musí být předem vytvořeny SQL Serverem během fáze přípravy obnovení. Měly by být rozšířeny na správnou velikost a vynulovány. Klient potřebuje pouze stanovit data podle částečné specifikace (částečná specifikace zahrnuje všechny přidělené rozsahy).

Pokud byl soubor databáze odstraněn po provedení úplného zálohování.

Částečné informace, které SQL Server poskytl, neobsahují žádné informace o sledování těchto souborů. SQL Server zodpovídá za detekci souborů, které se mají odstranit, porovnáním metadat obnovených souborů s existujícími kontejnery a jejich odstraněním. To se provádí před obnovením jako přípravný krok.

Pokud se soubor databáze zvětšil od doby, kdy byla pořízena plná záloha.

Tyto soubory musí být během přípravné fáze obnovení rozšířeny na správnou velikost SQL Serveru. Rozšířená oblast musí být také sql Serverem vynulována. Proto může klient bezpečně uložit data i v rozvinuté oblasti podle částečné specifikace. Pokud se soubor zvětšil po zaznamenání částečných informací, změny v rozšířené oblasti se obnoví tak, že se přehraje protokol, který byl zálohován spolu s rozdílovou zálohou.

Pokud se soubor databáze od úplné zálohy zmenšil.

SQL Server zodpovídá za zkrácení souboru na požadovanou velikost podle metadat. To se provádí před obnovením jako přípravný krok.

Pokud byl soubor databáze logicky přejmenován od doby, kdy byla přijata úplná základna

To nemá vliv na obnovení, protože logický název se nezobrazuje v dokumentu metadat zápisu ani v dokumentu zálohované komponenty. Změna logického názvu se obnoví, když klient použije změnu na primární databázový soubor, který obsahuje informace o systémovém katalogu.

Pokud byl soubor databáze fyzicky přejmenován od doby vytvoření úplné zálohy

Pokud se do doby rozdílového zálohování neprojeví přejmenování, klient stále obnoví data do starého umístění. Restartování databáze po obnovení způsobí, že se fyzické přejmenování projeví. Pokud se v době rozdílového zálohování projevilo přejmenování fyzického souboru, pak se částečná data (pokud existuje) zálohují z nové fyzické cesty.

Po obnovení

Během událostí po obnovení provede zapisovač SQL normální operaci opětovného obnovení a obnovení databáze (pokud SetAdditionalRestores() je nastaven na False).

Rozdílové zálohování a obnovení pro fulltextové katalogy

Fulltextové katalogy SQL Serveru jsou součástí databázových prostředků, které je potřeba zálohovat nebo obnovovat společně se zbývajícími soubory databáze. Rozdílové zálohování je založené na časových razítkách pro katalog plného textu. Rozdílové zálohování a obnovení pomocí VSS v SQL Serveru má jednu základní zálohu. Jinými slovy, neexistují různé základny pro různé kontejnery. U zálohování fulltextového katalogu VSS to znamená, že pro všechny kontejnery fulltextového katalogu je rozdílové zálohování založené na jednom časovém razítku, na rozdíl od nativního rozdílového zálohování SQL Serveru, kde má každý kontejner fulltextového katalogu své vlastní základní časové razítko.

Ve službě VSS se toto časové razítko vyjadřuje jako vlastnost pro celou součást, která je nastavena během úplného zálohování, a používá se během následného rozdílového zálohování.

OnIdentify

V OnIdentify zapisovač SQL volá IVssCreateWriterMetadata::SetBackupSchema() k nastavení hodnoty VSS_BS_TIMESTAMPED. To značí zálohovací aplikaci, že zapisovač SQL vlastní správu rozdílové základny.

Nastavte základní časové razítko

Základní časové razítko je nastavené během úplného zálohování. V OnPostSnapshot()zapisovač vyvolá IVssComponent::SetBackupStamp() k uložení časového razítka s komponentou v záložním dokumentu.

Rozdílové zálohování

Aplikace zálohování načte toto časové razítko z plné základní zálohy a zpřístupní jej pro zapisovače tím, že vyvolá IVssComponent::GetBackupStamp() pro načtení základního razítka z předchozí základní zálohy. Pak jej zpřístupní pro zapisovače voláním IVssBackupComponent::SetPreviousBackupStamp(). Zapisovatel pak načte razítko voláním IVssComponent::GetPreviousBackupStamp() a převede jej na časové razítko použité pro IVssComponent::AddDifferencedFilesByLastModifyTime().

Odpovědnost zálohovací aplikace během rozdílového zálohování

Během rozdílového zálohování zodpovídá zálohovací aplikace za:

  • Zálohování libovolného souboru (celého souboru), jehož časové razítko poslední změny je větší než časové razítko určené časem poslední úpravy souboru nastaveného v komponentě.

  • Sledování a zjišťování odstraněných souborů

Odpovědnosti zálohované aplikace během rozdílového obnovení

Během rozdílového obnovení zodpovídá zálohovací aplikace za:

  • Obnovení všech zálohovaných souborů buď vytvořením nového souboru, pokud ještě neexistuje, nebo přepsáním existujícího souboru, pokud již existuje.

  • Zvětšení souboru před rozložením obsahu, pokud je obnovený soubor větší než existující soubor.

  • Zkrácení souboru na stejnou velikost jako u obnoveného souboru, pokud je obnovený soubor menší než existující soubor.

  • Odstranění všech souborů, které by měly být odstraněny; to znamená soubory, které nemají existovat k okamžiku rozdílového zálohování.

Zálohování pouze kopírování

Někdy je potřeba vytvořit zálohu, která je určená pro zvláštní účely. Můžete například potřebovat vytvořit kopii databáze pro účely testování. Tato záloha by neměla mít vliv na celkové postupy zálohování a obnovení databáze. COPY_ONLY Použití možnosti určuje, že se zálohování provádí mimo pásmo a nemělo by mít vliv na normální sekvenci záloh. Zapisovač SQL podporuje typ zálohování jen pro kopírování s instancemi SQL Serveru.

Během fáze zjišťování zálohování zapisovač SQL indikuje jeho schopnost provádět zálohování pouze kopírování nastavením podporované možnosti VSS_BS_COPY schématu zálohování pomocí IVssCreateWriterMetadata::SetBackupSchema volání. Žadatel může nastavit typ zálohování jako zálohu typu 'pouze kopírování' nastavením volby VSS_BACKUP_TYPE jako VSS_BT_COPY při volání IVssBackupComponents::SetBackupState.

Při výběru zálohy jen pro kopírování se předpokládá, že se soubory na disku zkopírují do záložního média (žadatelem) bez ohledu na stav historie zálohování jednotlivých souborů. SQL Server neaktualizuje historii zálohování. Tento typ zálohování nepředstavuje základní zálohu pro další rozdílové operace zálohování a také neruší historii předchozích rozdílových záloh.

Obnovení s přesunem

VSS umožňuje žadateli (zálohovací aplikaci) zadat nový cíl obnovení pomocí IVssComponent::SetNewTarget volání. V obou PreRestore() a PostRestore() zapisovač SQL zkontroluje, jestli je zadaný alespoň jeden nový cíl. Za fyzické kopírování souborů do nového umístění během skutečného obnovení a kopírování je zodpovědná zálohovací aplikace.

Zálohovací aplikace může zadat pouze nové cíle pro fyzickou cestu, ale ne specifikaci souboru. Například u databázového souboru umístěného na c:\data\test.mdfadrese se skutečný název test.mdf souboru nedá změnit. Změnit lze pouze cestu c:\data . Pro kontejner fulltextového katalogu umístěný v c:\ftdata\fooumístění , protože specifikace souboru ve VSS je "*" a specifikace cesty ve VSS je c:\ftdata\foo, lze změnit celou cestu.

Přejmenování databáze

Žadatel může potřebovat obnovit databázi SQL Serveru s novým názvem, zejména pokud se má databáze obnovit vedle původní databáze. Tuto možnost může žadatel zadat během operace obnovení tak, že pomocí volání < VSS (v parametru>) nastaví vlastní možnost obnovení na hodnotu New Component Name (IVssBackupComponents::SetRestoreOptions()Název novéwszRestoreOptions komponenty).

Zapisovač SQL přebírá celý obsah hodnoty názvu nové komponenty a používá ho jako nový název obnovené databáze. Pokud není zadána žádná možnost, SQL Server obnoví databázi s původním názvem (název komponenty).

Poznámka:

Zapisovač SQL v současné době nepodporuje přejmenování mezi instancemi , aby se databáze přesunula do nové instance.

Automaticky obnovené snímky

Snímek databáze SQL Serveru získané pomocí architektury VSS je obvykle v neobnoveném stavu. Data ve snímku nelze bezpečně přistupovat před dokončením fáze obnovy pro vrácení probíhajících transakcí a uvedení databáze do konzistentního stavu. Vzhledem k tomu, že je snímek ve stavu jen pro čtení, nelze ho obnovit normálním procesem připojení databáze.

V rámci procesu vytváření snímků je možné snímky automaticky obnovit. Jako součást dokumentu metadat zapisovače určuje zapisovač SQL příznak komponenty VSS_CF_APP_ROLLBACK_RECOVERY, který naznačuje, že je potřeba provést obnovení databáze na snímku před tím, než bude možné k databázi získat přístup. Při zadávání sady snímků může žadatel určit, zda by snímek měl být snímkem zpětného vrácení aplikace (to znamená, že všechny soubory databáze ve snímku jsou určeny k použití aplikace v konzistentním stavu) nebo záložním snímkem (snímek používaný k zálohování dat, která mají být obnovena později v případě selhání systému).

Žadatel by měl nastavit VSS_VOLSNAP_ATTR_ROLLBACK_RECOVERY , aby naznačil, že tato komponenta se zálohuje pro účely nesouvisejí se zálohováním. Služba VSS pak spojuje VSS_CF_APP_ROLLBACK_RECOVERY se SQL zapisovačem, který je uveden na vybrané komponentě VSS_VOLSNAP_ATTR_ROLLBACK_RECOVERY, a určuje, že probíhá automatické obnovení. VSS umožňuje zapsat snímek po omezenou dobu a automaticky přidat VSS_VOLSNAP_ATTR_AUTORECOVERY bit do kontextu snímku.

Ve SQL Serveru by se mělo automatické obnovování použít jen na snímky návratu aplikace, ale ne na snímky záloh. Pro snímky vrácení aplikace je proces automatického obnovení inicializován zapisovačem SQL během PostSnapShotevent. Tento proces provede následující kroky pro každou explicitně vybranou databázi SQL Serveru (žadatelem) v sadě snímků:

  • Připojte databázi snímků k původní instanci SQL Serveru (to znamená instanci, ke které je původní databáze připojena).

  • Obnovte databázi (k tomu dochází v rámci operace připojení).

  • Zmenšete soubory protokolu.

    To snižuje množství nepotřebných zápisů při kopírování, které je potřeba provést architekturou VSS, pokud je poskytovatel VSS poskytovatelem softwaru. Zmenšení souborů protokolu je výchozí chování. To lze zakázat nastavením hodnoty na následující klíč registru 1.

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SQLWriter\Settings\DisableLogShrink

    To může být užitečné ve scénářích, kdy se snímek může použít k exportu dat z konkrétní stránky (v určitém okamžiku) z protokolu k vyřešení problému v online databázi.

  • Odpojte databázi.

Teď je k dispozici konzistentní obnovený snímek, který je možné připojit k dotazování.

Transakce s více databázemi

Ve starších verzích SQL Serveru můžou snímkové databáze někdy obsahovat probíhající transakce s více databázemi. Během operace obnovení zapisovač SQL připojí databázi uloženou na snímkách s možností předpokládaného ukončení. Tím by se zrušily všechny transakce mezi více databázemi, které ještě nejsou potvrzeny (včetně všech transakcí, které jsou ve stavu připravené k potvrzení). To může vést k nekonzistence mezi databázemi v sadě snímků.

Představte si například dvě databáze A a B. Mezi těmito dvěma databázemi existuje distribuovaná transakce a tato transakce je v databázi A ve stavu Potvrzeno a připraveno k potvrzení v databázi B. V rámci procesu automatického zjišťování je tato transakce potvrzena v databázi A a vrácena zpět v databázi B. To může vést k nekonzistence v sadě snímků.

Novější verze Systému Windows mají vylepšenou komponentu MS DTC (Microsoft Distributed Transaction Coordinator), která řeší tento problém s konzistencí pro transakce zahrnující databáze napříč instancemi SQL Serveru. Novější verze SQL Serveru opravují tyto nekonzistence pro transakce, které pokrývají databáze v instanci SQL Serveru.

Vliv na zabezpečení pro automaticky obnovené snímky

U snímků VSS jsou soubory po automatickém obnovení zabezpečené pomocí seznamů řízení přístupu (ACL) a umožňují přístup pouze ke speciální předdefinované skupině, do které patří účet SQL Serveru. To znamená, že členové buď správce boxu, nebo že speciální skupina mohou připojit databázi. Klient, který žádá o připojení databázových souborů na snímku, musí být členem Builtin/Administrators nebo účtem SQL Serveru.

Uživatelské databáze modelu jednoduchého obnovení

master Pokud je databáze obnovena společně s uživatelskými databázemi, které používají jednoduchý model obnovení, je možné uživatelské databáze obnovit stejnou technikou jako master databáze: s vypnutou instancí stačí zkopírovat nebo připojit svazky. Po spuštění instance SQL se všechno obnoví.

Průběžné předávání uživatelských databází

Pokud mají být uživatelské databáze obnoveny a posunuty dopředu společně s obnovou databáze master, instance nesmí spustit a obnovit databázi master a uživatelské databáze společně.

Postup je následující:

  1. Ujistěte se, že je instance SQL Serveru zastavená.

  2. Proveďte obnovení ve dvou fázích.

    1. Obnovte systémové databáze a uživatelské databáze, které by se měly obnovit současně (tj. uživatelské databáze v jednoduchém modelu obnovení) prostřednictvím kopírování souborů nebo připojení svazků prostřednictvím VSS.

      • Pokud uživatelské databáze, které se mají vrátit dál, nejsou na stejném svazku jako systémové databáze, pak by se tento svazek neměl v tuto chvíli vrátit zpět. Tento scénář vyžaduje plánování před zálohováním.

      • Pokud jsou uživatelské databáze na stejném svazku jako systémové databáze, musí být uživatelské databáze před SQL Serverem skryté.

    2. Spusťte instanci SQL Serveru pomocí parametru -f . (Při použití -f možnosti spuštění je možné obnovit pouze master databázi.)

      1. Vydat ALTER DATABASE <database> SET OFFLINE (nebo odpojte databázi) pro každou databázi, která má být posunuta vpřed.

      2. Zastavte instanci SQL Serveru.

      3. Spusťte instanci SQL Serveru (soubory pro uživatelské databáze, které se mají vrátit dál, nejsou pro SQL Server viditelné).

Pomocí služby VSS obnovte uživatelské databáze WITH NORECOVERY, jak je popsáno v úplném obnovení s dalšími průběžnými obnoveními.

Dokument metadat autora: Příklad

Databáze s názvem DB1 na instanci SQL Serveru Instance1 na počítači Server1 obsahuje následující soubory databáze/protokolu:

  • Databázový soubor s názvem "primary" uložený na adrese c:\db\DB1.mdf
  • Databázový soubor s názvem "sekundární" uložený na adrese c:\db\DB1.ndf
  • Soubor protokolu databáze s názvem "log" uložený na adrese c:\db\DB1.ldf
  • Fulltextový katalog s názvem "foo" uložený v adresáři c:\db\ftdata\foo
  • Fulltextový katalog s názvem "bar" uložený v adresáři c:\db\ftdata\bar

Následuje metadata zapisovače databáze:

Komponenta filegroup na úrovni databáze

Primární soubor databáze:

ComponentType: VSS_CT_FILEGROUP
LogicalPath: "Server1\Instance1"
ComponentName: "DB1"
Caption: NULL
pbIcon: NULL
cbIcon: 0
bRestoreMetadata: FALSE
NotifyOnBackupComplete: TRUE
Selectable: TRUE
SelectableForRestore: TRUE
ComponentFlags: VSS_CF_APP_ROLLBACK_RECOVERY

Sekundární databázový soubor:

LogicalPath: "Server1\Instance1"
GroupName: "DB1"
Path: "c:\db"
FileSpec: "DB1.mdf"
Recursive: FALSE
AlternatePath: NULL
BackupTypeMask: VSS_FSBT_ALL_BACKUP_REQUIRED | VSS_FSBT_ALL_SNAPSHOT_REQUIRED
Filegroup file
LogicalPath: "Server1\Instance1"
GroupName: "DB1"
Path: "c:\db"
FileSpec: "DB1.ndf"
Recursive: FALSE
AlternatePath: NULL
BackupTypeMask: VSS_FSBT_ALL_BACKUP_REQUIRED | VSS_FSBT_ALL_SNAPSHOT_REQUIRED

Záznam plnotextového souboru:

LogicalPath: "Server1\Instance1"
GroupName: "DB1"
Path: "c:\db"
FileSpec: "DB1.ldf"
Recursive: FALSE
AlternatePath: NULL
BackupTypeMask: VSS_FSBT_ALL_BACKUP_REQUIRED | VSS_FSBT_ALL_SNAPSHOT_REQUIRED

Fulltextový soubor foo:

LogicalPath: "Server1\Instance1"
GroupName: "DB1"
Path: "c:\db\ftdata\foo"
FileSpec: "*"
Recursive: TRUE
AlternatePath: NULL
BackupTypeMask: VSS_FSBT_ALL_BACKUP_REQUIRED | VSS_FSBT_ALL_SNAPSHOT_REQUIRED

Fulltextový panel souborů:

LogicalPath: "Server1\Instance1"
GroupName: "DB1"
Path: "c:\db\ftdata\bar"
FileSpec: "*"
Recursive: TRUE
AlternatePath: NULL
BackupTypeMask: VSS_FSBT_ALL_BACKUP_REQUIRED | VSS_FSBT_ALL_SNAPSHOT_REQUIRED

Pokud je instance serveru výchozí instancí počítače, logická cesta se stane jednou částí: Server1.

Zvláštní případy

Tato část popisuje některé zvláštní případy, ke kterým došlo během operací zálohování a obnovení založených na zapisovači SQL.

Automatické zavírání databází

U záloh, které nejsou založené na komponentách, je automatické uzavření databází provedeno při kontrole na roztržené podmínky, ale při operacích zálohování nejsou automaticky uzavřené databáze explicitně uzavřeny.

Očekávaným scénářem je, že existuje mnoho uzavřených databází a chcete minimalizovat náklady na snímek. Databáze s automatickým uzavíráním se obvykle používají v konfiguracích s omezenými prostředky, kde jsou zdroje vzácné.

Seznam souborů

Seznam souborů pro každou databázi se určuje během kroku výčtu před událostí Připravit na zálohování. Pokud se seznam databázových souborů změní mezi výčtem a zablokováním, může být databáze roztrhaná, pokud aplikace znovu nekontroluje seznam souborů. I když je tento scénář nepravděpodobné, je to něco, o čem dodavatelé potřebují vědět.

Zastavené instance

Pokud instance SQL Serveru není spuštěna v době, kdy dojde ke kroku výčtu, není možné vybrat žádnou z databází pro tyto instance.

Pokud se instance zastaví v intervalu mezi výčtem a událostí Prepare for Backup, budou všechny databáze v zastavené instanci ignorovány.

Systémové a uživatelské databáze

Systémové databáze v SYSTÉMU SQL Server zahrnují master, modela msdb databáze, které jsou dodávány a nainstalovány jako součást SQL Serveru. Tato část popisuje, jak se tyto databáze zpracovávají v procesu zálohování snímků VSS.

master Databázi lze obnovit pouze zastavením instance, nahrazením databázových souborů (provedenou zálohovací aplikací) a restartováním instance. Není možné přecházet dopředu.

Zapisovač SQL podporuje obnovení obou modelmsdb databází online bez vypnutí instance.

Související obsah

  • Last updated on