Dela via

SQL Server-säkerhetskopiering till URL för Microsoft Azure Blob Storage

gäller för:SQL ServerAzure SQL Managed Instance

Den här artikeln beskriver de begrepp, krav och komponenter som krävs för att använda Microsoft Azure Blob Storage som säkerhetskopieringsmål. Säkerhetskopierings- och återställningsfunktionerna är desamma eller liknar när du använder DISK eller BAND, med några skillnader. Dessa skillnader och några kodexempel ingår i den här artikeln.

Tips/Råd

Förhandsversionen av SQL Server 2025 (17.x) introducerar säkerhetskopiering till URL med hanterad identitet. Granska Säkerhetskopiering till URL med hanterad identitet (förhandsversion) – SQL Server aktiverad via Azure Arc.

Översikt

SQL Server 2012 Service Pack 1 CU2 och SQL Server 2014 introducerade möjligheten att säkerhetskopiera till en URL som pekar på Azure Blob Storage med hjälp av välbekant T-SQL-syntax för att skriva säkerhetskopior på ett säkert sätt till Azure Storage. SQL Server 2016 (13.x) introducerade File-Snapshot Säkerhetskopior för Databasfiler i Azure och säkerhet via SAS-nycklar (signatur för delad åtkomst), ett säkert och enkelt sätt att autentisera certifikat till Azure Storage-säkerhetsprinciper.

Det är viktigt att förstå komponenterna och interaktionen mellan dem för att utföra en säkerhetskopia till eller återställa från Microsoft Azure Blob Storage.

Det första steget i den här processen är att skapa ett Azure Storage-konto i din Azure-prenumeration. Det här lagringskontot är ett administrativt konto som har fullständig administratörsbehörighet för alla containrar och objekt som skapats med lagringskontot. SQL Server kan antingen använda Azure Storage-kontonamnet och dess åtkomstnyckelvärde för att autentisera och skriva och läsa blobar till Microsoft Azure Blob Storage eller använda en signaturtoken för delad åtkomst som genererats på specifika containrar som ger den läs- och skrivbehörighet. Mer information om Azure Storage-konton finns i Om Azure Storage-konton och mer information om signaturer för delad åtkomst finns i Signaturer för delad åtkomst, del 1: Förstå SAS-modellen. SQL Server-autentiseringsuppgifterna lagrar den här autentiseringsinformationen och används under säkerhetskopierings- eller återställningsåtgärderna.

Azure Storage och S3-kompatibel lagring

SQL Server 2022 (16.x) introducerar möjligheten att skriva säkerhetskopior till S3-kompatibel objektlagring, med säkerhetskopierings- och återställningsfunktioner som konceptuellt liknar att arbeta med säkerhetskopiering till URL med hjälp av Azure Blob Storage som en typ av säkerhetskopieringsenhet. SQL Server 2022 (16.x) utökar syntaxen för säkerhetskopiera/återställ till/från URL genom att lägga till stöd för en ny S3-kontakt med hjälp av REST API:et.

Den här artikeln innehåller information om hur du använder Säkerhetskopiering till URL för Azure Blob Storage. Mer information om hur du använder Säkerhetskopiering till URL för S3-kompatibel lagring finns i SQL Server-säkerhetskopiering till URL för S3-kompatibel objektlagring.

Säkerhetskopiering till Azure Storage-blockblob jämfört med sidblob

Det finns två typer av blobar som kan lagras i Microsoft Azure Blob Storage: block- och sidblobar. För SQL Server 2016 och senare föredras blockblob.

Om lagringsnyckeln används i autentiseringsuppgifterna används sidblob. Om signaturen för delad åtkomst används används blockblob.

Säkerhetskopiering till blockblob är endast tillgängligt i SQL Server 2016 eller senare version för säkerhetskopiering till Azure Blob Storage. Säkerhetskopiera för att blockera blob i stället för sidblob om du kör SQL Server 2016 eller senare.

De främsta orsakerna är:

  • Signatur för delad åtkomst är ett säkrare sätt att auktorisera blobåtkomst jämfört med lagringsnyckel.
  • Du kan säkerhetskopiera till flera blockblobar för att få bättre prestanda för säkerhetskopiering och återställning och stöd för större säkerhetskopiering av databaser.
  • Blockblob är billigare än sidblob.
  • Kunder som behöver säkerhetskopiera till sidblobar via en proxyserver måste använda backuptourl.exe.

