SQL Server-säkerhetskopieringsprogram – Volume Shadow Copy Service (VSS) och SQL Writer

gäller för:SQL Server – endast Windows

SQL Server har stöd för Volume Shadow Copy Service (VSS) genom att tillhandahålla en skrivare (SQL-skrivaren) så att ett program för säkerhetskopiering från tredje part kan använda VSS-ramverket för att säkerhetskopiera databasfiler. I det här dokumentet beskrivs SQL-skrivarkomponenten och dess roll i processen för att skapa och återställa VSS-ögonblicksbilder för SQL Server-databaser. Den innehåller också information om hur du konfigurerar och använder SQL-skrivaren för att arbeta med säkerhetskopieringsprogram i VSS-ramverket.

Infrastruktur för VSS

VSS tillhandahåller systeminfrastrukturen för att köra VSS-program på Windows-system. Vss är till stor del transparent för både användare och utvecklare:

• Samordnar aktiviteter för leverantörer, författare och beställare i skapandet och användningen av skuggkopior.
• Tillhandahåller standardsystemleverantören.
• Implementerar de lågnivådrivrutiner som krävs för att alla leverantörer ska fungera.

VSS-tjänsten startar på begäran, därför måste den här tjänsten vara aktiverad för att VSS-åtgärder ska lyckas.

VSS-komponenter

VSS samordnar följande samarbetskomponenters verksamhet:

• Leverantörer äger skuggkopieringsdata och instansierar skuggkopiorna.

• Författare är program som ändrar data och deltar i synkroniseringsprocessen för skuggkopior.

• Beställare initierar skapandet och förstörelsen av skuggkopior. Designen fokuserar på scenariot där beställaren är ett säkerhetskopieringsprogram.

VSS tillhandahåller samordning mellan dessa parter:

Det här diagrammet visar alla komponenter som deltar i en typisk VSS-ögonblicksbildsaktivitet. I ett sådant scenario fungerar SQL Server (inklusive SQL-skrivaren) som skrivare i en av skrivrutorna. Andra sådana skrivare kan vara Exchange Server osv.

• Virtuellt enhetsgränssnitt: SQL Server tillhandahåller ett programprogramprogramgränssnitt som kallas VDI (Virtual Device Interface), som hjälper oberoende programvaruleverantörer att integrera SQL Server i sina produkter genom att ge stöd för säkerhetskopierings- och återställningsåtgärder. API:erna är utformade för att ge maximal tillförlitlighet och prestanda samt stöder det fullständiga utbudet av säkerhetskopierings- och återställningsfunktioner i SQL Server, inklusive både het- och ögonblickskopieringsmöjligheter. Mer information finns i SQL Server 2005 Virtual Backup Device Interface Specification (Gränssnittsspecifikation för virtuell säkerhetskopiering för SQL Server 2005).

• Beställare: En process (antingen automatiserad eller med ett grafiskt användargränssnitt) som begär att en eller flera ögonblicksbildssamlingar ska tas från en eller flera ursprungliga volymer. I den här artikeln används en begäran också för att beteckna en säkerhetskopieringsapplikation som genererar en ögonblicksbild av SQL Server-databaser.

För mer information, se tjänsten för skuggkopiering av volymer.

SQL-skrivare

SQL-skrivaren är en VSS-skrivare som tillhandahålls av SQL Server-instansen. Den hanterar VSS-interaktionen med SQL Server. SQL-skrivaren levereras med SQL Server som en fristående tjänst och installeras som en del av SQL Server-installationen.

Sql-skrivarens roll i en vss-säkerhetskopieringsåtgärd för ögonblicksbilder:

Konfigurera SQL-skrivaren

SQL-skrivartjänsten installeras i systemet som en del av SQL Server-installationen och konfigureras att starta automatiskt när Windows startar.

SQL-skrivartjänstkonto

Under installationen installeras SQL-skrivarkontot för att använda det lokala systemkontot. Eftersom SQL-skrivaren behöver prata med SQL Server med hjälp av exklusiva VDI-API:er måste SQL-skrivarkontot ha tillräcklig åtkomstbehörighet för både SQL Server och VSS. Att konfigurera tjänsten som ett lokalt systemkonto ger tillräcklig behörighet för att tjänsten ska kunna köras korrekt.

Återaktivera och starta SQL-skrivare

Som standard aktiveras SQL-skrivartjänsten och startas automatiskt. Om den här konfigurationen har ändrats måste följande steg vidtas för att återgå till standardinställningarna:

SQL-skrivartjänsten kan aktiveras genom att markera den här tjänsten som Automatisk. Om du vill öppna tjänsterna via kontrollpanelen väljer du Start, Kontrollpanelen, dubbelklickar på Administrationsverktyg och dubbelklickar sedan på Tjänster. Dubbelklicka på SQL-skrivartjänsten i fönstret Tjänster och ändra egenskapen Starttyp till Automatisk.

Tjänsten bör sedan startas genom att välja knappen Start under egenskapen Tjänststatus på den tjänstegenskapsskärm som nämnts tidigare.

Funktioner som stöds av SQL-skrivaren

• Fulltext: SQL-skrivaren rapporterar katalogcontainrar i fulltext med rekursiva filspecifikationer under databaskomponenterna i författarens metadatadokument. De ingår automatiskt i säkerhetskopieringen när databaskomponenten väljs.

• Differentiell säkerhetskopiering och återställning: SQL-skrivaren stöder differentiell säkerhetskopiering och återställning via två VSS-differentiella mekanismer:

  • Partiell fil: SQL-skrivaren använder VSS Partial File-mekanismen för att rapportera ändrade byteintervall i sina databasfiler.

  • Skillnad i fil efter senaste ändringstid: SQL-skrivaren använder VSS Differenced File by Last Modify Time-mekanismen för rapportering av ändrade filer i fulltextkataloger.

• Återställ med flytt: SQL-skrivaren stöder VSS:s nya mål-specifikation under återställning. Med specifikationen Nytt mål kan en databas/loggfil eller en fulltextkatalogcontainer flyttas som en del av återställningsåtgärden.

• Databasbyte: En beställare kan behöva återställa en SQL Server-databas med ett nytt namn, särskilt om databasen ska återställas sida vid sida med den ursprungliga databasen. SQL-skrivaren har stöd för att byta namn på en databas under återställningsåtgärden, så länge databasen finns kvar i den ursprungliga SQL-instansen.

• Kopieringssäkerhetskopia: Ibland är det nödvändigt att göra en säkerhetskopia avsedd för ett särskilt ändamål, till exempel när du behöver göra en kopia av en databas i testsyfte. Den här säkerhetskopieringen bör inte påverka de övergripande säkerhetskopierings- och återställningsprocedurerna för databasen. Med alternativet COPY_ONLY anges att säkerhetskopieringen görs out-of-band och ska inte påverka den normala sekvensen av säkerhetskopior. SQL-skrivaren stöder typen kopieringsbara säkerhetskopior med SQL Server-instanser.

• Återskapa databasögonblicksbild automatiskt: Vanligtvis är en ögonblicksbild av en SQL Server-databas som hämtas med hjälp av VSS-ramverket i ett icke-återställt tillstånd. Data i ögonblicksbilden kan inte nås på ett säkert sätt innan de går igenom återställningsfasen för att återställa transaktioner under flygning och placera databasen i ett konsekvent tillstånd. Det är möjligt för ett VSS-säkerhetskopieringsprogram att begära automatisk återställning av ögonblicksbilderna som en del av processen för att skapa ögonblicksbilder.

