Delen via

Back-up van SQL Server naar een URL voor Microsoft Azure Blob Storage

Van toepassing op:SQL ServerAzure SQL Managed Instance

In dit artikel worden de concepten, vereisten en onderdelen geïntroduceerd die nodig zijn voor het gebruik van Microsoft Azure Blob Storage als back-upbestemming. De functionaliteit voor back-up en herstel is hetzelfde als bij het gebruik van SCHIJF of TAPE, met enkele verschillen. Deze verschillen en enkele codevoorbeelden zijn opgenomen in dit artikel.

Aanbeveling

SQL Server 2025 (17.x) Preview introduceert back-up naar URL met beheerde identiteit. Beoordeel back-up naar URL met beheerde identiteit (preview) - SQL Server ingeschakeld via Azure Arc.

Overzicht

SQL Server 2012 Service Pack 1 CU2 en SQL Server 2014 hebben de mogelijkheid geïntroduceerd om een back-up te maken van een URL die wijst op Azure Blob Storage, met behulp van vertrouwde T-SQL-syntaxis om veilig back-ups naar Azure Storage te schrijven. SQL Server 2016 (13.x) heeft File-Snapshot Back-ups voor Database Files in Azure geïntroduceerd en beveiliging via SAS-sleutels (Shared Access Signature), een veilige en eenvoudige manier om certificaten te verifiëren bij azure Storage-beveiligingsbeleid.

Het is belangrijk om inzicht te hebben in de onderdelen en de interactie tussen deze onderdelen om een back-up uit te voeren naar of te herstellen vanuit Microsoft Azure Blob Storage.

Azure Storage-account maken in uw Azure-abonnement is de eerste stap in dit proces. Dit opslagaccount is een beheerdersaccount met volledige beheerdersmachtigingen voor alle containers en objecten die zijn gemaakt met het opslagaccount. SQL Server kan de naam van het Azure-opslagaccount en de bijbehorende toegangssleutelwaarde gebruiken om blobs te verifiëren en te schrijven en te lezen naar Microsoft Azure Blob Storage of een Shared Access Signature-token gebruiken dat is gegenereerd op specifieke containers die deze lezen- en schrijfrechten verlenen. Voor meer informatie over Azure Storage-accounts raadpleegt u Over Azure Storage-accounts en voor meer informatie over Shared Access Signatures, zie Shared Access Signatures, Deel 1: Inzicht in het SAS-model. De SQL Server-referentie slaat deze verificatiegegevens op en wordt gebruikt tijdens de back-up- of herstelbewerkingen.

Met Azure Storage en S3 compatibele opslag

SQL Server 2022 (16.x) introduceert de mogelijkheid om back-ups te schrijven naar S3-compatibele objectopslag, met functionaliteit voor back-up en herstel, conceptueel vergelijkbaar met het werken met Back-up naar URL met behulp van Azure Blob Storage als back-upapparaattype. SQL Server 2022 (16.x) breidt de syntaxis VAN BACK-UP/RESTORE TO/FROM-URL uit door ondersteuning toe te voegen voor een nieuwe S3-connector met behulp van de REST API.

Dit artikel bevat informatie over het gebruik van back-up naar URL voor Azure Blob Storage. Raadpleeg SQL Server-back-up naar URL voor S3-compatibele objectopslag voor meer informatie over het gebruik van back-up naar URL voor S3-compatibele opslag.

Back-up maken naar Azure Storage-blok-blob versus pagina-blob

Er zijn twee typen blobs die kunnen worden opgeslagen in Microsoft Azure Blob Storage: blok- en pagina-blobs. Voor SQL Server 2016 en hoger heeft blok-blob de voorkeur.

Als de opslag-sleutel wordt gebruikt in de credential, wordt een page blob gebruikt; als de Shared Access Signature wordt gebruikt, wordt een block blob gebruikt.

Back-up naar blok-blob is alleen beschikbaar in SQL Server 2016 of hoger voor back-up naar Azure Blob Storage. Back-up maken naar blok-blob in plaats van pagina-blob als u SQL Server 2016 of hoger gebruikt.