En säkerhetskopia av en stor databas till Azure Blob Storage omfattas av de begränsningar som anges i T-SQL-skillnader, begränsningar och kända problem i Azure SQL Managed Instance.

Om databasen är för stor:

  • Använd komprimering av säkerhetskopior eller
  • Säkerhetskopiera till flera blockblobar

Stöd för Linux, containrar och SQL Managed Instance som aktiveras av Azure Arc

Om SQL Server-instansen finns i Linux, inklusive:

  • Fristående operativsystem
  • Behållare
  • SQL Managed Instance aktiverat av Azure Arc
  • Alla andra Linux-baserade miljöer

Den enda säkerhetskopiering som stöds till URL för Azure Blob Storage är att blockera blobar med signaturen för delad åtkomst.

Microsoft Azure Blob Storage

Lagringskonto: Lagringskontot är startpunkten för alla lagringstjänster. Om du vill komma åt Microsoft Azure Blob Storage skapar du först ett Azure Storage-konto. Mer information finns i Skapa ett lagringskonto

Behållare: En container tillhandahåller en gruppering av en uppsättning blobar och kan lagra ett obegränsat antal blobar. Om du vill skriva en SQL Server-säkerhetskopia till Azure Blob Storage måste du ha minst den rotcontainer som skapats. Du kan generera en signaturtoken för delad åtkomst på en container och endast bevilja åtkomst till objekt i en specifik container.

Blob: En fil av valfri typ och storlek. Det finns två typer av blobar som kan lagras i Azure Blob Storage: block- och sidblobar. SQL Server-säkerhetskopiering kan använda antingen blobtyp beroende på vilken Transact-SQL syntax som används. Blobar kan adresseras med följande URL-format: https://< storage account.blob.core.windows.net/>< container>/<blob>. Mer information om Azure Blob Storage finns i Introduktion till Azure Blob Storage. Mer information om sid- och blockblobar finns i Förstå block- och sidblobar.
Diagram över Azure Blob Storage-konton, containrar och blobar.

Azure Snapshot: En ögonblicksbild av en Azure-blob som tagits vid en tidpunkt. Mer information finns i Skapa en ögonblicksbild av en blob. SQL Server-säkerhetskopiering stöder nu säkerhetskopiering av Azure-ögonblicksbilder av databasfiler som lagras i Azure Blob Storage. Mer information finns i File-Snapshot Backups for Database Files i Azure.

SQL Server-komponenter

URL: En URL anger en URI (Uniform Resource Identifier) till en unik säkerhetskopia. URL:en används för att ange platsen och namnet på SQL Server-säkerhetskopieringsfilen. URL:en måste peka på en faktisk blob, inte bara en container. Om bloben inte finns skapas den. Om en befintlig blob anges misslyckas SÄKERHETSKOPIERingen, såvida inte alternativet "WITH FORMAT" anges för att skriva över den befintliga säkerhetskopieringsfilen i bloben.

Här är ett EXEMPEL-URL-värde: https://ACCOUNTNAME.blob.core.windows.net/<CONTAINER>/FILENAME.bak.

Anmärkning

Säkerhetskopiering till URL med HTTP stöds INTE.

Referens: En SQL Server-autentiseringsuppgift är ett objekt som används för att lagra autentiseringsinformation som krävs för att ansluta till en resurs utanför SQL Server. Här använder SQL Server-säkerhetskopierings- och återställningsprocesser autentiseringsuppgifter för att autentisera till Azure Blob Storage och dess container- och blobobjekt. Autentiseringsuppgifterna lagrar antingen namnet på lagringskontot och lagringskontots åtkomstnyckelvärden eller container-URL och dess signaturtoken för delad åtkomst. När autentiseringsuppgifterna har skapats avgör syntaxen för BACKUP/RESTORE-uttryck typen av blob och de autentiseringsuppgifter som krävs.

Ett exempel på hur du skapar en signatur för delad åtkomst finns i Skapa ett exempel på signatur för delad åtkomst senare i den här artikeln och för att skapa en SQL Server-autentiseringsuppgift finns i Skapa exempel på autentiseringsuppgifter senare i den här artikeln.

Mer information om autentiseringsuppgifter finns i Autentiseringsuppgifter (databasmotor).

Information om andra exempel där autentiseringsuppgifter används finns i Skapa en SQL Server-agentproxy.

Stöd för oföränderlig lagring i Azure