Dessa nya funktioner och deras användning beskrivs mer detaljerat i information om alternativ för säkerhetskopiering och återställning i den här artikeln.

Vad stöds inte

• Loggsäkerhetskopior stöds inte av SQL-skrivaren.
• Säkerhetskopiering av fil- och filgrupper stöds inte.
• Sidåterställning stöds inte.
• Databasögonblicksbilder stöds inte och ignoreras när du skapar både komponent- och icke-komponent-VSS-ögonblicksbilder.
• Autostäng databaser, eller databaser med avstängning aktiverat.
• Linux tillhandahåller inget VSS-ramverk och därför är SQL-skrivaren inte tillgänglig i Linux.

I följande tabell visas de typer av säkerhetskopieringar av ögonblicksbilder som stöds av SQL-skrivaren/SQL Server som arbetar med VSS-ramverket för alla utgåvor av SQL Server i Windows.

Säkerhetskopieringsåtgärder

SQL Server (med SQL-skrivaren) stöder följande lägen för VSS-baserade säkerhetskopieringsåtgärder:

• Icke-komponentbaserad
• Komponentbaserad

Versionsstöd

SQL-skrivaren levereras som en del av SQL Server och stöder endast SQL Server-instanser. SQL-skrivaren räknar även upp SQL Server Express-instanser, inklusive användarinstanser som startas av SQL Server Express Edition.

Icke-komponentbaserade säkerhetskopieringsåtgärder

Icke-komponentbaserade säkerhetskopior väljer implicit databaser med hjälp av listan över volymer i ögonblicksbilduppsättningen. SQL-skrivaren söker efter sönderrivna databaser, vilket skapar ett fel om det hittas. En sönderriven databas är en databas där en delmängd av filer väljs av listan över volymer.

I den icke-komponentbaserade modellen stöds endast databaser med den enkla återställningsmodellen. Framåtrullning efter en återställning stöds inte.

Komponentbaserade säkerhetskopieringsåtgärder

Komponentbaserade säkerhetskopior rekommenderas med SQL-skrivaren, eftersom programmet (VSS-säkerhetskopieringsprogrammet) uttryckligen väljer databaserna från de metadata som returneras från SQL-skrivaren. Ögonblicksbilduppsättningen bör innehålla alla volymer som krävs för att säkerhetskopiera dessa databaser. VSS-infrastrukturen lägger inte automatiskt till de volymer som krävs för den valda uppsättningen databaser. Alla underliggande volymer ska ingå i volymöversiktsuppsättningen. Det är säkerhetskopieringsprogrammets ansvar att se till att alla säkerhetskopieringsvolymer ingår i ögonblicksbilduppsättningen. SQL-skrivaren identifierar sönderrivna databaser (med säkerhetskopieringsvolymer utanför ögonblicksbildsuppsättningen) och misslyckas med säkerhetskopieringen.

Resten av det här avsnittet förutsätter att komponentbaserade säkerhetskopior används som en del av vss-processen för att skapa ögonblicksbilder för SQL Server.

Process för att skapa ögonblicksbilder

VSS-ramverket samordnar aktiviteterna för en klient (ett säkerhetskopieringsprogram) och SQL Writer när SQL Server-ögonblicksbilder skapas. För att aktivera den här samordningen definierar VSS-ramverket gränssnitt för beställare och skrivare. Dessa gränssnitt bör implementeras av deltagande begärarande program och författare. SQL-skrivaren implementerar nödvändiga skrivgränssnitt. Som en del av processen för att skapa ögonblicksbilder anropas SQL-skrivarens gränssnitt av VSS-ramverket. SQL-skrivaren interagerar med SQL Server-instanser i systemet för att underlätta skapandet av ögonblicksbilder.

VSS-ramverket definierar en uppsättning API:er för användning av ett program för begärande/säkerhetskopiering. En utvecklare av säkerhetskopieringsprogram måste följa dessa API-anropsmönster för att fungera med processen för att skapa ögonblicksbilder i VSS-ramverket. I nästa avsnitt beskrivs processen för att skapa ögonblicksbilder ur SQL-skrivarsynpunkt. De beskriver också några av de interna interaktionerna mellan begärande-, VSS-ramverket, SQL-skrivaren och SQL Server-instanserna.

Mer information om de här stegen och mer information om VSS-ramverksgränssnitten finns i VSS (Volume Shadow Copy Service).

Arbetsflöde för att skapa ögonblicksbilder

Följande bild visar dataflödesdiagrammet under en komponentbaserad åtgärd för skapande/säkerhetskopiering av ögonblicksbilder.

För att bättre förstå de grundläggande uppgifter som ingår i att utföra en säkerhetskopia är det användbart att dela upp den här översikten i följande faser:

• Initiering av säkerhetskopiering
• Fas för säkerhetskopieringsidentifiering
• Uppgifter för föråterställning
• Faktisk säkerhetskopiering av filer
• Avslutning av säkerhetskopia

Säkerhetskopieringens start

Under den här fasen av säkerhetskopieringen binder beställaren (säkerhetskopieringsprogrammet) till ögonblicksbildsgränssnittet IvssBackupComponentsoch initierar det inför säkerhetskopieringen. Den anropar även VSS-API IVssGatherWriterMetadata :et för att be VSS-ramverket att samla in metadata från alla författare.

VSS-ramverket anropar var och en av de registrerade författarna, inklusive SQL-skrivaren, för skrivarmetadata med hjälp av OnIdentify händelsen. SQL-skrivaren frågar SQL Server-instanserna efter säkerhetskopieringsmetadata för varje databas och skapar Skrivarmetadata-dokumentet. Den här fasen kallas även metadatauppräkning.

Dokumentet med skrivarmetadata är ett dokument som innehåller information som skickas från skrivaren till beställaren (säkerhetskopieringsprogram). Dokumentet med skrivmetadata innehåller följande information:

• Program-ID och eget namn
• Där filer och komponenter finns
• Vilka filer som måste inkluderas och undantas i en säkerhetskopia
• Vilka alternativ ska användas vid återställningstid

Detta skickas tillbaka till beställaren via VSS-ramverket.

Upptäckning av säkerhetskopior

I den här fasen undersöker en beställare dokumentet med skrivarmetadata och skapar och fyller ett dokument för säkerhetskopior med varje komponent som måste säkerhetskopieras. Den anger också de säkerhetskopieringsalternativ och parametrar som behövs som en del av det här dokumentet. För SQL-skrivaren är varje databasinstans som måste säkerhetskopieras en separat komponent.

Dokument om säkerhetskopieringskomponenter

Det här är ett XML-dokument som skapats av en användare (med hjälp av IVssBackupComponents gränssnittet) under konfigurationen av en återställnings- eller säkerhetskopieringsåtgärd. Dokumentet med säkerhetskopieringskomponenter innehåller en lista över de komponenter som uttryckligen ingår, från en eller flera skrivare, som deltar i en säkerhetskopierings- eller återställningsåtgärd. Den innehåller inte implicit inkluderad komponentinformation. Ett dokument med skrivarmetadata innehåller däremot endast skrivarkomponenter som kan ingå i en säkerhetskopia. Strukturell information om ett dokument för säkerhetskopior beskrivs i VSS API-dokumentationen.