De belangrijkste redenen zijn:

  • Shared Access Signature is een veiligere manier om blobtoegang te autoriseren in vergelijking met de opslagsleutel.
  • U kunt een back-up maken van meerdere blok-blobs om betere back-up- en herstelprestaties te krijgen en grotere databaseback-ups te ondersteunen.
  • Block blob is goedkoper dan page blob.
  • Klanten die een back-up moeten maken van pagina-blobs via een proxyserver, moeten backuptourl.exe gebruiken.

Het maken van een back-up van een grote database naar Azure Blob Storage is onderhevig aan de beperkingen die worden vermeld in T-SQL-verschillen, beperkingen en bekende problemen in Azure SQL Managed Instance.

Als de database te groot is, doe dan het volgende:

  • Back-up compressie gebruiken of
  • Een back-up maken naar meerdere blokblobs

Ondersteuning voor Linux, containers en SQL Managed Instance ingeschakeld door Azure Arc

Als het SQL Server-exemplaar wordt gehost op Linux, waaronder:

  • Zelfstandig besturingssysteem
  • Verpakkingen
  • SQL Managed Instance ingeschakeld door Azure Arc
  • Elke andere linux-omgeving

De enige ondersteunde back-up naar URL voor Azure Blob Storage is het blokkeren van blobs met behulp van de Shared Access Signature.

Microsoft Azure Blob Storage

Opslagaccount: Het opslagaccount is het startpunt voor alle opslagservices. Als u toegang wilt krijgen tot Microsoft Azure Blob Storage, maakt u eerst een Azure-opslagaccount. Zie Een opslagaccount maken voor meer informatie

Container: Een container biedt een groepering van een set blobs en kan een onbeperkt aantal blobs opslaan. Als u een SQL Server-back-up naar Azure Blob Storage wilt schrijven, moet u ten minste de hoofdcontainer hebben gemaakt. U kunt een Shared Access Signature-token genereren op een container en alleen toegang verlenen tot objecten in een specifieke container.

Blob: Een bestand van elk type en elke grootte. Er zijn twee typen blobs die kunnen worden opgeslagen in Azure Blob Storage: blok- en pagina-blobs. SQL Server-back-up kan een van beide blobtypen gebruiken, afhankelijk van de Transact-SQL syntaxis die wordt gebruikt. Blobs kunnen worden adresseerbaar met behulp van de volgende URL-indeling: https://< storage account.blob.core.windows.net/>< container>/<blob>. Zie Inleiding tot Azure Blob Storage voor meer informatie over Azure Blob Storage. Voor meer informatie over blok- en pagina-blobs, zie Understanding Block and Page Blobs.
Diagram van Azure Blob Storage-accounts, -containers en -blobs.

Azure-momentopname: Een momentopname van een Azure-blob die op een bepaald moment is gemaakt. Zie Een momentopname van een blob maken voor meer informatie. SQL Server-back-up ondersteunt nu back-ups van Azure-momentopnamen van databasebestanden die zijn opgeslagen in Azure Blob Storage. Zie File-Snapshot Backups for Database Files in Azurevoor meer informatie.

SQL Server-onderdelen

URL: Een URL specificeert een URI (Uniform Resource Identifier) naar een uniek back-upbestand. De URL wordt gebruikt om de locatie en naam van het BACK-upbestand van SQL Server op te geven. De URL moet verwijzen naar een werkelijke blob, niet alleen naar een container. Als de blob niet bestaat, wordt deze gemaakt. Als er een bestaande blob is opgegeven, mislukt back-up, tenzij de optie 'WITH FORMAT' is opgegeven om het bestaande back-upbestand in de blob te overschrijven.

Hier volgt een voorbeeld-URL-waarde: https://ACCOUNTNAME.blob.core.windows.net/<CONTAINER>/FILENAME.bak.

Opmerking

Back-up naar URL met HTTP wordt NIET ondersteund.