Förhandsversionen av SQL Server 2025 (17.x) ger stöd för oföränderlig lagring i Azure, vilket skyddar mot utpressningstrojanattacker. Filer som skrivs till oföränderlig lagring kan inte ändras eller tas bort, vilket definieras av oföränderlighet.

Vanligtvis skapas SQL Server-säkerhetskopior i två steg. Först skapas säkerhetskopieringsfilen .bak med nolla och sedan uppdateras filen med data. Eftersom filändring på oföränderlig lagring inte tillåts när filen har skrivits och checkats in hoppar säkerhetskopieringsprocessen nu över det första steget för att skapa säkerhetskopieringsfilen med nollor. I stället skapas säkerhetskopieringen i ett enda steg när den skrivs till blockblobar.

Under förhandsversionen krävs spårningsflagga 3012 för att aktivera oföränderligt lagringsstöd för säkerhetskopior till URL.

Gör så här om du vill använda oföränderlig lagring med SQL Server 2025 (17.x) förhandsgranskad säkerhetskopiering till URL:

  1. Konfigurera oföränderlighet för azure-lagringscontainern.
  2. Aktivera spårningsflagga 3012 för SQL Server-instansen genom att köra följande DBCC-kommando:
    DBCC TRACEON(3012,-1).
  3. Använd BACKUP för att säkerhetskopiera databasen till Azure lagringscontainer.
    BACKP DATABASE [<Database>] TO URL = ‘<url>’ WITH FORMAT.

Säkerhet för Azure Blob Storage

Följande är säkerhetsöverväganden och krav när du säkerhetskopierar till eller återställer från Azure Blob Storage.

  • När du skapar en container för Azure Blob Storage rekommenderar vi att du anger åtkomsten till privat. Om du anger åtkomst till privat begränsas åtkomsten till användare eller konton som kan tillhandahålla nödvändig information för att autentisera till Azure-kontot.

    Viktigt!

    SQL Server kräver att antingen ett Azure-kontonamn och åtkomstnyckelautentisering eller en signatur för delad åtkomst och åtkomsttoken lagras i en SQL Server-autentiseringsuppgift. Den här informationen används för att autentisera till Azure-kontot när du utför säkerhetskopierings- eller återställningsåtgärder.

    Varning

    Azure Storage stöder inaktivering av auktorisering av delad nyckel för ett lagringskonto. Om auktorisering av delad nyckel är inaktiverad, fungerar inte säkerhetskopiering till URL för SQL Server.

  • Användarkontot som används för att utfärda kommandon för säkerhetskopiering eller ÅTERSTÄLLNING bör finnas i db_backup-operatörsdatabasrollen med Ändra eventuella behörigheter för autentiseringsuppgifter .