Uppgifter före säkerhetskopiering

Förhandsåterställningsuppgifter under VSS fokuserar på att skapa en skuggkopia av volymerna som innehåller data för säkerhetskopiering. Säkerhetskopieringsprogrammet sparar data från skuggkopian, inte den faktiska volymen.

Beställare väntar vanligtvis på skrivare under förberedelserna för säkerhetskopiering och medan skuggkopian skapas. Om SQL-skrivaren deltar i säkerhetskopieringen måste den konfigurera sina filer och även sig själv för att vara redo för säkerhetskopiering och skuggkopiering.

Förbereda för säkerhetskopiering

Beställaren måste ange vilken typ av säkerhetskopieringsåtgärd som ska utföras (IVssBackupComponents::SetBackupState) och meddelar sedan skrivare via VSS för att förbereda för en säkerhetskopieringsåtgärd med hjälp av IVssBackupComponents::PrepareForBackup.

SQL-skrivaren ges åtkomst till dokumentet för säkerhetskopieringskomponenten, som beskriver vilka databaser som behöver säkerhetskopieras. Alla säkerhetskopieringsvolymer ska ingå i volymens ögonblicksbilduppsättning. SQL-skrivaren identifierar sönderrivna databaser (med säkerhetskopieringsvolymer utanför ögonblicksbildsuppsättningen) och misslyckas med säkerhetskopieringen under PostSnapshot-händelsen.

Faktisk säkerhetskopiering av filer

I den här fasen kan beställaren flytta data till ett säkerhetskopieringsmedium om det behövs. Interaktioner i det här steget sker mellan beställaren och VSS-ramverket. SQL-skrivaren är inte inblandad.

1. Få författarstatus Returnerar status för författare. Beställaren kan behöva hantera eventuella fel här.
2. Utför säkerhetskopieringen.

Beställaren kan flytta data för att säkerhetskopiera media om det behövs just nu.

Säkerhetskopieringen har slutförts

Den här händelsen anger att säkerhetskopieringen har slutförts.

Det här är också den tidpunkt då SQL-skribenten kan utföra säkerhetskopieringen som en differentialbas, om den aktuella säkerhetskopian är en fullständig säkerhetskopia av databasen (och inte en säkerhetskopia endast för kopiering).

Spara författarmetadata

Beställaren bör spara dokumentet för säkerhetskopieringskomponenten och varje komponents säkerhetskopieringsmetadata tillsammans med de data som backas upp från ögonblicksbilden. Dessa skrivarmetadata behövs av SQL-skrivaren/SQL Server för återställningsåtgärder.

Avbrott av säkerhetskopia

Beställaren avslutar skuggkopian genom att släppa gränssnittet IVssBackupComponents eller genom att anropa IVssBackupComponents::DeleteSnapshots.

SQL-skrivarmetadatadokument

Det här är ett XML-dokument som skapats av en skrivare (SQL-skrivaren i det här fallet) med hjälp av IVssCreateWriterMetadata gränssnittet och som innehåller information om skrivarens tillstånd och komponenter. Den strukturella informationen om ett dokument med skrivarmetadata beskrivs i VSS API-dokumentationen. Här följer några av detaljerna i dokumentet med SQL-skrivarmetadata.

• Information om författaridentifiering

  • Författarens namn – L"SqlServerWriter"
  • Skrivarklass-ID – 0xa65faa63, 0x5ea8, 0x4ebc, 0x9d, 0xbd, 0xa0, 0xc4, 0xdb, 0x26, 0x91, 0x2a
  • Skrivarinstans-ID – L"SQL Server:SQLWriter"
  • VSSUsageType – VSS_UT_USERDATA
  • VSSSourceType – VSS_ST_TRANSACTEDDB

• Författarnivåinformation: VSS_APP_BACK_END

• Specifikation av återställningsmetod – VSS_RME_RESTORE_IF_CAN_REPLACE.

• Säkerhetskopieringsschema som stöds (IVssCreateWriterMetadata::SetBackupSchema API)

  • VSS_BS_DIFFERENTIAL – differentiell säkerhetskopiering
  • VSS_BS_TIMESTAMPED – tidsstämpelbaserad – för katalogfiler med fulltext.
  • VSS_BS_LAST_MODIFY – Differentiell säkerhetskopiering baserat på senaste ändringstid,
  • VSS_BS_WRITER_SUPPORTS_NEW_TARGET – stöder alternativ för ny målplats.
  • VSS_BS_WRITER_SUPPORTS_RESTORE_WITH_MOVE – stöder återställning "med flytt"
  • VSS_BS_COPY – stöder säkerhetskopieringsalternativet "endast kopiering".

• Information på komponentnivå (innehåller information på komponentnivå som tillhandahålls av SQL-skrivaren)

  • Typ – VSS_CT_FILEGROUP
  • Namn – namnet på komponenten (databasnamn)
  • Logisk sökväg – för serverinstansen (i form av "server\instance-name" för namngivna instanser och "server" för standardinstansen.)
  • Komponentflaggor
  • VSS_CF_APP_ROLLBACK_RECOVERY – anger att SQL Server-ögonblicksbilder alltid kräver en "återställningsfas" för att göra filerna konsekventa och användbara för scenarier som inte är säkerhetskopierade (dvs. appåterställning).
  • Valbar – Ja
  • Valbar för Återställning – Sant
  • Återställningsmetoder som stöds – VSS_RME_RESTORE_IF_CAN_REPLACE

Det enda tillägget för komponentuppsättningsstrukturen i SQL Server är introduktionen av fulltextkataloger. Fulltextkataloger är containerkataloger, som inte kan uttryckas som VSS-databasen eller loggfilerna, eftersom VSS-databasen och loggfilerna inte har rekursiv specifikation. Därför använder SQL-skrivaren en VSS-filgruppskomponent (VSS_CT_FILEGROUP) för att representera komponent- och filgruppsfilerna på databasnivå för att representera databas-, logg- och fulltextkatalogfilerna.

Ett exempel på metadatadokument för författare finns i slutet av det här dokumentet.

Initiera ögonblicksbild

Beställaren initierar ögonblicksbildsprocessen genom att anropa VSS Framework-gränssnittet DoSnapshotSet.

Skapa ögonblicksbild

Den här fasen omfattar en serie interaktioner mellan VSS-ramverket och SQL-skrivaren.

1. Förbered för ögonblicksbild. SQL-skrivaren anropar SQL Server för att förbereda skapandet av ögonblicksbilder.

2. Lås. SQL-skrivaren anropar SQL Server för att låsa alla databas-I/O för var och en av databaserna som säkerhetskopieras i ögonblicksbilden. När fryshändelsen återgår till VSS-ramverket skapar VSS ögonblicksbilden.

3. Tina. Vid denna händelse anropar SQL-skrivaren SQL Server-instanserna för att tina upp eller återuppta normala I/O-åtgärder.

Det tar mindre än 60 sekunder att skapa ögonblicksbilder för att förhindra blockering av alla skrivningar till databasen.

Efter ögonblicksbild