Geloofsbrief: Een SQL Server-referentie is een object dat wordt gebruikt voor het opslaan van verificatiegegevens die nodig zijn om verbinding te maken met een resource buiten SQL Server. Hier gebruiken back-up- en herstelprocessen van SQL Server referenties voor verificatie bij Azure Blob Storage en de bijbehorende container- en blobobjecten. De referentie slaat de naam van het opslagaccount en de toegangssleutelwaarden van het opslagaccount of de container-URL en het bijbehorende Shared Access Signature-token op. Zodra de referentie is gemaakt, bepaalt de syntaxis van de instructies BACKUP/RESTORE het type blob en de vereiste referentie.

Zie de voorbeelden van Shared Access Signature maken verderop in dit artikel, en voor het maken van een SQL Server-referentie, zie de referentie voorbeelden verderop in dit artikel.

Zie Referenties (Database Engine) voor meer informatie over referenties.

Zie Een SQL Server Agent-proxy maken voor meer informatie over andere voorbeelden waarin referenties worden gebruikt.

Ondersteuning voor onveranderbare azure-opslag

SQL Server 2025 (17.x) Preview introduceert ondersteuning voor onveranderbare Azure-opslag, die beschermt tegen ransomware-aanvallen. Bestanden die naar onveranderbare opslag worden geschreven, kunnen niet worden gewijzigd of verwijderd, zoals gedefinieerd door onveranderbaarheid.

Sql Server-back-ups worden doorgaans in twee stappen gemaakt. In eerste instantie wordt het .bak back-upbestand gemaakt met nullen en vervolgens wordt het bestand bijgewerkt met gegevens. Omdat bestandswijziging op onveranderbare opslag niet is toegestaan zodra het bestand is geschreven en doorgevoerd, slaat het back-upproces nu de eerste stap over om het back-upbestand met nullen te maken. In plaats daarvan wordt de volledige back-up in één stap gemaakt wanneer deze naar blok-blobs wordt geschreven.

Tijdens de preview is traceringsvlag 3012 vereist om onveranderbare opslagondersteuning voor back-ups naar URL in te schakelen.

Als u onveranderbare opslag wilt gebruiken met SQL Server 2025 (17.x) Preview-back-up naar URL, voert u de volgende stappen uit:

  1. Configureer onveranderbaarheid voor uw Azure Storage-container.
  2. Schakel traceringsvlag 3012 in voor uw SQL Server-exemplaar door de volgende DBCC-opdracht uit te voeren:
    DBCC TRACEON(3012,-1).
  3. Geef de BACK-up uit om een back-up te maken van uw database naar de Azure-opslagcontainer:
    BACKP DATABASE [<Database>] TO URL = ‘<url>’ WITH FORMAT.

Beveiliging voor Azure Blob Storage

Hier volgen beveiligingsoverwegingen en -vereisten bij het maken van back-ups van of het herstellen van Azure Blob Storage.

  • Bij het maken van een container voor Azure Blob Storage wordt u aangeraden de toegang tot privé in te stellen. Als u de toegang tot privé instelt, wordt de toegang beperkt tot gebruikers of accounts die de benodigde informatie kunnen verstrekken om te verifiëren bij het Azure-account.

    Belangrijk

    SQL Server vereist dat een Azure-accountnaam en toegangssleutelverificatie of een Shared Access Signature en toegangstoken worden opgeslagen in een SQL Server-referentie. Deze informatie wordt gebruikt voor verificatie bij het Azure-account bij het uitvoeren van back-up- of herstelbewerkingen.

    Waarschuwing

    Azure Storage biedt ondersteuning voor het uitschakelen van autorisatie van gedeelde sleutels voor een opslagaccount. Als autorisatie van gedeelde sleutels is uitgeschakeld, werkt sql Server Backup To URL niet.

  • Het gebruikersaccount dat gebruikt wordt om BACKUP- of RESTORE-opdrachten uit te voeren, moet in de db_backup operator databaserol zitten met Alter any credential rechten.

