Dela via

Återställa en databas till SQL Server 2022 från Azure SQL Managed Instance

  • Artikel

gäller för:Azure SQL Managed Instance

I den här artikeln beskrivs hur du återställer en databassäkerhetskopia från Azure SQL Managed Instance till SQL Server 2022.

Överblick

Databasformatjusteringen mellan SQL Managed Instance och SQL Server 2022 ger dig ett enkelt sätt att kopiera eller flytta databaser från din hanterade instans till en Enterprise-, Developer- eller Standard-version av SQL Server 2022 som finns lokalt, på virtuella datorer i Azure eller i andra moln.

Återställning av databaser från hanterade instanser till SQL Server 2022-instanser låser upp följande scenarier:

  • Säkerställer databasmobilitet mellan SQL Managed Instance och SQL Server-baserade produkter.
  • Tillhandahåller databaskopior till kunder och andra berättigade parter.
  • Uppdaterar miljöer utanför SQL Managed Instance.

Möjligheten att återställa fullständiga säkerhetskopior av databaser från SQL Managed Instance till SQL Server 2022 är tillgänglig som standard i alla befintliga och eventuella nya distribuerade instanser.

Viktig

Möjligheten att återställa fullständiga säkerhetskopior av databaser från SQL Managed Instance till SQL Server 2022 är tillgänglig fram till slutet av mainstream-stöd för SQL Server 2022.

Gör en säkerhetskopia på SQL Managed Instance

Skapa först en autentiseringsuppgift för att komma åt lagringskontot från din instans, ta en säkerhetskopia av databasen och sedan lagra den.

Du kan skapa dina autentiseringsuppgifter med hjälp av en hanterad identitet eller en SAS-token (signatur för delad åtkomst).

En hanterad identitet är en funktion i Microsoft Entra-ID (tidigare Azure Active Directory) som tillhandahåller instanser av Azure-tjänster, till exempel Azure SQL Managed Instance, med en automatiskt hanterad identitet i Microsoft Entra-ID, den systemtilldelade hanterade identiteten.

Du kan använda den här identiteten för att auktorisera begäranden om dataåtkomst till andra Azure-resurser, inklusive lagringskonton. Tjänster som Azure SQL Managed Instance har en systemtilldelad hanterad identitet och kan också ha en eller flera användartilldelade hanterade identiteter. Du kan använda antingen systemtilldelade hanterade identiteter eller användartilldelade hanterade identiteter för att auktorisera begäranden.

Innan Azure Storage-administratören skriver en säkerhetskopia till ett lagringskonto måste de ge behörighet till den hanterade identiteten för att kunna skriva data. Att bevilja behörigheter till den hanterade identiteten för instansen görs på samma sätt som att bevilja behörigheter till andra Microsoft Entra-användare. Till exempel:

  1. I Azure-portalen, i fönstret Åtkomstkontroll (IAM) för ett lagringskonto, välj Lägg till rolltilldelning.

  2. Välj den inbyggda rollbaserade åtkomstkontrollen Storage Blob Data Contributor i Azure (RBAC). Detta ger läs-/skrivåtkomst till den hanterade identiteten för nödvändiga Azure Blob Storage-containrar.

    I stället för att bevilja den hanterade identiteten Azure RBAC-rollen Storage Blob Data Contributor kan du bevilja mer specifika behörigheter. Mer information finns i Ange ACL:er i Azure Data Lake Storage Gen2.

  3. På nästa sida för Tilldela åtkomst tillväljer du Hanterad identitet.

  4. Välj Välj medlemmar och välj sedan lämplig hanterad identitet i listrutan Hanterad identitet. Mer information finns i Tilldela Azure-roller med hjälp av Azure-portalen.

Nu är det enkelt att skapa databasomfattande autentiseringsuppgifter för hanterad identitetsautentisering.

Observera i följande exempel att Managed Identity är en hårdkodad sträng och att du måste ersätta det allmänna lagringskontonamnet med namnet på det faktiska lagringskontot:

CREATE CREDENTIAL [https://<mystorageaccountname>.blob.core.windows.net/<containername>] 
WITH IDENTITY = 'MANAGED IDENTITY'

Ta sedan en COPY_ONLY säkerhetskopia av databasen genom att köra följande exempel på T-SQL-kommandot:

BACKUP DATABASE [SampleDB]
TO URL = 'https://<mystorageaccountname>.blob.core.windows.net/<containername>/SampleDB.bak'
WITH COPY_ONLY

Återställa till SQL Server

Återställ databasen till SQL Server med hjälp av alternativet WITH MOVE för T-SQL-kommandot RESTORE DATABASE och explicita filsökvägar för dina filer på målservern.

Om du vill återställa databasen till SQL Server kör du följande T-SQL-exempelkommando med filsökvägar som är lämpliga för din miljö:

RESTORE DATABASE [SampleDB]
FROM URL = 'https://<mystorageaccountname>.blob.core.windows.net/<containername>/SampleDB.bak'
WITH
MOVE 'data_0' TO 'C:\Program Files\Microsoft SQL Server\MSSQL16.MSSQLSERVER\MSSQL\DATA\SampleDB_data_0.mdf',
MOVE 'log' TO 'C:\Program Files\Microsoft SQL Server\MSSQL16.MSSQLSERVER\MSSQL\DATA\SampleDBlog.ldf',
MOVE 'XTP' TO 'C:\Program Files\Microsoft SQL Server\MSSQL16.MSSQLSERVER\MSSQL\DATA\SampleDB_xtp.xtp'

Not

Om du vill återställa databaser som krypteras i vila med hjälp av transparent datakryptering (TDE)måste målinstansen av SQL Server ha åtkomst till samma nyckel som används för att skydda källdatabasen via SQL Server Connector för Azure Key Vault. För detaljer, se Ställ in SQL Server TDE med AKV.

Överväganden

Tänk på följande när du återställer en databas till SQL Server:

  • Du måste använda WITH MOVE-kvalificeraren och ange explicita sökvägar för datafilerna.
  • Databaser som är krypterade med tjänsthanterade TDE-nycklar kan inte återställas till SQL Server. Du kan bara återställa en krypterad databas till SQL Server om den krypterades med en kundhanterad nyckel och målservern har åtkomst till samma nyckel som används för att kryptera databasen. Mer information finns i Konfigurera SQL Server TDE med Azure Key Vault.
  • Den här funktionen är endast tillgänglig för instanser med SQL Server 2022 uppdateringsprincip. Du kommer inte att kunna återställa databassäkerhetskopian till SQL Server 2022 från en instans med Alltid uppdaterad uppdateringsprincip.
  • När du har återställt en Azure SQL Managed Instance-databas till SQL Server 2022 och släppt ett index eller en tabell med ett index kan du se fel 8992 när du kör kommandot DBCC CHECKDB.

Nästa steg