Om automatisk återställning behövs för ögonblicksbilden gör SQL-skrivaren automatisk återställning för varje databas som har valts för att finnas i ögonblicksbilden. En detaljerad förklaring finns i Automatisk återställning av ögonblicksbilder.

Återställningsprocess

I det här avsnittet beskrivs arbetsflödet för återställningsåtgärden och olika steg.

Arbetsflöde för återställningsprocess

Följande bild visar dataflödesdiagrammet under en VSS-återställningsåtgärd.

För att bättre förstå de grundläggande uppgifter som ingår i återställningen är det bra att dela upp den här översikten i följande avsnitt:

• Återställ initiering
• Förbereder för återställning
• Faktisk filåterställning
• Återställa rensning och avslutning

I alla VSS-komponentbaserade återställningsscenarier hanteras databasåterställning av SQL-skrivaren i två olika faser.

• Före återställning: SQL-skrivaren hanterar validering, stängning av filhandtag osv.
• Efter återställning: SQL-skrivaren kopplar databasen och utför kraschåterställning om det behövs.

Mellan dessa två faser ansvarar säkerhetskopieringsprogrammet för att flytta relevanta data under SQL.

Återställ initieringen

Under initieringsfasen för en återställning måste beställaren ha åtkomst till dokument för lagrade säkerhetskopieringskomponenter.

Dokumentet för säkerhetskopieringskomponenten som genereras under säkerhetskopieringen lagras som en del av säkerhetskopieringsdata. Säkerhetskopieringsprogrammet måste skicka tillbaka dessa data till VSS-ramverket. SQL-skrivaren får åtkomst till dessa data i början av återställningsprocessen.

Förbered för återställning

När användaren förbereder sig för en återställning, använder den det lagrade dokumentet om säkerhetskopieringskomponenter för att avgöra vad och hur som ska återställas. Beställaren väljer vilka komponenter som ska återställas och anger lämpliga återställningsalternativ efter behov.

Om ett säkerhetskopieringsprogram har för avsikt att använda differentiella säkerhetskopior eller loggsäkerhetskopior ovanpå den aktuella återställningsåtgärden (dvs. återställning med norecovery krävs), bör följande alternativ anges som en del av komponentskapandet för varje databas som återställs.

IVssBackupComponents::SetAdditionalRestores(true)

När all nödvändig information har angetts i dokumentet för säkerhetskopieringskomponenten anropar IVssBackupComponents::PreRestore beställaren för att generera en föråterställningshändelse via VSS som hanteras av författarna.

SQL-skrivaren undersöker det angivna dokumentet för säkerhetskopieringskomponenten för att identifiera lämpliga databaser och tar bort eventuella ytterligare filer som skapats sedan säkerhetskopieringstiden. Den kontrollerar även diskutrymmen och stänger alla öppna databasfilreferenser så att beställaren kan kopiera nödvändiga data under återställningsfasen. Den här fasen gör det möjligt att identifiera eventuella tidiga felvillkor innan beställaren utför den faktiska filkopieringen. SQL Server försätter även databasen i återställningstillstånd. Från och med nu kan databasen inte startas förrän återställningen har slutförts.

Återställa filer

Detta är enbart en begärandespecifik åtgärd. Det är beställarens ansvar (säkerhetskopieringsprogrammet) att kopiera de nödvändiga databasfilerna (eller kopiera relevanta dataintervall för differentiella återställningar) till lämpliga platser. SQL-skrivaren är inte inblandad i den här åtgärden.

Rensning och avslutning

När alla data har återställts till rätt platser kan ett anrop från en beställare som meddelar att återställningsåtgärden har slutförts IvssBackupComponents::PostRestore, låta SQL-skrivaren veta att åtgärder efter återställningen kan startas. SQL-skrivaren gör nu om fasen för kraschåterställning. Om återställning inte begärs (d.v.s., SetAdditionalRestores(true) inte anges av beställaren) utförs även ångringsfasen av återställningssteget under den här fasen.

Information om alternativ för säkerhetskopiering och återställning

I det här avsnittet beskrivs i detalj alla alternativ för säkerhetskopiering och återställning som stöds av SQL-skrivaren.

Requestor skapar en volymskuggakopia

SQL-skrivaren kan vara involverad i processen för att skapa volymskuggakopior (utanför kontexten för säkerhetskopiering och återställning), eftersom säkerhetskopieringsvolymerna för databasfilerna har lagts till i volymens ögonblicksbilduppsättning. I det här fallet deltar SQL-skrivaren endast i metadatauppräkningen, Freeze, Thaw, PrepareForSnapshotoch PostSnapshot samordningen (se dataflödesdiagrammet för mer information).

Fullständig säkerhetskopiering och återställning

SQL-skrivaren stöder fullständiga säkerhetskopierings- och återställningsåtgärder i både icke-komponentbaserat läge och komponentbaserat läge.

Icke-komponentbaserad säkerhetskopiering och återställning

I en icke-komponentbaserad säkerhetskopiering och återställning anger beställaren en volym eller ett mappträd som ska säkerhetskopieras och återställas. Alla data i den angivna volymen och mappen säkerhetskopieras och återställs.

Säkerhetskopiering

I en icke-komponentbaserad säkerhetskopiering väljer SQL-skrivaren implicit databaser med hjälp av listan över volymer i ögonblicksbilduppsättningen. Skrivaren söker efter sönderrivna databaser, vilket ger upphov till ett fel om det hittas. En sönderriven databas är en databas där en delmängd av filer väljs av listan över volymer. Framåtrullning (differentiella återställningar eller loggåterställningar) efter en återställning stöds inte via SQL-skrivaren.

Återställ

Beställaren återställer databaser som har säkerhetskopierats i icke-komponentbaserat läge. Sådana återställningar kan inte följas upp av en återställning med framåtrullning, till exempel loggåterställning eller differentiell återställning.

För icke-komponentbaserade återställningsåtgärder måste återställningen utföras med SQL Server-instansen offline eller så tas måldatabaserna bort/kopplas från för att säkerställa att filerna är offline. Filerna kopieras på plats och därefter bifogas databaserna. Allt detta sker utanför SQL-skrivarens omfång.

Komponentbaserad säkerhetskopiering och återställning

I en komponentbaserad säkerhetskopia väljer beställaren uttryckligen databaskomponenter (från de metadata som SQL-skrivaren returnerar till klienten) som ska säkerhetskopieras/återställas.

Säkerhetskopiering

I en komponentbaserad säkerhetskopia bör alla säkerhetskopieringsvolymer för valda databaser ingå i volymens ögonblicksbilduppsättning. Annars identifierar SQL-skrivaren sönderrivna databaser (med säkerhetskopieringsvolymer utanför ögonblicksbilduppsättningen) och misslyckas med säkerhetskopieringen. En fullständig säkerhetskopia säkerhetskopierar databasdata och alla loggfiler som krävs för att föra databasen upp till ett transaktionsmässigt konsekvent tillstånd vid återställningen.

Fullständig återställning utan framåtrullning

En fullständig återställning av databassäkerhetskopian utförs ibland utan ytterligare framåtrullning. Det kan bero på att det inte finns några metadata för att underlätta framåtrullningen eller att det i vissa fall inte behövs någon framåtrullning. Det här avsnittet beskriver dessa två situationer kortfattat.