Beperkingen van back-up/herstel naar Azure Blob Storage

  • SQL Server beperkt de maximale back-upgrootte die wordt ondersteund met behulp van een pagina-blob tot 1 TB. De maximale back-upgrootte die wordt ondersteund met blok-blobs, is beperkt tot ongeveer 200 GB (50.000 blokken * 4 MB MAXTRANSFERSIZE). Blok-blobs ondersteunen striping om aanzienlijk grotere back-ups te ondersteunen: de limiet is maximaal 64 URL's, wat resulteert in de volgende formule: 64 stripes * 50,000 blocks * 4MB maxtransfersize = 12.8 TB

    Belangrijk

    Hoewel de maximale back-upgrootte die wordt ondersteund door één blok-blob 200 GB is, is het mogelijk voor SQL Server om te schrijven in kleinere blokgrootten, waardoor SQL Server de bloklimiet van 50.000 kan bereiken voordat de volledige back-up wordt overgedragen. Stripe-back-ups (zelfs als ze kleiner zijn dan 200 GB) om de bloklimiet te voorkomen, met name wanneer u differentiële of niet-gecomprimeerde back-ups gebruikt.

  • U kunt back-up- of herstelinstructies uitgeven met behulp van Transact-SQL, SMO, PowerShell-cmdlets of de wizard SQL Server Management Studio Backup of Restore.

  • Back-up naar Azure Storage-account ondersteunt alleen verificatie met SAS-tokens (Shared Access Signature) of opslagaccountsleutels. Alle andere verificatiemethoden, waaronder verificatie met Microsoft Entra ID (voorheen Azure Active Directory), worden niet ondersteund.

  • Het maken van een logische apparaatnaam wordt niet ondersteund. Het toevoegen van een URL als back-upapparaat via sp_dumpdevice of SQL Server Management Studio wordt niet ondersteund.

  • Toevoegen aan bestaande back-upblobs wordt niet ondersteund. Back-ups naar een bestaande blob kunnen alleen worden overschreven met behulp van de WITH FORMAT optie. Wanneer u echter back-ups van bestandsmomentopnamen gebruikt (met behulp van het WITH FILE_SNAPSHOT argument), mag het WITH FORMAT argument niet worden gebruikt om achtergelaten bestandsmomentopnamen te vermijden die zijn gemaakt met de oorspronkelijke back-up van de momentopname.

  • Back-up naar meerdere blobs in één back-upbewerking wordt alleen ondersteund met blok-blobs en het gebruik van een SAS-token (Shared Access Signature) in plaats van de opslagaccountsleutel voor de SQL-referentie.

  • Het specificeren van BLOCKSIZE wordt niet ondersteund voor pagina-blobs.

  • Het specificeren van MAXTRANSFERSIZE wordt niet ondersteund voor pagina-blobs.

  • Back-upsetopties specificeren - RETAINDAYS en EXPIREDATE worden niet ondersteund.

  • SQL Server heeft een maximale limiet van 259 tekens voor de naam van een back-upapparaat. De BACKUP TO-URL verbruikt 36 tekens voor de vereiste elementen die worden gebruikt om de URL https://.blob.core.windows.net//.bakop te geven, waarbij 223 tekens voor accounts, containers en blobnamen worden samengevoegd.

  • SQL Server 2019 (15.x) en eerdere versies hebben een limiet van 256 tekens voor SAS-tokens (Shared Access Signature), waarmee het type tokens wordt beperkt dat kan worden gebruikt (bijvoorbeeld tokens voor gebruikersdelegatiesleutels worden niet ondersteund).

  • Als uw server Toegang heeft tot Azure via een proxyserver, moet u traceringsvlag 1819 gebruiken en vervolgens de WinHTTP-proxyconfiguratie instellen via een van de volgende methoden:

  • Onveranderbare opslag voor Azure Blob Storage wordt niet ondersteund. Stel het onveranderbare opslagbeleid in op onwaar.

Ondersteunde argumenten en verklaringen in Azure Blob Storage