Begränsningar för säkerhetskopiering/återställning till Azure Blob Storage

  • Felet/symtomet du upplever beror på att SQL Server begränsar den maximala storleken för säkerhetskopiering med sidblobbar till 1 TB. Den maximala säkerhetskopieringsstorleken som stöds med blockblobar är begränsad till cirka 200 GB (50 000 block * 4 MB MAXTRANSFERSIZE). Blockblobar stöder striping för att stödja betydligt större säkerhetskopieringsstorlekar – gränsen är högst 64 URL:er, vilket resulterar i följande formel: 64 stripes * 50,000 blocks * 4MB maxtransfersize = 12.8 TB.

    Viktigt!

    Även om den maximala säkerhetskopieringsstorleken som stöds av en enda blockblob är 200 GB är det möjligt för SQL Server att skriva i mindre blockstorlekar, vilket kan leda till att SQL Server når blockgränsen på 50 000 innan hela säkerhetskopieringen överförs. Stripe-säkerhetskopior (även om de är mindre än 200 GB) för att undvika blockgränsen, särskilt när du använder differentiella eller okomprimerade säkerhetskopior.

  • Du kan utfärda instruktioner för säkerhetskopiering eller återställning med hjälp av Transact-SQL, SMO, PowerShell-cmdletar eller guiden Säkerhetskopiering eller återställning av SQL Server Management Studio.

  • Säkerhetskopiering till Azure Storage-konto stöder endast autentisering med SAS-token (Signatur för delad åtkomst) eller lagringskontonycklar. Alla andra autentiseringsmetoder, inklusive autentisering med Microsoft Entra-ID (tidigare Azure Active Directory), stöds inte.

  • Det går inte att skapa ett logiskt enhetsnamn. Därför stöds inte att lägga till URL som en säkerhetskopieringsenhet med hjälp av sp_dumpdevice eller via SQL Server Management Studio.

  • Det går inte att lägga till befintliga säkerhetskopieringsblobar. Säkerhetskopieringar till en befintlig blob kan bara skrivas över med hjälp av WITH FORMAT-alternativet. Men när du använder säkerhetskopieringar av ögonblicksbilder (med argumentet WITH FILE_SNAPSHOT ) WITH FORMAT tillåts inte argumentet att undvika att lämna överblivna filögonblicksbilder som skapades med den ursprungliga säkerhetskopieringen av filögonblicksbilden.

  • Säkerhetskopiering till flera blobar i en enda säkerhetskopieringsåtgärd stöds endast med blockblobar och med hjälp av en SAS-token (Signatur för delad åtkomst) i stället för lagringskontonyckeln för SQL-autentiseringsuppgifterna.

  • Det går inte att ange BLOCKSIZE för sidblobar.

  • Det är inte möjligt att ange MAXTRANSFERSIZE för sidblobar.

  • Ange alternativ för säkerhetskopieringsuppsättningar – RETAINDAYS och EXPIREDATE stöds inte.

  • SQL Server har en maxgräns på 259 tecken för ett enhetsnamn för säkerhetskopiering. Säkerhetskopiering till URL använder 36 tecken för de element som krävs för att ange URL:https://.blob.core.windows.net//.bak, och lämnar 223 tecken för konto-, container- och blobnamn.

  • SQL Server 2019 (15.x) och tidigare versioner har en gräns på 256 tecken för SAS-token (Signatur för delad åtkomst), vilket begränsar vilken typ av token som kan användas (t.ex. nyckeltoken för användardelegering stöds inte).

  • Om servern kommer åt Azure via en proxyserver måste du använda spårningsflagga 1819 och sedan ange WinHTTP-proxykonfigurationen via någon av följande metoder:

    • Verktyget proxycfg.exe i Windows XP eller Windows Server 2003 och tidigare.
    • Verktyget netsh.exe i Windows Vista och Windows Server 2008 eller senare.

  • Oföränderlig lagring för Azure Blob Storage stöds inte. Ange oföränderlig lagringsprincip till false.

Argument och instruktioner som stöds i Azure Blob Storage

Stöd för säkerhetskopierings-/återställningsinstruktioner i Azure Blob Storage

Uttalande om säkerhetskopiering/återställning Understödd Undantag Kommentarer
SÄKERHETSKOPIA Y BLOCKSIZE och MAXTRANSFERSIZE stöds för blockblobar. De stöds inte för sidblobar. Säkerhetskopiering till en blockblob kräver en delad åtkomstsignatur som sparats i en SQL Server-referens. Säkerhetskopiering till sidblob kräver att lagringskontonyckeln sparas i en SQL Server-referens och att WITH CREDENTIAL-argumentet måste anges.
ÅTERSTÄLLA Y Kräver att en SQL Server-autentiseringsuppgift definieras och kräver att argumentet WITH CREDENTIAL anges om SQL Server-autentiseringsuppgifterna definieras med lagringskontonyckeln som hemlighet
ÅTERSTÄLL FILELISTONLY Y Kräver att en SQL Server-autentiseringsuppgift definieras och kräver att argumentet WITH CREDENTIAL anges om SQL Server-autentiseringsuppgifterna definieras med lagringskontonyckeln som hemlighet
ÅTERSTÄLL HEADERONLY Y Kräver att en SQL Server-autentiseringsuppgift definieras och kräver att argumentet WITH CREDENTIAL anges om SQL Server-autentiseringsuppgifterna definieras med lagringskontonyckeln som hemlighet
ÅTERSTÄLL LABELONLY Y Kräver att en SQL Server-autentiseringsuppgift definieras och kräver att argumentet WITH CREDENTIAL anges om SQL Server-autentiseringsuppgifterna definieras med lagringskontonyckeln som hemlighet
ÅTERSTÄLL VERIFYONLY Y Kräver att en SQL Server-autentiseringsuppgift definieras och kräver att argumentet WITH CREDENTIAL anges om SQL Server-autentiseringsuppgifterna definieras med lagringskontonyckeln som hemlighet
ÅTERSTÄLL REWINDONLY -