Inga metadata/ingen vidarekoppling

Om inga skrivarmetadata (komponentbaserade säkerhetskopieringsmetadata) sparas under säkerhetskopieringen måste återställningen utföras med SQL Server-instansen offline eller så tas måldatabaserna bort/kopplas från för att säkerställa att filerna är offline. Filerna kopieras på plats och sedan bifogas databaserna. Allt detta sker utanför SQL-skrivarens omfång.

Metadata finns men ingen ytterligare vidarekoppling krävs

Beställaren återställer databaser som har säkerhetskopierats i komponentbaserat läge men ingen framåtrullning begärs. I det här fallet utför SQL Server kraschåterställning på databasen som en del av återställningen.

Fullständig återställning med ytterligare rullning framåt

Beställaren kan utfärda en återställning som anger alternativet SetAdditionalRestores(true) . Det här alternativet anger att begäraren kommer att följa upp med fler roll-forward-återställningar (till exempel logg-återställning, differential-återställning osv.). Detta instruerar SQL Server att inte utföra återställningssteget i slutet av återställningsåtgärden.

Detta är endast möjligt om skrivarmetadata sparades under säkerhetskopieringen och är tillgängligt för SQL-skrivaren vid tidpunkten för återställningen. SQL Server-tjänsten måste köras innan beställaren dirigerar VSS för att utföra återställningsaktiviteten.

SQL-skrivaren förväntar sig följande sekvens:

1. Förberedelse för att återställa varje databas. Den här aktiviteten innebär att alla filhandtag stängs så att databasfiler kan kopieras/monteras av den förfrågande applikationen.

2. Filer kopieras/monteras av programbegärandeprogrammet.

3. Slutför återställningen (med NORECOVERY). Databaserna är online, men i ett återställningstillstånd .

Konventionella SQL Server-säkerhetskopior, differentiella eller loggar kan sedan användas för att distribuera databasen via VDI eller Transact-SQL, eller genom att tillämpa differentiell återställning med vss-ramverket.

Stöd för fulltext

SQL-skrivaren rapporterar katalogcontainrar med fulltext med rekursiva filspecifikationer under databaskomponenterna i dokumentet med skrivarmetadata. De ingår automatiskt i säkerhetskopieringen när databaskomponenten väljs.

Differentiell säkerhetskopiering och återställning

En differentiell säkerhetskopieringsåtgärd säkerhetskopierar endast de data som har ändrats sedan den senaste fullständiga bassäkerhetskopian. En differentiell säkerhetskopia innehåller endast de delar av databasfilerna som har ändrats. För att kunna göra en sådan säkerhetskopia behöver beställaren (säkerhetskopieringsprogrammet) information om platsen för ändringarna i databasfilerna, så att lämpliga delar av filerna kan säkerhetskopieras. Under en differentiell säkerhetskopieringsåtgärd tillhandahåller SQL-skrivaren den här informationen i det format som anges av vss partiell filinformation. Den här informationen kan endast användas för att säkerhetskopiera den ändrade delen av databasfilerna.

Säkerhetskopiering

Beställaren kan utfärda en differentiell säkerhetskopia genom att ange DIFFERENTIAL alternativet VSS_BT_DIFFERENTIAL i dokumentet IVssBackupComponents::SetBackupStateför säkerhetskopieringskomponenten när en säkerhetskopiering med VSS initieras. SQL-skrivaren skickar den partiella filinformationen (som returneras till den av SQL Server) till VSS. Beställaren kan hämta den här filinformationen genom att anropa VSS-API:ets IVssComponent::GetPartialFile. Med den här partiella filinformationen kan beställaren endast välja ändrade byteintervall för att säkerhetskopiera för databasfilerna.

Under fasen för säkerhetskopieringsaktiviteter ser SQL-skrivaren till att det finns en enda differentiell bas för varje vald databas.

PostSnapshot Under händelsen hämtar SQL-skrivaren den partiella filinformationen från SQL Server och lägger till den i dokumentet för säkerhetskopiering av komponenten med hjälp av IVssComponent::AddPartialFile anrop.

Format för partiell filinformation

För varje databas som säkerhetskopieras under en differentiell säkerhetskopia lagrar SQL-skrivaren den partiella filinformationen för varje databasfil. Den här informationen används av beställaren eller säkerhetskopieringsprogrammet för att endast kopiera relevanta delar av filen till säkerhetskopieringsmediet under den faktiska säkerhetskopieringen av filerna.

Mer information om formatet för den här partiella filinformationen finns i Volume Shadow Copy Service (VSS).

En beställare kan fastställa dessa filer genom att anropa IVssComponent::GetPartialFileCount och IVssComponent::GetPartialFile. IVssComponent::GetPartialFile returnerar en sökväg och ett filnamn som pekar på filen och en intervallsträng som anger vad som behöver säkerhetskopieras i filen.

Mer information om hämtning av partiell filinformation finns i VSS-dokumentationen.

Säkerhetskopiera filer

Under den här fasen bör säkerhetskopieringsprogrammet titta på skrivarmetadata som lagras i dokumentet för säkerhetskopieringskomponenten och endast säkerhetskopiera relevanta delar av filerna. (För katalogfiler i fulltext bör den här säkerhetskopian göras baserat på filtidsstämplarna. Detta beskrivs senare i den här artikeln).

En differentiell säkerhetskopiering relaterar alltid till den senaste bassäkerhetskopian som finns för databasen. Vid återställningstillfället identifierar SQL Server felmatchade bas- och differentiella säkerhetskopior. Därför är det säkerhetskopieringsprogrammets eller systemadministratörens ansvar att se till att differentiell är relativ till den förväntade fullständiga säkerhetskopieringen. Om någon out-of-band-procedur har gjort en annan fullständig säkerhetskopia kanske säkerhetskopieringsprogrammet inte kan återställa den differentiella säkerhetskopian, eftersom det inte äger den grundläggande säkerhetskopian.

Om byteintervallsinformationen (partiell filinformation) för närvarande är för stor (överstiger 64 kB i buffertstorlek) genererar SQL Server ett fel som instruerar användaren att utföra en fullständig säkerhetskopia.

Felsökning

Filändringar som tillägg, borttagning, krympning, utvidgning, logiskt namnbyte och fysiskt namnbyte utgör intressanta fall vid felsökning av säkerhetskopior.

Filer som nyligen lagts till efter att basen har tagits

Dessa filer ingår i den partiella specifikationen eftersom varje rubrik i databasfilen måste finnas i den partiella specifikationen. Förutom sidhuvudsidan måste alla allokerade sidor inkluderas i den partiella specifikationen.

Filer som släppts efter att basen har tagits

När basen hade tagits kunde datafiler tas bort. Sådana filer ingår inte i dokumentet med skrivarmetadata under differentiell säkerhetskopiering. Dessutom är ingen partiell information associerad med den borttagna filen.

Filerna krymptes efter att basen hade tagits

Informationen samlas inte in från filerna förrän krympning av filer har inaktiverats på servern. Detta säkerställer att VSS aldrig innehåller någon partiell information som motsvarar den krympte regionen för en datafil.

Filer som har växt efter att basen togs