Ondersteuning voor back-up-/herstelinstructies in Azure Blob Storage

Back-up-/herstelverklaring Ondersteund Uitzonderingen Opmerkingen
RESERVEKOPIE Ja BLOCKSIZE en MAXTRANSFERSIZE worden ondersteund voor blok-blobs. Ze worden niet ondersteund voor paginablobs. VOOR BACK-UP naar een blok-blob is een Shared Access Signature vereist die is opgeslagen in een SQL Server-referentie. Voor BACKUP naar page blob is de sleutel van het opslagaccount die in een SQL Server-referentie is opgeslagen vereist en moet het argument WITH CREDENTIAL worden opgegeven.
HERSTELLEN Ja Vereist dat een SQL Server-referentie wordt gedefinieerd en vereist dat het argument WITH CREDENTIAL moet worden opgegeven als de SQL Server-referentie is gedefinieerd met behulp van de sleutel van het opslagaccount als geheim
Herstel FILELISTONLY Ja Vereist dat een SQL Server-referentie wordt gedefinieerd en vereist dat het argument WITH CREDENTIAL moet worden opgegeven als de SQL Server-referentie is gedefinieerd met behulp van de sleutel van het opslagaccount als geheim
HEADERONLY HERSTELLEN Ja Vereist dat een SQL Server-referentie wordt gedefinieerd en vereist dat het argument WITH CREDENTIAL moet worden opgegeven als de SQL Server-referentie is gedefinieerd met behulp van de sleutel van het opslagaccount als geheim
LABELONLY HERSTELLEN Ja Vereist dat een SQL Server-referentie wordt gedefinieerd en vereist dat het argument WITH CREDENTIAL moet worden opgegeven als de SQL Server-referentie is gedefinieerd met behulp van de sleutel van het opslagaccount als geheim
VERIFYONLY HERSTELLEN Ja Vereist dat een SQL Server-referentie wordt gedefinieerd en vereist dat het argument WITH CREDENTIAL moet worden opgegeven als de SQL Server-referentie is gedefinieerd met behulp van de sleutel van het opslagaccount als geheim
HERSTELLEN REWINDONLY -

Zie BACKUP voor syntaxis en algemene informatie over back-upinstructies.

Zie RESTORE-instructies voor syntaxis en algemene informatie over herstelinstructies.

Ondersteuning voor back-upargumenten in Azure Blob Storage

