Notitie
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen u aan te melden of de directory te wijzigen.
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen de mappen te wijzigen.
Van toepassing op:SQL Server
Azure SQL Managed Instance
In dit artikel worden de concepten, vereisten en onderdelen geïntroduceerd die nodig zijn voor het gebruik van Azure Blob Storage als back-upbestemming. De functionaliteit voor back-up en herstel is hetzelfde of vergelijkbaar met wanneer u deze gebruikt DISK of TAPE, met een paar verschillen. Deze verschillen en enkele codevoorbeelden zijn opgenomen in dit artikel.
Tip
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.
Overview
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 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 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 BACKUP/RESTORE TO/FROM URL syntaxis 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. Voor meer informatie over het gebruik van back-up naar een URL voor S3-compatibele opslag, raadpleegt u SQL Server backup naar URL voor S3-compatibele objectopslag.
Back-up maken naar Azure Storage-blok-blob versus pagina-blob
Er zijn twee typen blobs die kunnen worden opgeslagen in 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.exegebruiken.
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
- Containers
- 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.
Azure Blob Storage (opslagdienst van Azure)
Opslagaccount: Het opslagaccount is het startpunt voor alle opslagservices. Als u toegang wilt krijgen tot Azure Blob Storage, maakt u eerst een Azure Storage-account. 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.
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 dit, BACKUP tenzij de WITH FORMAT optie 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.
Note
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 op, of container-URL en het bijbehorende Shared Access Signature-token. Zodra de referentie is gemaakt, bepaalt de syntaxis van de BACKUP/RESTORE instructies 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:
Configureer onveranderbaarheid voor uw Azure Storage-container.
Schakel traceringsvlag 3012 in voor uw SQL Server-exemplaar door de volgende DBCC-opdracht uit te voeren:
DBCC TRACEON(3012, -1);Geef de BACKUP uit om een back-up te maken van uw database naar de Azure-opslagcontainer. Als u de
WITH FORMAToptie voor onveranderbare opslag gebruikt en er al een back-up met dezelfde naam bestaat, krijgt u een foutmelding en mislukt de back-up.BACKUP DATABASE [<Database>] TO URL = '<url>';
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.
Important
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.
Warning
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 wordt gebruikt om opdrachten met
BACKUPofRESTOREte geven, moet de databaserol van de db_backup operator hebben met machtigingen voor het aanpassen van referenties.
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 TBImportant
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.
Wanneer u een back-up maakt van een Azure Storage-account, ondersteunt SQL Server 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_dumpdeviceof 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 FORMAToptie. Wanneer u echter back-ups van bestandsmomentopnamen gebruikt (met behulp van hetWITH FILE_SNAPSHOTargument), mag hetWITH FORMATargument 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
BLOCKSIZEwordt niet ondersteund voor pagina-blobs.Het specificeren van
MAXTRANSFERSIZEwordt niet ondersteund voor pagina-blobs.Back-upsetopties specificeren -
RETAINDAYSenEXPIREDATEworden niet ondersteund.SQL Server heeft een maximale limiet van 259 tekens voor de naam van een back-upapparaat. De
BACKUP TO URLverbruikt 36 tekens voor de vereiste elementen die worden gebruikt om de URLhttps://.blob.core.windows.net//.bakop te geven, waarbij 223 tekens voor account-, container- 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:
- Het proxycfg.exe hulpprogramma op Windows XP of Windows Server 2003 en eerder.
- Het hulpprogrammanetsh.exe op Windows Vista en Windows Server 2008 of hoger.
Onveranderbare opslag voor Azure Blob Storage wordt niet ondersteund. Stel het onveranderbare opslagbeleid in op onwaar.
Back-up naar URL wordt niet ondersteund voor Premium Storage.
Ondersteunde argumenten en verklaringen in Azure Blob Storage
Ondersteuning voor back-up-/herstelinstructies in Azure Blob Storage
| Back-up-/herstelverklaring | Supported | Exceptions | Comments |
|---|---|---|---|
BACKUP |
Yes |
BLOCKSIZE en MAXTRANSFERSIZE worden ondersteund voor blok-blobs. Ze worden niet ondersteund voor paginablobs. |
BACKUP voor een blok-blob is een Gedeelde Toegangssignatuur vereist die is opgeslagen in SQL Server-verificatiegegevens.
BACKUP voor pagina-blob is de sleutel van het opslagaccount vereist die is opgeslagen in een SQL Server-referentie en moet het WITH CREDENTIAL argument worden opgegeven. |
RESTORE |
Yes | Vereist dat een SQL Server-referentie wordt gedefinieerd en vereist dat het WITH CREDENTIAL argument wordt opgegeven als de SQL Server-referentie is gedefinieerd met behulp van de sleutel van het opslagaccount als het geheim |
|
RESTORE FILELISTONLY |
Yes | Vereist dat een SQL Server-referentie wordt gedefinieerd en vereist dat het WITH CREDENTIAL argument wordt opgegeven als de SQL Server-referentie is gedefinieerd met behulp van de sleutel van het opslagaccount als het geheim |
|
RESTORE HEADERONLY |
Yes | Vereist dat een SQL Server-referentie wordt gedefinieerd en vereist dat het WITH CREDENTIAL argument wordt opgegeven als de SQL Server-referentie is gedefinieerd met behulp van de sleutel van het opslagaccount als het geheim |
|
RESTORE LABELONLY |
Yes | Vereist dat een SQL Server-referentie wordt gedefinieerd en vereist dat het WITH CREDENTIAL argument wordt opgegeven als de SQL Server-referentie is gedefinieerd met behulp van de sleutel van het opslagaccount als het geheim |
|
RESTORE VERIFYONLY |
Yes | Vereist dat een SQL Server-referentie wordt gedefinieerd en vereist dat het WITH CREDENTIAL argument wordt opgegeven als de SQL Server-referentie is gedefinieerd met behulp van de sleutel van het opslagaccount als het geheim |
|
RESTORE REWINDONLY |
No |
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
| Argument | Supported | Exception | Comments |
|---|---|---|---|
DATABASE |
Yes | ||
LOG |
Yes | ||
TO (URL) |
Yes | In tegenstelling tot DISK en TAPEbiedt 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. |
MIRROR TO |
Yes | ||
WITH Opties: |
|||
CREDENTIAL |
Yes |
WITH CREDENTIAL wordt alleen ondersteund wanneer de optie BACKUP TO URL wordt 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 geheim |
|
FILE_SNAPSHOT |
Yes | ||
ENCRYPTION |
Yes | 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). |
|
DIFFERENTIAL |
Yes | ||
COPY_ONLY |
Yes | ||
COMPRESSION|NO_COMPRESSION |
Yes | Niet ondersteund voor back-ups van momentopnamen van bestanden | |
DESCRIPTION |
Yes | ||
NAME |
Yes | ||
EXPIREDATE | RETAINDAYS |
No | ||
NOINIT | INIT |
No | 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 | SKIP |
No | ||
NOFORMAT | FORMAT |
Yes | 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 back-ups van bestandsmomentopnamen gebruikt (met behulp van het WITH FILE_SNAPSHOT argument), mag het FORMAT argument niet worden gebruikt om achtergelaten bestandsmomentopnamen te vermijden die zijn gemaakt met de oorspronkelijke back-up van de momentopname. 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. |
|
MEDIADESCRIPTION |
Yes | ||
MEDIANAME |
Yes | ||
BLOCKSIZE |
Yes | Niet ondersteund voor pagina-blob. Ondersteuning beschikbaar voor block blob. | Het wordt aanbevolen om BLOCKSIZE=65536 te gebruiken om het gebruik van de 50.000 toegestane blokken in een blok-blob te optimaliseren. |
BUFFERCOUNT |
Yes | ||
MAXTRANSFERSIZE |
Yes | Niet ondersteund voor pagina-blob. Ondersteuning beschikbaar voor block blob. | De standaardwaarde is 1048576. De waarde kan oplopen tot 4 MB in stappen van 65.536 bytes. Het wordt aanbevolen om MAXTRANSFERSIZE=4194304 te gebruiken om het gebruik van de 50.000 toegestane blokken in een blok-blob te optimaliseren. |
NO_CHECKSUM | CHECKSUM |
Yes | ||
STOP_ON_ERROR | CONTINUE_AFTER_ERROR |
Yes | ||
STATS |
Yes | ||
REWIND | NOREWIND |
No | ||
UNLOAD | NOUNLOAD |
No | ||
NORECOVERY | STANDBY |
Yes | ||
NO_TRUNCATE |
Yes |
Zie BACKUP voor meer informatie over back-upargumenten.
Ondersteuning voor herstelargumenten in Azure Blob Storage
| Argument | Supported | Exceptions | Comments |
|---|---|---|---|
DATABASE |
Yes | ||
LOG |
Yes | ||
FROM (URL) |
Yes | Het FROM URL argument wordt gebruikt om het URL-pad voor het back-upbestand op te geven. |
|
WITH Opties: |
|||
CREDENTIAL |
Yes |
WITH CREDENTIAL wordt alleen ondersteund wanneer u RESTORE FROM URL de optie gebruikt om te herstellen vanuit Azure Blob Storage. |
|
PARTIAL |
Yes | ||
RECOVERY | NORECOVERY | STANDBY |
Yes | ||
LOADHISTORY |
Yes | ||
MOVE |
Yes | ||
REPLACE |
Yes | ||
RESTART |
Yes | ||
RESTRICTED_USER |
Yes | ||
FILE |
No | ||
PASSWORD |
Yes | ||
MEDIANAME |
Yes | ||
MEDIAPASSWORD |
Yes | ||
BLOCKSIZE |
Yes | ||
BUFFERCOUNT |
No | ||
MAXTRANSFERSIZE |
No | ||
CHECKSUM | NO_CHECKSUM |
Yes | ||
STOP_ON_ERROR | CONTINUE_AFTER_ERROR |
Yes | ||
FILESTREAM |
Yes | Niet ondersteund voor back-ups van momentopnamen | |
STATS |
Yes | ||
REWIND | NOREWIND |
No | ||
UNLOAD | NOUNLOAD |
No | ||
KEEP_REPLICATION |
Yes | ||
KEEP_CDC |
Yes | ||
ENABLE_BROKER | ERROR_BROKER_CONVERSATIONS | NEW_BROKER |
Yes | ||
STOPAT | STOPATMARK | STOPBEFOREMARK |
Yes |
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.
Note
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:
Maak in Objectverkennerverbinding met een exemplaar van de SQL Server Database Engine en vouw dat exemplaar vervolgens uit.
Vouw Databases uit, klik met de rechtermuisknop op de gewenste database, wijs Taken aan en selecteer Back-up....
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 Azure Storage. Selecteer Toevoegen en het dialoogvenster Back-updoel selecteren wordt geopend:
Azure Storage-container: De naam van de Azure Storage-container voor het opslaan van de back-upbestanden. Selecteer een bestaande container in de vervolgkeuzelijst of voer de container handmatig in.
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.
Back-upbestand: Naam van het back-upbestand.
Nieuwe container: Wordt gebruikt om een bestaande container te registreren waarvoor u geen Shared Access Signature hebt. Zie Verbinding maken met een Azure-abonnement (back-up naar URL).
Note
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:
- Backup van database (Algemene pagina)
- Back-up maken van database (pagina Mediaopties)
- Back-up maken van de database (Pagina Back-up-opties)
- Referentie maken - Verifiëren bij Azure Storage
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.
Note
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:
Klik met de rechtermuisknop op Databases en selecteer Database terugzetten....
Selecteer op de Algemene pagina Apparaat onder de Bron sectie.
Selecteer de knop Bladeren (...) om het dialoogvenster Back-upapparaten selecteren te openen.
Selecteer de URL in de keuzelijst voor type back-upmedia: Selecteer Toevoegen om het dialoogvenster Een back-upbestandslocatie selecteren te openen.
Azure Storage-container: De volledig gekwalificeerde naam van de Azure Storage-container die de back-upbestanden bevat. Selecteer een bestaande container in de vervolgkeuzelijst of voer handmatig de volledig gekwalificeerde containernaam in.
Shared Access Signature: Wordt gebruikt om de Shared Access Signature voor de aangewezen container in te voeren.
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).
OK: SQL Server maakt verbinding met 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.
- Database herstellen (pagina Algemeen)
- Database herstellen (Bestandenpagina)
- Database herstellen (pagina Opties)
Codevoorbeelden
Deze sectie bevat de volgende voorbeelden.
- Een Shared Access Signature maken
- Een referentie maken
- Perform a full database backup (Volledige back-up van de database uitvoeren)
- Herstellen naar een bepaald tijdstip met BEHULP van STOPAT
Note
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.
Note
Voor het voorbeeld is 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.
Shared Access Signature gebruiken
Als u het vorige script hebt uitgevoerd om de Shared Access Signature te maken, kopieert u de
CREATE CREDENTIALnaar 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>';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:
URL gebruiken met gedeelde toegangshandtekening
BACKUP DATABASE AdventureWorks2022 TO URL = 'https://<mystorageaccountname>.blob.core.windows.net/<mycontainername>/AdventureWorks2022.bak'; GONaar 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