Om tillväxten skedde innan den partiella informationen samlades in, bör den partiella informationen ha inkluderat de allokerade sidorna i den utökade regionen. Om tillväxten ägde rum efter att den partiella informationen har samlats in innehåller den partiella informationen inte ändringar i den odlade regionen. I följande avsnitt ser du att sådana framtida ändringar återställs genom framåtloggning.

Filen har bytt namn logiskt efter att basen har tagits

En logisk omdöpning av filen påverkar inte säkerhetskopieringen eller återställningen, eftersom filens logiska namn inte refereras någonstans i författarens metadata dokument eller i säkerhetskopians komponentdokument.

Mer information finns i Dokumentet om skrivarmetadata: Ett exempel senare i den här artikeln.

Filen har fysiskt bytt namn efter att basen togs

Ett namnbyte för en fysisk databasfil börjar inte gälla förrän databasen startas om. Därför baseras databaskonfigurationsinformationen eller filsökvägsinformationen i den partiella informationsbufferten fortfarande på de gamla fysiska sökvägarna, som är de enda giltiga sökvägarna till databasfilerna i ögonblicksbilden.

Återställ

Under en differentiell återställning har säkerhetskopieringsmetadata som beställaren ger tillbaka till SQL-skrivaren informationen om säkerhetskopieringstypen. Därför behövs ingen särskild behandling från SQL-skrivaren. SQL Server räknar ut att det är en differentiell återställning på egen hand. SQL Server hanterar en sådan differentiell återställning på samma sätt som mot en intern differentiell återställning som inte utförs via VSS.

Föråterställningsfas

Under den här fasen ändrar SQL Server storlek på alla filer till lämplig storlek baserat på differentiella säkerhetskopieringens filmetadata. Om filen har vuxit, nollställer SQL Server den utökade delen. Om en ny fil måste skapas (den skapades efter att basen togs) nollställs den nya filen i SQL Server. Den stänger även alla filreferenser så att säkerhetskopieringsprogrammet kan skriva över filerna med återställd data från säkerhetskopieringsmediet.

Återställa filer

Klienten bör återställa filerna baserat på den partiella filspecifikationen. Data ska återställas till samma förskjutning/intervall för databasfilen som anges i den partiella filspecifikationen som lagras i skrivarmetadata.

Databasfilens operationer för att lägga till, ta bort, växa, krympa, logiskt byta namn samt fysiskt byta namn skapar återigen intressanta felsökningsfall vid återställning.

Om en databasfil har lagts till efter att den fullständiga basen har tagits

Sådana filer måste ha skapats i förväg av SQL Server under återställningsförberedelsefasen. De borde ha utökats till rätt storlek och nollställts. Klienten behöver bara ange data enligt partiell specifikation (den partiella specifikationen innehåller alla allokerade omfattningar).

Om en databasfil har tagits bort efter att den fullständiga basen har tagits

Den partiella information som SQL Server har angett innehåller ingen spårningsinformation för sådana fildroppar. SQL Server ansvarar för att identifiera de filer som ska tas bort genom att jämföra metadata för återställde filer med befintliga containrar och faktiskt ta bort dem. Detta görs före återställningen som ett förberedelsesteg.

Om en databasfil har vuxit sedan den fullständiga basen togs

Sådana filer måste utökas till rätt storlek av SQL Server under återställningsförberedelsefasen. Den utökade regionen måste också nollställas av SQL Server. Därför kan klienten på ett säkert sätt lagra data även i tillväxtregionen enligt delvis specifikation. Om filen har utökats efter att den delvisa informationen togs återställs ändringarna i det utökade området genom att spela upp loggen som säkerhetskopierades tillsammans med differentiell säkerhetskopiering.

Om en databasfil har krympt sedan den fullständiga basen togs

SQL Server ansvarar för att trunkera filen till den storlek som krävs enligt metadata. Detta görs före återställningen som ett förberedelsesteg.

Om en databasfil har logiskt namnändrats sedan den fullständiga säkerhetskopian togs

Detta påverkar inte återställningen eftersom det logiska namnet inte visas i dokumentet med skrivmetadata eller i dokumentet för säkerhetskopian. Ändringen av det logiska namnet återställs när klienten tillämpar ändringen på den primära databasfilen, som innehåller systemkataloginformationen.

Om en databasfil har bytt namn fysiskt sedan den fullständiga basen togs

Om namnändringen inte har trätt i kraft vid tidpunkten för differentiell säkerhetskopiering, återställer klienten fortfarande data till den gamla platsen. En databasomstart efter återställningen gör att det fysiska namnbytet börjar gälla. Om namnbytet för den fysiska filen redan hade börjat gälla vid tidpunkten för differentiell säkerhetskopiering, så säkerhetskopieras eventuella partiella data från den nya fysiska sökvägen.

Efter återställandet

Under händelserna efter återställningen utför SQL-skrivaren den normala om- och återställningsåtgärden (om SetAdditionalRestores() är inställd på False) för databasen.

Differentiell säkerhetskopiering och återställning för fulltextkataloger

SQL Server-fulltextkataloger är en del av databasresurserna som måste säkerhetskopieras eller återställas tillsammans med resten av databasfilerna. En differentiell säkerhetskopiering är tidsstämpelbaserad för fulltextkatalog. SQL Server VSS differentiell säkerhetskopiering och återställning har en enda bassäkerhetskopia. Det finns med andra ord inte olika baser för olika containrar. För säkerhetskopiering av VSS-fulltextkatalog innebär det att för alla fulltextkatalogcontainrar är differentiell säkerhetskopiering baserad på enstaka tidsstämpel, till skillnad från fallet med intern SQL Server differentiell säkerhetskopiering, där det finns en tidsstämpelbas per fulltextkatalogcontainer.

I VSS uttrycks den här tidsstämpeln som en komponentomfattande egenskap som anges under den fullständiga säkerhetskopieringen och som används under en efterföljande differentiell säkerhetskopiering.

OnIdentify

I OnIdentifyanropar IVssCreateWriterMetadata::SetBackupSchema() SQL-skrivaren för att ange värdet VSS_BS_TIMESTAMPED. Detta indikerar för säkerhetskopieringsprogrammet att SQL-skrivaren äger hanteringen av differentiella bas.

Ange grundtidsstämpel

Tidsstämpeln ställs in under en fullständig säkerhetskopia. I OnPostSnapshot()anropar IVssComponent::SetBackupStamp() skrivaren för att lagra tidsstämpeln med komponenten i säkerhetskopieringsdokumentet.

Differentiell säkerhetskopiering

Säkerhetskopieringsprogrammet hämtar den här tidsstämpeln från den fullständiga bassäkerhetskopian och gör tidsstämpeln tillgänglig för skrivaren genom att anropa IVssComponent::GetBackupStamp() för att hämta basstämpeln från den tidigare bassäkerhetskopian. Sedan gör den tillgänglig för författaren genom att anropa IVssBackupComponent::SetPreviousBackupStamp(). Skrivaren hämtar sedan stämpeln genom att anropa IVssComponent::GetPreviousBackupStamp() och översätter den till en tidsstämpel som används för IVssComponent::AddDifferencedFilesByLastModifyTime().

Säkerhetskopieringsprogrammets ansvar under differentiell säkerhetskopiering

Under en differentiell säkerhetskopiering ansvarar säkerhetskopieringsprogrammet för:

• Säkerhetskopiera alla filer (hela filen) vars senast ändrade tidsstämpel är större än tidsstämpeln som anges av den senaste ändringstiden för filen som angetts i komponenten.

• Spåra och identifiera borttagna filer.

Ansvarsområden för säkerhetskopieringsprogrammet under en differentiell återställning

Under en differentiell återställning ansvarar säkerhetskopieringsprogrammet för:

• Återställa alla filer som har säkerhetskopierats, antingen genom att skapa en ny fil om den inte redan finns eller genom att skriva över en befintlig fil om den redan finns.

• Utöka filen innan du lägger ned innehållet om den återställde filen är större än den befintliga filen.

• Trunkera filen till samma storlek som för den återställde filen om den återställde filen är mindre än den befintliga filen.

• Ta bort alla filer som ska tas bort. det vill: de filer som inte ska finnas från och med tidpunkten för differentiell säkerhetskopiering.

Kopieringsbackup

Ibland är det nödvändigt att ta en säkerhetskopia som är avsedd för ett särskilt syfte. Du kan till exempel behöva göra en kopia av en databas i testsyfte. Den här säkerhetskopieringen bör inte påverka de övergripande säkerhetskopierings- och återställningsprocedurerna för databasen. Genom att använda alternativet COPY_ONLY anges att säkerhetskopieringen görs out-of-band och ska inte påverka den normala sekvensen av säkerhetskopior. SQL-skrivaren stöder copy-only säkerhetskopieringstyp för SQL Server-instanser.

Under fasen för säkerhetskopieringsidentifiering anger SQL-skrivaren sin förmåga att utföra en sekundär säkerhetskopiering genom att ange det stödda säkerhetskopieringsschemaalternativet VSS_BS_COPY med hjälp av anropet IVssCreateWriterMetadata::SetBackupSchema. Beställaren kan ange säkerhetskopieringstypen som endast kopiering genom att ställa in VSS_BACKUP_TYPE alternativet till VSS_BT_COPY med anropet IVssBackupComponents::SetBackupState.

När en kopieringssäkerhetskopiering har valts antas det att filer på disken kopieras till ett säkerhetskopieringsmedium (av beställaren) oavsett tillståndet för varje fils säkerhetskopieringshistorik. SQL Server uppdaterar inte säkerhetskopieringshistoriken. Den här typen av säkerhetskopiering utgör inte någon bassäkerhetskopia för ytterligare differentiella säkerhetskopieringsåtgärder, och den stör inte heller historiken för tidigare differentiella säkerhetskopior.

Återställ med flytt

MED VSS kan beställaren (säkerhetskopieringsprogrammet) ange ett nytt återställningsmål med hjälp av anropet IVssComponent::SetNewTarget . I både PreRestore() och PostRestore()kontrollerar SQL-skrivaren om det finns minst ett nytt mål angivet. Det är säkerhetskopieringsprogrammets ansvar att fysiskt kopiera filerna till den nya platsen under den faktiska tiden för filåterställning/kopiering.

Säkerhetskopieringsprogrammet får bara ange nya mål för den fysiska sökvägen, men inte filspecifikationen. För en databasfil som finns på c:\data\test.mdfgår det till exempel inte att ändra det faktiska filnamnet test.mdf . Endast sökvägen c:\data kan ändras. För en fulltextkatalogcontainer som finns på c:\ftdata\foo, eftersom filspecifikationen i VSS är "*" och sökvägsspecifikationen i VSS är c:\ftdata\foo, kan hela sökvägen ändras.

Namnbyte för databas

En beställare kan behöva återställa en SQL Server-databas med ett nytt namn, särskilt om databasen ska återställas sida vid sida med den ursprungliga databasen. Det här alternativet kan anges av beställaren under återställningsåtgärden genom att ange ett anpassat återställningsalternativ som "Nytt komponentnamn" = <"Nytt namn"> med VSS-anropet IVssBackupComponents::SetRestoreOptions() (i parametern wszRestoreOptions ).

SQL-skrivaren tar hela innehållet i nytt komponentnamns värde och använder det som det nya namnet för den återställde databasen. Om inget alternativ anges återställer SQL Server databasen med sitt ursprungliga namn (komponentnamn).

Automatiskt återställda ögonblicksbilder

Vanligtvis är en ögonblicksbild av SQL Server-databasen som hämtas med hjälp av VSS-ramverket i ett icke-återställt tillstånd. Data i ögonblicksbilden kan inte nås på ett säkert sätt innan du går igenom återställningsfasen för att återställa transaktioner under flygning och placera databasen i ett konsekvent tillstånd. Eftersom ögonblicksbilden är i skrivskyddat tillstånd kan den inte återställas av den normala processen för att koppla databasen.

Det är möjligt att återskapa ögonblicksbilderna automatiskt som en del av processen för att skapa ögonblicksbilder. Som en del av skrivarmetadata dokumentet anger SQL-skrivaren komponentflaggan VSS_CF_APP_ROLLBACK_RECOVERY för att indikera att återställning måste utföras för databasen efter att en ögonblicksbild har skapats, innan databasen kan nås. När ögonblicksbilduppsättningen anges kan frågeställaren specificera att ögonblicksbilden ska vara en appåterställningsögonblicksbild (det vill säga att alla databasfiler i en ögonblicksbild är avsedda att vara i ett konsistent tillstånd för programanvändning) eller en säkerhetskopieringsögonblicksbild (en ögonblicksbild som används för att säkerhetskopiera data för att återställas senare om det sker ett systemfel).

Beställaren bör konfigurera VSS_VOLSNAP_ATTR_ROLLBACK_RECOVERY för att indikera att den här komponenten säkerhetskopieras för ett annat syfte än säkerhetskopiering. VSS korrelerar sedan SQL-skrivaren som specificerats VSS_CF_APP_ROLLBACK_RECOVERY för den valda komponenten med VSS_VOLSNAP_ATTR_ROLLBACK_RECOVERY, och fastställer att automatisk återställning pågår. VSS gör ögonblicksbilden skrivbar under en begränsad tidsperiod och lägger automatiskt till biten VSS_VOLSNAP_ATTR_AUTORECOVERY i ögonblicksbildskontexten.

I SQL Server ska automatisk återhämtning endast tillämpas på ögonblicksbilder för appåterställning, men inte för ögonblicksbilder av säkerhetskopior. För ögonblicksbilder av appåterställning initieras en automatisk återställningsprocess av SQL-skrivaren under PostSnapShotevent. Den här processen gör följande för varje uttryckligen vald (av beställaren) SQL Server-databas i ögonblicksbilduppsättningen:

• Koppla ögonblicksbilddatabasen till den ursprungliga SQL Server-instansen (det vill: den instans som den ursprungliga databasen är ansluten till).

• Återställ databasen (detta sker som en del av åtgärden "koppla").

• Minska storleken på loggfiler.

  Detta minskar mängden onödig kopiera-vid-skrivning som behöver göras av VSS-ramen, om VSS-providern är en programvaruleverantör. Att krympa loggfilerna är standardbeteendet. Detta kan inaktiveras genom att ange värdet till följande registernyckel till 1.

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

  Detta kan vara användbart i scenarier där ögonblicksbilden kan användas för att exportera data från en viss sida (vid en viss tidpunkt) från loggen för att åtgärda ett problem i onlinedatabasen.