Argumentatie Ondersteund Uitzondering Opmerkingen
DATABANK Ja
logboek Ja
AAN (URL) Ja In tegenstelling tot DISK en TAPE biedt DE URL geen ondersteuning voor het opgeven of maken van een logische naam. Dit argument wordt gebruikt om het URL-pad voor het back-upbestand op te geven.
SPIEGELEN NAAR Ja
WITH Opties:
REFERENTIE Ja MET CREDENTIAL wordt alleen ondersteund wanneer u de optie BACKUP TO URL gebruikt om een back-up te maken naar Azure Blob Storage en alleen als de SQL Server-referentie is gedefinieerd met behulp van de opslagaccountsleutel als geheime sleutel.
FILE_SNAPSHOT Ja
CODERING Ja Wanneer het WITH ENCRYPTION-argument is opgegeven, zorgt SQL Server File-Snapshot Backup ervoor dat de volledige database TDE-versleuteld is voordat de back-up wordt gemaakt. Als dat het geval is, wordt het back-upbestand van de bestandsmomentopname zelf versleuteld met behulp van het algoritme dat is gespecificeerd voor TDE in de database. Als alle gegevens in de database in de hele database niet zijn versleuteld, mislukt de back-up (het versleutelingsproces is bijvoorbeeld nog niet voltooid).
DIFFERENTIAAL Ja
ALLEEN_KOPIËREN Ja
COMPRESSIE|GEEN_COMPRESSIE Ja Niet ondersteund voor back-ups van momentopnamen van bestanden
BESCHRIJVING Ja
NAAM Ja
VERVALDATUM | BEHOUDDAGEN -
NOINIT | INIT - Het is niet mogelijk om aan blobs toe te voegen. Als u een back-up wilt overschrijven, gebruikt u het WITH FORMAT argument. Wanneer u echter back-ups van bestandsmomentopnamen gebruikt (met behulp van het WITH FILE_SNAPSHOT argument), is het WITH FORMAT argument niet toegestaan om te voorkomen dat er verweesde bestandsmomentopnamen worden achtergelaten die zijn gemaakt met de oorspronkelijke back-up.
NOSKIP | OVERSLAAN -
NOFORMAT | FORMATTEREN Ja Een backup naar een bestaande blob mislukt, tenzij WITH FORMAT is opgegeven. De bestaande blob wordt overschreven wanneer WITH FORMAT is gespecificeerd. Wanneer u echter bestandsmomentopnamen-back-ups gebruikt (met behulp van het WITH FILE_SNAPSHOT argument), is het argument FORMAT niet toegestaan om te voorkomen dat achtergelaten momentopnamen van bestanden worden gecreëerd met de oorspronkelijke bestandsmomentopnamen-back-up. Wanneer u echter back-ups van bestandsmomentopnamen gebruikt (met behulp van het WITH FILE_SNAPSHOT argument), is het WITH FORMAT argument niet toegestaan om te voorkomen dat er verweesde bestandsmomentopnamen worden achtergelaten die zijn gemaakt met de oorspronkelijke back-up.
MEDIABESCHRIJVING Ja
MEDIANAME Ja
Blokgrootte Ja Niet ondersteund voor pagina-blob. Ondersteuning beschikbaar voor block blob. Raad BLOCKSIZE=65536 aan om het gebruik van de 50.000 blokken te optimaliseren die zijn toegestaan in een blok-blob.
BUFFERAANTAL Ja
MAXTRANSFERSIZE Ja Niet ondersteund voor pagina-blob. Ondersteuning beschikbaar voor block blob. De standaardwaarde is 1048576. De waarde kan oplopen tot 4 MB in stappen van 65536 bytes.
Het wordt aanbevolen om MAXTRANSFERSIZE=4194304 in te stellen om het gebruik van de 50.000 toegestane blokken in een block blob te optimaliseren.
NO_CHECKSUM | CHECKSUM Ja
STOP_BIJ_FOUT | DOORGAAN_NA_FOUT Ja
Statistieken Ja
TERUGSPOELEN | NOREWIND -
Uitladen | Niet uitladen -
NORECOVERY | STANDBY Ja
NO_TRUNCATE Ja

Zie BACKUP voor meer informatie over back-upargumenten.

Ondersteuning voor herstelargumenten in Azure Blob Storage

Argumentatie Ondersteund Uitzonderingen Opmerkingen
DATABANK Ja
logboek Ja
VAN (URL) Ja Het argument FROM URL wordt gebruikt om het URL-pad voor het back-upbestand op te geven.
MET opties:
REFERENTIE Ja MET CREDENTIAL wordt alleen ondersteund wanneer u de optie RESTORE FROM URL gebruikt om te herstellen vanuit Microsoft Azure Blob Storage.
GEDEELTELIJK Ja
HERSTEL | NORECOVERY | STANDBY Ja
LAADGESCHIEDENIS Ja
BEWEGEN Ja
VERVANGEN Ja
HERSTARTEN Ja
GEBLOKKEERDE_GEBRUIKER Ja
BESTAND -
wachtwoord Ja
MEDIANAME Ja
MEDIAPASSWORD Ja
Blokgrootte Ja
BUFFERAANTAL -
MAXTRANSFERSIZE -
CONTROLESOM | GEEN_CONTROLESOM Ja
STOP_BIJ_FOUT | DOORGAAN_NA_FOUT Ja
FILESTREAM Ja Niet ondersteund voor back-ups van momentopnamen
Statistieken Ja
TERUGSPOELEN | NOREWIND -
Uitladen | Niet uitladen -
KEEP_REPLICATIE Ja
KEEP_CDC Ja
ENABLE_BROKER | ERROR_BROKER_CONVERSATIONS | NEW_BROKER Ja
STOPAT | STOPATMARK | STOPBEFOREMARK Ja