För syntax och allmän information om säkerhetskopieringssatser, se BACKUP.

Syntax och allmän information om återställningsinstruktioner finns i RESTORE-instruktioner.

Stöd för säkerhetskopieringsargument i Azure Blob Storage

Argumentation Understödd Undantag Kommentarer
DATABAS Y
LOGG Y
TILL (URL) Y Till skillnad från DISK och BAND har URL inte stöd för att ange eller skapa ett logiskt namn. Det här argumentet används för att ange URL-sökvägen för säkerhetskopieringsfilen.
SPEGLA TILL Y
WITH Alternativ:
REFERENS Y MED CREDENTIAL stöds endast när du använder alternativet säkerhetskopiering till en URL för att säkerhetskopiera till Azure Blob Storage och endast om SQL Server-autentiseringsuppgifterna definieras med lagringskontonyckeln som lösenord.
filögonblicksbild Y
KRYPTERING Y WITH ENCRYPTION När argumentet har angetts ser SQL Server File-Snapshot Backup till att hela databasen var TDE-krypterad innan säkerhetskopieringen och i så fall krypterar själva fil-ögonblicksbildens säkerhetskopieringsfil med hjälp av algoritmen som angetts för TDE i databasen. Om alla data i databasen i hela databasen inte är krypterade misslyckas säkerhetskopieringen (till exempel är krypteringsprocessen ännu inte klar).
differentialväxel Y
ENDAST_KOPIERA Y
KOMPRIMERING|INGEN_KOMPRIMERING Y Stöds inte för säkerhetskopiering av filsnapshots
BESKRIVNING Y
NAMN Y
Utgångsdatum | Bevarandedagar -
NOINIT | INIT - Det går inte att lägga till blobar. Använd argumentet för WITH FORMAT att skriva över en säkerhetskopia. Men när du använder säkerhetskopieringar av ögonblicksbilder (med argumentet WITH FILE_SNAPSHOT ) WITH FORMAT tillåts inte argumentet att undvika att lämna överblivna filögonblicksbilder som skapades med den ursprungliga säkerhetskopian.
NOSKIP | HOPPA ÖVER -
NOFORMAT | FORMAT Y En säkerhetskopia som tas till en befintlig blob misslyckas om inte WITH FORMAT har angetts. Den befintliga blobben skrivs över när WITH FORMAT har angetts. Men när du använder säkerhetskopieringar av ögonblicksbilder (med argumentet WITH FILE_SNAPSHOT ) tillåts inte formatargumentet att undvika att lämna överblivna filögonblicksbilder som skapades med den ursprungliga säkerhetskopieringen av filögonblicksbilden. Men när du använder säkerhetskopieringar av ögonblicksbilder (med argumentet WITH FILE_SNAPSHOT ) WITH FORMAT tillåts inte argumentet att undvika att lämna överblivna filögonblicksbilder som skapades med den ursprungliga säkerhetskopian.
MEDIEBESKRIVNING Y
MEDIENAMN Y
BLOCKSTORLEK Y Stöds inte för sidblob. Stöd för blockblob. Rekommendera BLOCKSIZE=65536 för att optimera användningen av de 50 000 block som tillåts i en blockblob.
BUFFERCOUNT Y
MAXTRANSFERSIZE Y Stöds inte för sidblob. Stöd för blockblob. Standardvärdet är 1048576. Värdet kan vara upp till 4 MB i steg om 65536 byte.
Rekommendera MAXTRANSFERSIZE=4194304 för att optimera användningen av de 50 000 block som tillåts i en blockblob.
NO_CHECKSUM | KONTROLLSUMMA Y
STOPPA_VID_FEL | FORTSÄTT_EFTER_FEL Y
STATISTIK Y
REWIND | NOREWIND -
LASTA AV | NOUNLOAD -
NORECOVERY | STANDBY Y
NO_TRUNCATE Y

Mer information om säkerhetskopieringsargument finns i SÄKERHETSKOPIERing.

Stöd för återställningsargument i Azure Blob Storage