• Koppla från databasen.

Nu finns det en konsekvent, återställd ögonblicksbild som kan bifogas för frågor.

Transaktioner med flera databaser

I äldre versioner av SQL Server kan ögonblicksbilddatabaserna ibland innehålla vissa transaktioner med flera databaser under flygning. Under återställningsprocessen kopplar SQL-skrivaren databasen till ögonblicksbilderna med alternativet 'Förmodad avbrutning'. Detta skulle rulla tillbaka alla transaktioner med flera databaser som ännu inte har bekräftats (inklusive transaktioner som är i tillståndet Förberedd för att bekräftas). Detta kan leda till vissa inkonsekvenser mellan databaser i ögonblicksbilduppsättningen.

Överväg till exempel två databaser A och B. Det finns en distribuerad transaktion mellan dessa två databaser och den här transaktionen är i Commit-tillstånd i databas A och i tillståndet Förberedd att bekräfta i databas B. Som en del av processen för automatisk återställning bekräftas denna transaktion i databas A och återställs i databas B. Detta kan leda till vissa inkonsekvenser i ögonblicksbildsgruppen.

Nyare versioner av Windows har en förbättrad Ms DTC-komponent (Microsoft Distributed Transaction Coordinator) som åtgärdar det här inkonsekvensproblemet för transaktioner som sträcker sig över databaser mellan SQL Server-instanser. Nyare versioner av SQL Server åtgärdar dessa inkonsekvenser för transaktioner som sträcker sig över databaser i en SQL Server-instans.

Säkerhetskonsekvenser för automatiskt återskapade ögonblicksbilder

För VSS-ögonblicksbilder skyddas filerna efter den automatiska återställningen med hjälp av åtkomstkontrollistor (ACL: er) för att endast tillåta åtkomst till den särskilda inbyggda grupp som SQL Server-kontot tillhör. Detta innebär att medlemmar i antingen box admin eller den särskilda gruppen kan bifoga databasen. Klienten som begär en infogning av databasfilerna från en ögonblicksbild måste antingen vara medlem i Builtin/Administrators eller ha ett SQL Server-konto.

Enkla användardatabaser för återställningsmodell

master Om databasen återställs tillsammans med användardatabaser som använder den enkla återställningsmodellen kan användardatabaserna återställas med samma teknik som master databasen: när instansen är avstängd kopierar eller monterar du bara volymerna. När SQL-instansen startas återställs allt.

Löpande vidarebefordran av användardatabaser

Om användardatabaser ska återställas och återställas framåt tillsammans med master databasåterställning, får instansen inte starta och återställa master- och användardatabaserna tillsammans.

Proceduren är följande:

1. Kontrollera att SQL Server-instansen har stoppats.

2. Utför återställningen i två faser.

   1. Återställ de systemdatabaser och användardatabaser som ska återställas samtidigt (dvs. användardatabaser i den enkla återställningsmodellen) via filkopiering eller volymmontering via VSS.

      • Om de användardatabaser som ska distribueras inte finns på samma volym som systemdatabaserna bör den volymen inte tas tillbaka just nu. Det här scenariot kräver planering före säkerhetskopieringen.

      • Om användardatabaserna finns på samma volym som systemdatabaserna måste användardatabaserna döljas från SQL Server.

   2. Starta SQL Server-instansen med hjälp av parametern -f . (När du använder startalternativet -fmaster kan endast databasen återställas.)

      1. Utfärda en ALTER DATABASE <database> SET OFFLINE (eller detatch databasen) för varje databas som ska rullas framåt.

      2. Stoppa SQL Server-instansen.

      3. Starta SQL Server-instansen (filerna för användardatabaserna som ska rullas framåt är inte synliga för SQL Server).

Använd VSS för att återställa användardatabaserna WITH NORECOVERY, enligt beskrivningen i Fullständig återställning med extra framåtrullning.

Dokument för skrivarmetadata: Ett exempel

En databas med namnet DB1, som tillhör SQL Server-instansen Instance1 på datorn Server1, innehåller följande databas-/loggfiler:

• Databasfil med namnet "primär" lagrad på c:\db\DB1.mdf
• Databasfil med namnet "sekundär" lagrad på c:\db\DB1.ndf
• Databasloggfil med namnet "log" lagrad på c:\db\DB1.ldf
• Fulltextkatalog med namnet "foo" som lagras under katalogen c:\db\ftdata\foo
• Fulltextkatalog med namnet "bar" som lagras under katalogen c:\db\ftdata\bar

Följande är databasens skrivarmetadata:

Filgruppskomponent på databasnivå

Primär databasfil:

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är databasfil:

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

Fulltextfillogg:

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

Fulltextfil 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

Fulltextfilfält:

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

Om serverinstansen är standardinstansen på datorn blir den logiska sökvägen en del: Server1.

Specialfall

I det här avsnittet beskrivs några av de specialfall som påträffas under SQL-skrivarbaserade säkerhetskopierings- och återställningsåtgärder.

Autostänga databaser

För icke-komponentbaserade säkerhetskopior görs automatisk avskärmning av databaser, vid kontroll av sönderrivna villkor, men de automatiskt slutna databaserna fryses inte uttryckligen under säkerhetskopieringsåtgärder.

Det förväntade scenariot här är att många stängda databaser kan finnas och du vill minimera kostnaden för ögonblicksbilden. Automatiskt slutna databaser används vanligtvis i lågslutskonfigurationer där resurserna är knappa.

Fillista

Listan över filer för varje databas bestäms under ett uppräkningssteg före händelsen Förbered för säkerhetskopiering. Om listan över databasfiler ändras mellan uppräkning och frysning kan databasen rivas, såvida inte programmet söker igenom listan över filer igen. Även om det här scenariot är osannolikt är det något som leverantörerna måste vara medvetna om.

Avstängda instanser

Om en instans av SQL Server inte körs när uppräkningssteget inträffar kan ingen av databaserna för dessa instanser väljas.

Om en instans stoppas i intervallet mellan uppräkning och händelsen Förbered för säkerhetskopiering ignoreras alla databaser i den stoppade instansen.

System- och användardatabaser

Systemdatabaser i SQL Server innehåller databaserna master, modeloch msdb som levereras och installeras som en del av SQL Server. I det här avsnittet beskrivs hur dessa databaser hanteras i en VSS-säkerhetskopieringsprocess för ögonblicksbilder.

Databasen master kan bara återställas genom att stoppa instansen, ersätta databasfilerna (görs av säkerhetskopieringsprogrammet) och sedan starta om instansen. Ingen framåtrullning är möjlig.

SQL-skrivaren stöder återställning av både model databaser och msdb databaser online, utan att stänga av instansen.

Relaterat innehåll

• Loggning för SQL Server VSS Writer
• Säkerhetskopiering (Transact-SQL)
• RESTORE-instruktioner (Transact-SQL)
• säkerhetskopiering och återställning av SQL Server-databaser
• Endast kopia-säkerhetskopior
• säkerhetskopieringar av transaktionsloggar (SQL Server)
• Tillämpa säkerhetskopieringar av transaktionsloggar (SQL Server)
• arkitektur och hanteringsguide för SQL Server-transaktionsloggar