Zie RESTORE-instructies - Argumenten voor meer informatie over herstelargumenten.

Een back-up maken met SSMS

U kunt een back-up maken van een database naar URL via de back-uptaak in SQL Server Management Studio met behulp van een SQL Server-referentie.

Opmerking

Als u een back-up van een SQL Server-bestandsmomentopname wilt maken of een bestaande mediaset wilt overschrijven, moet u Transact-SQL, PowerShell of C# gebruiken in plaats van de back-uptaak in SQL Server Management Studio.

In de volgende stappen worden de wijzigingen beschreven die zijn aangebracht in de back-updatabasetaak in SQL Server Management Studio om back-ups te maken naar Azure Storage:

  1. Maak in Objectverkennerverbinding met een exemplaar van de SQL Server Database Engine en vouw dat exemplaar vervolgens uit.

  2. Vouw Databases uit, klik met de rechtermuisknop op de gewenste database, wijs Taken aan en selecteer Back-up....

  3. Op de pagina Algemeen in de sectie Bestemming is de URL-optie beschikbaar in de vervolgkeuzelijst Back-up tot: De URL-optie wordt gebruikt om een back-up te maken naar Microsoft Azure Storage. Selecteer Toevoegen en het dialoogvenster Back-updoel selecteren wordt geopend:

    1. Azure Storage-container: De naam van de Microsoft Azure-opslagcontainer voor het opslaan van de back-upbestanden. Selecteer een bestaande container in de vervolgkeuzelijst of voer de container handmatig in.

    2. Beleid voor gedeelde toegang: Voer de Shared Access Signature in voor een handmatig ingevoerde container. Dit veld is niet beschikbaar als er een bestaande container is gekozen.

    3. Back-upbestand: Naam van het back-upbestand.

    4. Nieuwe container: Wordt gebruikt om een bestaande container te registreren waarvoor u geen Shared Access Signature hebt. Zie Verbinding maken met een Microsoft Azure-abonnement (Backup naar URL).

Opmerking

Add ondersteunt meerdere back-upbestanden en opslagcontainers voor één mediaset.

Wanneer u DE URL als bestemming selecteert, worden bepaalde opties op de pagina Mediaopties uitgeschakeld. De volgende artikelen bevatten meer informatie over het dialoogvenster Back-updatabase:

Back-up maken met onderhoudsplan

Net als bij de eerder beschreven back-uptaak bevat de wizard Onderhoudsplan in SQL Server Management Studio een URL als een van de doelopties en andere ondersteunende objecten die nodig zijn om een back-up te maken van Azure Storage, zoals de SQL-referentie. Het heeft hetzelfde voor meer informatie, zie de sectie Back-uptaken definiëren in de wizard Onderhoudsplan gebruiken.

Opmerking

Als u een gestreepte back-upset, een SQL Server-bestandssnapshot-back-up, of een SQL-referentie met behulp van een Shared Access-token wilt maken, moet u Transact-SQL, PowerShell of C# gebruiken in plaats van de back-uptaak in de Wizard Onderhoudsplan te gebruiken.

Herstellen met SSMS