Argumentation Understödd Undantag Kommentarer
DATABAS Y
LOGG Y
FRÅN (URL) Y ARGUMENTET FROM URL används för att ange URL-sökvägen för säkerhetskopieringsfilen.
Med alternativ:
REFERENS Y MED CREDENTIAL stöds endast när du använder alternativet RESTORE FROM URL för att återställa från Microsoft Azure Blob Storage.
PARTIELL Y
ÅTERSTÄLLNING | NORECOVERY | STANDBY Y
LADDHISTORIK Y
FLYTTA Y
ersätt Y
STARTA OM Y
BEGRÄNSAD_ANVÄNDARE Y
FIL -
LÖSENORD Y
MEDIENAMN Y
MEDIAPASSWORD Y
BLOCKSTORLEK Y
BUFFERCOUNT -
MAXTRANSFERSIZE -
CHECKSUMMA | INGEN CHECKSUMMA Y
STOPPA_VID_FEL | FORTSÄTT_EFTER_FEL Y
FILESTREAM Y Stöds inte för säkerhetskopiering av ögonblicksbilder
STATISTIK Y
REWIND | NOREWIND -
LASTA AV | NOUNLOAD -
BEHÅLL_REPLIKERING Y
BEHÅLL_CDC Y
AKTIVERA_MÄKLARE | FEL_MÄKLARE_KONVERSATIONER | NY_MÄKLARE Y
STOPPA | STOPPAMÄRKE | STOPPAINNANMÄRKE Y

Mer information om återställningsargument finns i RESTORE-instruktioner – Argument.

Säkerhetskopiera med SSMS

Du kan säkerhetskopiera en databas till URL via säkerhetskopieringsaktiviteten i SQL Server Management Studio med hjälp av en SQL Server-autentiseringsuppgift.

Anmärkning

Om du vill skapa en säkerhetskopia av SQL Server-filer eller skriva över en befintlig medieuppsättning måste du använda Transact-SQL, PowerShell eller C# i stället för säkerhetskopieringsaktiviteten i SQL Server Management Studio.

Följande steg beskriver de ändringar som gjorts i säkerhetskopieringsdatabasaktiviteten i SQL Server Management Studio så att du kan säkerhetskopiera till Azure Storage:

  1. I Object Exploreransluter du till en instans av SQL Server Database Engine och expanderar sedan den instansen.

  2. Expandera Databaser, högerklicka på den önskade databasen, peka på Uppgifter och välj sedan Säkerhetskopiera....

  3. På sidan Allmänt i avsnittet Mål är URL-alternativet tillgängligt i listrutan Säkerhetskopiera till: . URL-alternativet används för att skapa en säkerhetskopia till Microsoft Azure Storage. Välj Lägg till och dialogrutan Välj mål för säkerhetskopiering öppnas:

    1. Azure Storage-container: Namnet på Microsoft Azure Storage-containern för lagring av säkerhetskopieringsfilerna. Välj en befintlig container i listrutan eller ange containern manuellt.

    2. Princip för delad åtkomst: Ange signaturen för delad åtkomst för en manuellt angiven container. Det här fältet är inte tillgängligt om en befintlig container har valts.

    3. Säkerhetskopieringsfil: Namnet på säkerhetskopieringsfilen.

    4. Ny container: Används för att registrera en befintlig container som du inte har en signatur för delad åtkomst för. Se Ansluta till en Microsoft Azure-prenumeration (URL för säkerhetskopiering TILL).

Anmärkning

Lägg till har stöd för flera säkerhetskopieringsfiler och lagringscontainrar för en enda medieuppsättning.

När du väljer URL som mål inaktiveras vissa alternativ på sidan Mediealternativ . Följande artiklar har mer information om dialogrutan Säkerhetskopiera databas:

Säkerhetskopiera med underhållsplan

På samma sätt som säkerhetskopieringsaktiviteten som beskrevs tidigare innehåller guiden Underhållsplan i SQL Server Management Studio URL som ett av målalternativen och andra stödobjekt som krävs för att säkerhetskopiera till Azure Storage som SQL-autentiseringsuppgifterna. För mer information, se avsnittet Definiera säkerhetskopieringsuppgifter i Guiden för att använda underhållsplanering.

Anmärkning

Om du vill skapa en randig säkerhetskopieringsuppsättning, en säkerhetskopia av SQL Server-filögonblicksbild eller en SQL-autentiseringsuppgift med hjälp av token för delad åtkomst måste du använda Transact-SQL, PowerShell eller C# i stället för säkerhetskopieringsaktiviteten i guiden Underhållsplan.

Återställa med SSMS