De taak Database herstellen bevat de URL als een middel waaruit het herstel plaatsvindt. In de volgende stappen wordt beschreven hoe u de hersteltaak gebruikt om te herstellen vanuit Azure Blob Storage:

  1. Klik met de rechtermuisknop op Databases en selecteer Database terugzetten....

  2. Selecteer op de Algemene pagina Apparaat onder de Bron sectie.

  3. Selecteer de knop Bladeren (...) om het dialoogvenster Back-upapparaten selecteren te openen.

  4. Selecteer de URL in de keuzelijst voor type back-upmedia: Selecteer Toevoegen om het dialoogvenster Een back-upbestandslocatie selecteren te openen.

    1. Azure Storage-container: De volledig gekwalificeerde naam van de Microsoft Azure-opslagcontainer die de back-upbestanden bevat. Selecteer een bestaande container in de vervolgkeuzelijst of voer handmatig de volledig gekwalificeerde containernaam in.

    2. Shared Access Signature: Wordt gebruikt om de Shared Access Signature voor de aangewezen container in te voeren.

    3. Toevoegen: Wordt gebruikt om een bestaande container te registreren waarvoor u geen Shared Access Signature hebt. Zie Verbinding maken met een Microsoft Azure-abonnement (Backup naar URL).

    4. OK: SQL Server maakt verbinding met Microsoft Azure Storage met behulp van de SQL-referentiegegevens die u hebt opgegeven en opent het dialoogvenster Back-upbestand zoeken in Microsoft Azure . De back-upbestanden die zich in de opslagcontainer bevinden, worden op deze pagina weergegeven. Selecteer het bestand dat u wilt gebruiken om te herstellen en selecteer OK. Hiermee gaat u terug naar het dialoogvenster Back-upapparaten selecteren en door OK in dit dialoogvenster te selecteren, gaat u terug naar het hoofddialoogvenster Herstellen , waar u het herstellen kunt voltooien.

Codevoorbeelden

Deze sectie bevat de volgende voorbeelden.

Opmerking

Voor een zelfstudie over het gebruik van SQL Server 2016 met Azure Blob Storage raadpleegt u zelfstudie: Azure Blob Storage gebruiken met SQL Server

Een Shared Access Signature maken

In het volgende voorbeeld worden Shared Access Signatures gemaakt die kunnen worden gebruikt om een SQL Server-referentie te maken op een zojuist gemaakte container. Het script maakt een Shared Access Signature die is gekoppeld aan een opgeslagen toegangsbeleid. Zie Shared Access Signatures, deel 1, voor meer informatie: Inzicht in het SAS-model. Het script schrijft ook de T-SQL-opdracht die nodig is om de referentie op SQL Server te maken.

Opmerking

Voor het voorbeeld is Microsoft Azure PowerShell vereist. Zie Azure PowerShell installeren en configureren voor meer informatie over het installeren en gebruiken van Azure PowerShell.
Deze scripts zijn geverifieerd met behulp van Azure PowerShell 5.1.15063.

Shared Access Signature die is gekoppeld aan een opgeslagen toegangsbeleid

# 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

Nadat het script is uitgevoerd, kopieert u de CREATE CREDENTIAL opdracht naar een queryprogramma, maakt u verbinding met een exemplaar van SQL Server en voert u de opdracht uit om de referentie te maken met de Shared Access Signature.

Een referentie maken

In de volgende voorbeelden worden SQL Server-referenties gemaakt voor verificatie bij Azure Blob Storage. Ga op een van de volgende manieren te werk.

  1. Shared Access Signature gebruiken

    Als u het vorige script hebt uitgevoerd om de Shared Access Signature te maken, kopieert u de CREATE CREDENTIAL naar een query-editor die is verbonden met uw exemplaar van SQL Server en voert u de opdracht uit.

    De volgende T-SQL is een voorbeeld dat de referentie aanmaakt voor het gebruik van een Shared Access Signature.

    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. Identiteit en toegangssleutel van opslagaccount gebruiken

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

Een volledige databaseback-up uitvoeren

In de volgende voorbeelden wordt een volledige databaseback-up van de AdventureWorks2022 database uitgevoerd naar Azure Blob Storage. Gebruik een van de volgende voorbeelden:

  1. URL gebruiken met gedeelde toegangshandtekening

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

  2. Naar URL gebruikmakend van de identiteit en toegangssleutel van het opslagaccount

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

Herstellen naar een bepaald tijdstip met BEHULP van STOPAT

In het volgende voorbeeld wordt de AdventureWorks2022 voorbeelddatabase hersteld naar een eerder tijdstip, en wordt een herstelbewerking gedemonstreerd.

Van URL met Shared Access Signature

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

Verwante inhoud