Uppgiften Återställ databas innehåller URL som en enhet för att återställa. Följande steg beskriver hur du använder återställningsuppgiften för att återställa från Azure Blob Storage:

  1. Högerklicka på Databaser och välj Återställ databas....

  2. På sidan Allmänt väljer du Device under avsnittet Source .

  3. Välj knappen Bläddra (...) för att öppna dialogrutan Välj säkerhetskopieringsenheter.

  4. Välj URL i listrutan Säkerhetskopieringsmediatyp: . Välj Lägg till för att öppna dialogrutan Välj en plats för säkerhetskopieringsfil .

    1. Azure Storage-container: Det fullständigt kvalificerade namnet på Den Microsoft Azure-lagringscontainer som innehåller säkerhetskopieringsfilerna. Välj en befintlig container i listrutan eller ange det fullständigt kvalificerade containernamnet manuellt.

    2. Signatur för delad åtkomst: Används för att ange signaturen för delad åtkomst för den avsedda containern.

    3. Addera: Används för att registrera en befintlig container som du inte har en signatur för delad åtkomst för. Se Ansluta till en Microsoft Azure-prenumeration (URL för säkerhetskopiering TILL).

    4. OKEJ: SQL Server ansluter till Microsoft Azure Storage med hjälp av informationen om SQL-autentiseringsuppgifter som du angav och öppnar dialogrutan Hitta säkerhetskopieringsfil i Microsoft Azure . Säkerhetskopieringsfilerna som finns i lagringscontainern visas på den här sidan. Välj den fil som du vill använda för att återställa och välj OK. Detta tar dig tillbaka till dialogrutan Välj enheter för säkerhetskopiering och om du väljer OK i den här dialogrutan går du tillbaka till den huvudsakliga återställningsdialogrutan, där du kan slutföra återställningen.

Kodexempel

Det här avsnittet innehåller följande exempel.

Anmärkning

En självstudiekurs om hur du använder SQL Server 2016 med Azure Blob Storage finns i Självstudie: Använda Azure Blob Storage med SQL Server

Skapa en signatur för delad åtkomst

I följande exempel skapas signaturer för delad åtkomst som kan användas för att skapa en SQL Server-autentiseringsuppgift i en nyligen skapad container. Skriptet skapar en signatur för delad åtkomst som är associerad med en princip för lagrad åtkomst. Mer information finns i Signaturer för delad åtkomst, del 1: Förstå SAS-modellen. Skriptet skriver även det T-SQL-kommando som krävs för att skapa autentiseringsuppgifterna på SQL Server.

Anmärkning

Exemplet kräver Microsoft Azure PowerShell. Information om hur du installerar och använder Azure PowerShell finns i Installera och konfigurera Azure PowerShell.
Dessa skript verifierades med hjälp av Azure PowerShell 5.1.15063.

Signatur för delad åtkomst som är associerad med en princip för lagrad åtkomst

# Define global variables for the script
$prefixName = '<a prefix name>'  # used as the prefix for the name for various objects
$subscriptionName='<your subscription name>'   # the name of subscription name you will use
$locationName = '<a data center location>'  # the data center region you will use
$storageAccountName= $prefixName + 'storage' # the storage account name you will create or use
$containerName= $prefixName + 'container'  # the storage container name to which you will attach the SAS policy with its SAS token
$policyName = $prefixName + 'policy' # the name of the SAS policy

# Set a variable for the name of the resource group you will create or use
$resourceGroupName=$prefixName + 'rg'

# adds an authenticated Azure account for use in the session
Connect-AzAccount

# set the tenant, subscription and environment for use in the rest of
Set-AzContext -SubscriptionName $subscriptionName

# create a new resource group - comment out this line to use an existing resource group
New-AzResourceGroup -Name $resourceGroupName -Location $locationName

# Create a new ARM storage account - comment out this line to use an existing ARM storage account
New-AzStorageAccount -Name $storageAccountName -ResourceGroupName $resourceGroupName -Type Standard_RAGRS -Location $locationName

# Get the access keys for the ARM storage account
$accountKeys = Get-AzStorageAccountKey -ResourceGroupName $resourceGroupName -Name $storageAccountName

# Create a new storage account context using an ARM storage account
$storageContext = New-AzStorageContext -StorageAccountName $storageAccountName -StorageAccountKey $accountKeys[0].value

# Creates a new container in Azure Blob Storage
$container = New-AzStorageContainer -Context $storageContext -Name $containerName
$cbc = $container.CloudBlobContainer

# Sets up a Stored Access Policy and a Shared Access Signature for the new container
$policy = New-AzStorageContainerStoredAccessPolicy -Container $containerName -Policy $policyName -Context $storageContext -ExpiryTime $(Get-Date).ToUniversalTime().AddYears(10) -Permission "rwld"
$sas = New-AzStorageContainerSASToken -Policy $policyName -Context $storageContext -Container $containerName
Write-Host 'Shared Access Signature= '$($sas.TrimStart('?'))''

# Outputs the Transact SQL to the clipboard and to the screen to create the credential using the Shared Access Signature
Write-Host 'Credential T-SQL'
$tSql = "CREATE CREDENTIAL [{0}] WITH IDENTITY='Shared Access Signature', SECRET='{1}'" -f $cbc.Uri,$sas.TrimStart('?')
$tSql | clip
Write-Host $tSql

När skriptet har körts kopierar du CREATE CREDENTIAL kommandot till ett frågeverktyg, ansluter till en instans av SQL Server och kör kommandot för att skapa autentiseringsuppgifterna med signaturen för delad åtkomst.

Skapa en autentiseringsuppgift

I följande exempel skapas SQL Server-autentiseringsuppgifter för autentisering till Azure Blob Storage. Gör något av följande.

  1. Använda signatur för delad åtkomst

    Om du körde föregående skript för att skapa signaturen för delad åtkomst kopierar du CREATE CREDENTIAL till en frågeredigerare som är ansluten till din instans av SQL Server och kör kommandot.

    Följande T-SQL är ett exempel som skapar autentiseringsuppgifterna för att använda en signatur för delad åtkomst.

    IF NOT EXISTS (SELECT *
               FROM sys.credentials
               WHERE name = 'https://<mystorageaccountname>.blob.core.windows.net/<mystorageaccountcontainername>')
    CREATE CREDENTIAL [https://<mystorageaccountname>.blob.core.windows.net/<mystorageaccountcontainername>]
        WITH IDENTITY = 'SHARED ACCESS SIGNATURE', SECRET = '<SAS_TOKEN>';

  2. Använda lagringskontots identitet och åtkomstnyckel

    IF NOT EXISTS (SELECT *
               FROM sys.credentials
               WHERE name = '<mycredentialname>')
    CREATE CREDENTIAL [<mycredentialname>]
        WITH IDENTITY = '<mystorageaccountname>', SECRET = '<mystorageaccountaccesskey>';

Utföra en fullständig databassäkerhetskopia

I följande exempel utförs en fullständig databassäkerhetskopia av AdventureWorks2022 databasen till Azure Blob Storage. Använd något av följande exempel:

  1. Till URL med signatur för delad åtkomst

    BACKUP DATABASE AdventureWorks2022
    TO URL = 'https://<mystorageaccountname>.blob.core.windows.net/<mycontainername>/AdventureWorks2022.bak';
GO

  2. Till URL med lagringskontots identitet och åtkomstnyckel

    BACKUP DATABASE AdventureWorks2022
TO URL = 'https://<mystorageaccountname>.blob.core.windows.net/<mycontainername>/AdventureWorks2022.bak'
WITH CREDENTIAL = '<mycredentialname>',
COMPRESSION, STATS = 5;
GO

Återställ till en specifik tidpunkt med kommandot STOPAT

I följande exempel återställs exempeldatabasen AdventureWorks2022 till dess tillstånd vid en tidpunkt och visar en återställningsåtgärd.

Från URL med signatur för delad åtkomst

RESTORE DATABASE AdventureWorks2022 FROM URL = 'https://<mystorageaccountname>.blob.core.windows.net/<mycontainername>/AdventureWorks2022_2015_05_18_16_00_00.bak'
WITH
MOVE 'AdventureWorks2022_data' TO 'C:\Program Files\Microsoft SQL Server\<myinstancename>\MSSQL\DATA\AdventureWorks2022.mdf',
MOVE 'AdventureWorks2022_log' TO 'C:\Program Files\Microsoft SQL Server\<myinstancename>\MSSQL\DATA\AdventureWorks2022.ldf',
NORECOVERY, REPLACE, STATS = 5;
GO

RESTORE LOG AdventureWorks2022 FROM URL = 'https://<mystorageaccountname>.blob.core.windows.net/<mycontainername>/AdventureWorks2022_2015_05_18_18_00_00.trn'
WITH RECOVERY, STOPAT = 'May 18, 2015 5:35 PM';
GO

Relaterat innehåll