Udostępnij za pośrednictwem


SQL Server tworzenie kopii zapasowej pod adresem URL dla Azure Blob Storage

Applies to:SQL ServerAzure SQL Managed Instance

W tym artykule przedstawiono pojęcia, wymagania i składniki niezbędne do używania Azure Blob Storage jako miejsca docelowego kopii zapasowej. Funkcja tworzenia i przywracania kopii zapasowej jest taka sama lub podobna do funkcji w przypadku używania DISK lub TAPE, z kilkoma różnicami. Te różnice i kilka przykładów kodu znajdują się w tym artykule.

Tip

Począwszy od SQL Server 2025 (17.x), możesz utworzyć kopię zapasową adresu URL przy użyciu tożsamości zarządzanej. Przejrzyj Wykonywanie kopii zapasowej na adres URL z tożsamością zarządzaną (wersja wstępna) – SQL Server obsługiwany przez Azure Arc.

Overview

SQL Server 2012 z dodatkiem Service Pack 1 CU2 i SQL Server 2014 wprowadzono możliwość tworzenia kopii zapasowych do URL wskazującego na Azure Blob Storage, używając dobrze znanej składni T-SQL do bezpiecznego zapisywania kopii zapasowych w usłudze Azure. SQL Server 2016 (13.x) wprowadzono kopie zapasowe z migawkami plików dla plików baz danych w Azure oraz zabezpieczenia poprzez klucze sygnatury współdzielonego dostępu (SAS), bezpieczny i prosty sposób uwierzytelniania certyfikatów w polityce bezpieczeństwa Azure Storage.

Ważne jest, aby zrozumieć składniki i interakcje między nimi, aby wykonać kopię zapasową lub przywrócić z Azure Blob Storage.

Tworzenie konta Azure Storage w ramach subskrypcji Azure jest pierwszym krokiem w tym procesie. To konto magazynu to konto administracyjne, które ma pełne uprawnienia administracyjne do wszystkich kontenerów i obiektów utworzonych przy użyciu konta magazynu. SQL Server może użyć nazwy konta magazynu Azure i jego wartości klucza dostępu do uwierzytelniania oraz zapisu i odczytu obiektów blob do Azure Blob Storage lub użyć tokenu sygnatury dostępu współdzielonego generowanego dla określonych kontenerów, udzielając mu praw do odczytu i zapisu. Aby uzyskać więcej informacji na temat Azure Storage Accounts, zobacz About Azure Storage Accounts i aby uzyskać więcej informacji na temat sygnatur dostępu współdzielonego, zobacz Shared Access Signatures, Part 1: Understanding the SAS Model. SQL Server Credential przechowuje te informacje uwierzytelniania i jest używany podczas operacji tworzenia kopii zapasowej lub przywracania.

Azure Storage i magazyn zgodny z protokołem S3

SQL Server 2022 (16.x) wprowadza możliwość zapisywania kopii zapasowych w magazynie obiektów zgodnym z usługą S3 z funkcją tworzenia kopii zapasowych i przywracania w sposób koncepcyjny podobny do pracy z usługą Backup pod adresem URL przy użyciu Azure Blob Storage jako typu urządzenia kopii zapasowej. SQL Server 2022 (16.x) rozszerza BACKUP/RESTORE TO/FROM URL składni, dodając obsługę nowego łącznika S3 przy użyciu interfejsu API REST.

Ten artykuł zawiera informacje na temat używania kopii zapasowej do adresu URL na Azure Blob Storage. Aby dowiedzieć się więcej na temat używania tworzenia kopii zapasowej w adresie URL magazynu zgodnego z protokołem S3, zobacz Tworzenie kopii zapasowej SQL Server do adresu URL dla magazynu obiektów zgodnego z protokołem S3.

Kopia zapasowa do Azure Storage: porównanie blokowych obiektów blob i stronicowych obiektów blob

Istnieją dwa typy obiektów blob, które można przechowywać w Azure Blob Storage: blokowe i stronicowe obiekty blob. Dla SQL Server 2016 i nowszych preferowany jest blokowy blob.

Jeśli klucz magazynu jest używany w poświadczeniu, używany jest blob stronicowy; jeśli jest używana sygnatura współdzielonego dostępu, używany jest blob blokowy.

Tworzenie kopii zapasowej do blokowego blob jest dostępne tylko w wersji SQL Server 2016 lub nowszej do tworzenia kopii zapasowych w Azure Blob Storage. W SQL Server 2016 lub nowszym wykonaj kopię zapasową do obiektu blob blokowego zamiast obiektu blob stronicowego.

Główne przyczyny to:

  • Sygnatura dostępu współdzielonego to bezpieczniejszy sposób autoryzowania dostępu do obiektów blob w porównaniu z kluczem magazynu.
  • Możesz utworzyć kopię zapasową wielu blokowych obiektów blob, aby uzyskać lepszą wydajność tworzenia kopii zapasowych i przywracania oraz obsługiwać większą kopię zapasową bazy danych.
  • Blob blokowy jest tańszy niż blob stronicowy.
  • Klienci, którzy muszą utworzyć kopię zapasową stronicowych obiektów blob za pośrednictwem serwera proxy, muszą używać polecenia backuptourl.exe.

Tworzenie kopii zapasowej dużej bazy danych do Azure Blob Storage podlega ograniczeniom wymienionym w różnicach, ograniczeniach i znanych problemach dotyczących Azure SQL Managed Instance T-SQL.

Jeśli baza danych jest za duża, albo:

  • Używanie kompresji kopii zapasowej lub
  • Tworzenie kopii zapasowej do wielu bloków blob

Obsługa systemu Linux, kontenerów i SQL Managed Instance włączona przez Azure Arc

Jeśli wystąpienie SQL Server jest hostowane w systemie Linux, w tym:

  • Autonomiczny system operacyjny
  • Containers
  • SQL Managed Instance obsługiwane przez Azure Arc
  • Dowolne inne środowisko oparte na systemie Linux

Jedyną obsługiwaną kopią zapasową adresu URL dla Azure Blob Storage jest blokowanie obiektów blob przy użyciu sygnatury dostępu współdzielonego.

Azure Blob Storage

Konto magazynu: Konto magazynu jest punktem wyjścia dla wszystkich usług magazynu. Aby uzyskać dostęp do Azure Blob Storage, najpierw utwórz konto usługi przechowywania w Azure. Aby uzyskać więcej informacji, zobacz Tworzenie konta magazynu

Kontener: Kontener udostępnia grupowanie zestawu obiektów blob i może przechowywać nieograniczoną liczbę obiektów blob. Aby zapisać kopię zapasową SQL Server do Azure Blob Storage, musisz mieć co najmniej utworzony kontener główny. Token sygnatury dostępu współdzielonego można wygenerować w kontenerze i udzielić dostępu tylko do obiektów w określonym kontenerze.

Blob: Plik dowolnego typu i rozmiaru. Istnieją dwa typy obiektów blob, które można przechowywać w Azure Blob Storage: blokowe i stronicowe obiekty blob. Kopia zapasowa SQL Servera może używać każdego typu obiektu blob w zależności od składni Transact-SQL używanej. Obiekty blob są adresowalne przy użyciu następującego formatu adresu URL: https://< kontotorage.blob.core.windows.net/>< container>/<blob>. Aby uzyskać więcej informacji na temat Azure Blob Storage, zobacz Wprowadzenie do Azure Blob Storage. Aby uzyskać więcej informacji na temat obiektów blob typu blokowego i stronicowego, zobacz Opis obiektów blob typu blokowego i stronicowego.

Diagram kont Azure Blob Storage, kontenerów i blobów.

Azure Snapshot: Migawka obiektu blob w usłudze Azure wykonana w danym momencie. Aby uzyskać więcej informacji, zobacz Tworzenie migawki obiektu blob. SQL Server obsługuje teraz kopie migawek w Azure plików bazy danych przechowywanych w Azure Blob Storage. Aby uzyskać więcej informacji, zobacz File-Snapshot Backups for Database Files in Azure (Kopie zapasowe plików bazy danych Azure

składniki SQL Server

Adres URL: Adres URL określa identyfikator URI (Uniform Resource Identifier) do unikatowego pliku kopii zapasowej. Adres URL służy do podawania lokalizacji i nazwy pliku kopii zapasowej SQL Server. Adres URL musi wskazywać rzeczywisty obiekt blob, a nie tylko kontener. Jeśli obiekt blob nie istnieje, zostanie utworzony. Jeśli istniejący obiekt blob został określony, BACKUP nie zostanie pomyślnie wykonany, chyba że określono opcję WITH FORMAT, aby zastąpić istniejący plik kopii zapasowej w obiekcie blob.

Oto przykładowa wartość adresu URL: https://ACCOUNTNAME.blob.core.windows.net/<CONTAINER>/FILENAME.bak.

Note

Tworzenie kopii zapasowej pod adresem URL przy użyciu protokołu HTTP nie jest obsługiwane.

Credential: Poświadczenie SQL Server jest obiektem używanym do przechowywania informacji uwierzytelniania wymaganych do nawiązania połączenia z zasobem poza SQL Server. Procesy tworzenia kopii zapasowych i przywracania w SQL Server używają poświadczenia do uwierzytelniania w Azure Blob Storage oraz w obiektach kontenera oraz blob. Poświadczenie przechowuje nazwę konta magazynu i wartości klucza dostępu konta magazynu lub adres URL kontenera oraz jego token sygnatury dostępu współdzielonego. Po utworzeniu poświadczenia składnia instrukcji BACKUP/RESTORE określa typ obiektu blob i wymagane poświadczenie.

Aby zapoznać się z przykładem tworzenia sygnatury dostępu współdzielonego, zobacz Tworzenie sygnatury dostępu współdzielonego przykłady w dalszej części tego artykułu oraz tworzenie poświadczeń SQL Server, zobacz Utwórz poświadczenia przykłady w dalszej części tego artykułu.

Aby uzyskać więcej informacji na temat poświadczeń, zobacz Credentials (Database Engine).

Aby uzyskać informacje na temat innych przykładów użycia poświadczeń, zobacz Tworzenie serwera proxy SQL Server Agent.

obsługa niezmiennego magazynu Azure

SQL Server 2025 (17.x) wprowadza obsługę niezmiennego magazynu Azure, który chroni przed atakami ransomware. Plików zapisywanych w magazynie niezmiennym nie można modyfikować ani usuwać zgodnie z definicją niezmienności.

Zazwyczaj kopie zapasowe SQL Server są tworzone w dwóch krokach. Początkowo plik kopii zapasowej jest tworzony z zerami, a następnie zostaje zaktualizowany danymi. Ponieważ modyfikacja pliku w magazynie niezmiennym nie jest dozwolona po zapisaniu i zatwierdzeniu pliku, proces tworzenia kopii zapasowej pomija teraz początkowy krok tworzenia pliku kopii zapasowej z zerami. Zamiast tego cała kopia zapasowa jest tworzona w jednym kroku podczas zapisywania w blokowych obiektach blob.

Azure Storage zapewnia dwa typy immutability: na poziomie kontenera i na poziomie wersji. Obecnie obsługiwany jest tylko niezmienny magazyn na poziomie kontenera.

Aby użyć niezmiennego magazynu z kopią zapasową SQL Server 2025 (17.x) na adres URL, wykonaj następujące kroki:

  1. Skonfiguruj niezmienność dla kontenera przechowywania w Azure.

  2. Wydaj BACKUP aby utworzyć kopię zapasową bazy danych w kontenerze magazynu Azure. Jeśli używasz opcji WITH FORMAT na magazynie niemodyfikowalnym, a kopia zapasowa już istnieje o tej samej nazwie, pojawi się błąd i tworzenie kopii zapasowej zakończy się niepowodzeniem.

    BACKUP DATABASE [<Database>] TO URL = '<url>';
    

Zabezpieczenia dla Azure Blob Storage

Poniżej przedstawiono zagadnienia i wymagania dotyczące zabezpieczeń podczas tworzenia kopii zapasowej lub przywracania z Azure Blob Storage.

  • Podczas tworzenia kontenera dla Azure Blob Storage zalecamy ustawienie dostępu do private. Ustawienie dostępu jako prywatny ogranicza dostęp do użytkowników lub kont, które są w stanie dostarczyć niezbędne informacje potrzebne do uwierzytelnienia konta Azure.

    Important

    SQL Server wymaga, aby nazwa konta Azure i klucz uwierzytelniania dostępu, albo sygnatura dostępu współdzielonego i token dostępu, musiały być przechowywane w poświadczeniach SQL Server. Te informacje są używane do uwierzytelniania na koncie Azure podczas wykonywania operacji tworzenia kopii zapasowej lub przywracania.

    Warning

    Azure Storage obsługuje wyłączanie autoryzacji kluczem współdzielonym dla konta magazynu. Jeśli autoryzacja klucza współużytkowanego jest wyłączona, kopie zapasowe SQL Server na URL nie będą działać.

  • Konto użytkownika używane do wydawania poleceń BACKUP lub RESTORE powinno znajdować się w roli bazy danych operator db_backup z uprawnieniami do Modyfikowania dowolnych poświadczeń.

Ograniczenia tworzenia/przywracania kopii zapasowej do Azure Blob Storage

  • SQL Server ogranicza maksymalny rozmiar kopii zapasowej obsługiwany przy użyciu stronicowego obiektu blob do 1 TB. Maksymalny rozmiar kopii zapasowej obsługiwanej przy użyciu blokowych obiektów blob jest ograniczony do około 195,3 GB (50 000 bloków x 4 MB MAXTRANSFERSIZE). Blokowe obiekty blob obsługują paskowanie w celu obsługi znacznie większych rozmiarów kopii zapasowych — limit wynosi maksymalnie 64 adresy URL, co skutkuje następującą formułą: 64 stripes * 50,000 blocks * 4MB maxtransfersize = 12.8 TB.

    Important

    Chociaż maksymalny rozmiar kopii zapasowej obsługiwany przez pojedynczy blokowy obiekt BLOB wynosi około 195,3 GB, SQL Server może zapisywać w mniejszych rozmiarach bloków, co może prowadzić do tego, że SQL Server osiągnie limit 50 000 bloków, zanim cała kopia zapasowa zostanie przeniesiona. Poddziel kopie zapasowe (nawet jeśli mają mniej niż 200 GB), aby uniknąć przekroczenia limitu bloków, zwłaszcza gdy używasz różnicowych lub nieskompresowanych kopii zapasowych.

  • Kopie zapasowe dziennika transakcji ignorują określone przez użytkownika MAXTRANSFERSIZE podczas tworzenia kopii zapasowej do wielu plików zapasowych. Zamiast tego, jeśli określono więcej niż jeden plik, używane jest 64 KB, niezależnie od wartości MAXTRANSFERSIZE w poleceniu kopii zapasowej. W związku z tym maksymalny rozmiar kopii zapasowej dziennika transakcji do adresu URL wynosi około 195,3 GB (50 000 bloków * 4 MB MAXTRANSFERSIZE * 1 plik LUB 50 000 bloków * 64 KB * 64 pliki). Kompresja może pozwolić na utworzenie kopii zapasowej większego dziennika transakcji, ale współczynniki kompresji będą się różnić.

  • Instrukcje tworzenia kopii zapasowej lub przywracania można wydać za pomocą poleceń cmdlet Transact-SQL, SMO, Programu PowerShell lub kreatora tworzenia kopii zapasowej lub przywracania SQL Server Management Studio.

  • Podczas tworzenia kopii zapasowej na konto Azure Storage, SQL Server obsługuje tylko uwierzytelnianie przy użyciu tokenów sygnatury dostępu współdzielonego (SAS) lub kluczy konta magazynu. Wszystkie inne metody uwierzytelniania, w tym uwierzytelnianie za pomocą Microsoft Entra ID (formerly Azure Active Directory), nie są obsługiwane.

  • Tworzenie nazwy urządzenia logicznego nie jest obsługiwane. Dlatego dodanie adresu URL jako urządzenia kopii zapasowej przy użyciu sp_dumpdevice lub za pośrednictwem SQL Server Management Studio nie jest obsługiwane.

  • Dołączanie do obiektów blob istniejących kopii zapasowych nie jest obsługiwane. Kopie zapasowe istniejącego obiektu blob można zastąpić tylko za pomocą opcji WITH FORMAT. Jednakże przy korzystaniu z migawkowych kopii zapasowych plików (przy użyciu argumentu WITH FILE_SNAPSHOT), argument WITH FORMAT nie jest dozwolony, aby uniknąć pozostawienia osieroconych migawek plików, które zostały utworzone przy użyciu oryginalnej migawkowej kopii zapasowej.

  • Tworzenie kopii zapasowej w wielu obiektach blob w ramach jednej operacji tworzenia kopii zapasowej jest obsługiwane tylko przy użyciu blokowych obiektów blob i tokenu sygnatury dostępu współdzielonego (SAS), a nie klucza konta magazynu dla poświadczeń SQL.

  • Określanie BLOCKSIZE nie jest obsługiwane w odniesieniu do stronicowych obiektów blob.

  • Określanie MAXTRANSFERSIZE nie jest obsługiwane dla stronicowych obiektów blob.

  • Określanie opcji zestawu kopii zapasowych — RETAINDAYS i EXPIREDATE nie są obsługiwane.

  • SQL Server ma maksymalny limit 259 znaków dla nazwy urządzenia kopii zapasowej. BACKUP TO URL zajmuje 36 znaków dla wymaganych elementów używanych do określenia adresu URL https://.blob.core.windows.net//.bak, pozostawiając 223 znaki dla nazw kont, kontenerów i obiektów blob.

  • SQL Server 2019 (15.x) i starsze wersje mają limit 256 znaków dla tokenów sygnatury dostępu współdzielonego (SAS), co ogranicza typ używanych tokenów (na przykład tokeny klucza delegowania użytkownika nie są obsługiwane).

  • Jeśli serwer uzyskuje dostęp Azure za pośrednictwem serwera proxy, należy użyć flagi śledzenia 1819, a następnie ustawić konfigurację serwera proxy WinHTTP za pomocą jednej z następujących metod:

    • Narzędzie proxycfg.exe w Windows XP lub Windows Server 2003 i starszych wersjach.
    • Narzędzie netsh.exe w Windows Vista i Windows Server 2008 lub nowszym.
  • Nieulotne przechowywanie dla Azure Blob Storage nie jest obsługiwane przed SQL Server 2025. Ustaw niezmienne zasady magazynu na wartość false.

  • Aby uzyskać informacje o obsłudze SQL Server 2025 i nowszych, zobacz obsługę niezmiennych zasobów magazynowych w Azure.

    • Magazyn Azure zapewnia dwa typy niezmienności: na poziomie kontenera i na poziomie wersji. Obecnie obsługiwany jest tylko niezmienny magazyn na poziomie kontenera.
  • Tworzenie kopii zapasowej pod adresem URL nie jest obsługiwane w magazynie w warstwie Premium.

Obsługiwane argumenty i instrukcje w Azure Blob Storage

Obsługa instrukcji tworzenia/przywracania kopii zapasowych w Azure Blob Storage

Kopia zapasowa/Odzyskiwanie oświadczenie Supported Exceptions Comments
BACKUP Yes BLOCKSIZE i MAXTRANSFERSIZE są obsługiwane w przypadku blokowych blobów. Nie są obsługiwane dla blobów stronicowych. BACKUP do blokowego obiektu blob wymaga sygnatury dostępu współdzielonego zapisanej w poświadczeniu SQL Server. BACKUP do stronicowania obiektu blob wymaga klucza konta magazynu zapisanego w poświadczeniu SQL Server i wymaga określenia argumentu WITH CREDENTIAL.
RESTORE Yes Wymaga zdefiniowania poświadczenia SQL Server oraz określenia argumentu WITH CREDENTIAL, jeśli poświadczenie SQL Server jest zdefiniowane z użyciem klucza konta magazynu jako tajnego.
RESTORE FILELISTONLY Yes Wymaga zdefiniowania poświadczenia SQL Server i wymaga określenia argumentu WITH CREDENTIAL, jeśli poświadczenie SQL Server jest definiowane przy użyciu klucza konta magazynu jako sekretu.
RESTORE HEADERONLY Yes Wymaga zdefiniowanie poświadczeń SQL Server i wymaga określenia argumentu WITH CREDENTIAL, jeśli poświadczenie SQL Server jest definiowane przy użyciu klucza konta magazynu jako wpisu tajnego
RESTORE LABELONLY Yes Wymaga zdefiniowania poświadczenia SQL Server i wymaga określenie argumentu WITH CREDENTIAL, jeśli poświadczenie SQL Server jest definiowane przy użyciu klucza konta magazynu jako tajnej wartości
RESTORE VERIFYONLY Yes Wymaga zdefiniowania poświadczeń SQL Server oraz określenia argumentu WITH CREDENTIAL, jeśli poświadczenia SQL Server są zdefiniowane przy użyciu klucza tajnego konta magazynu.
RESTORE REWINDONLY No

Aby uzyskać informacje o składni i ogólne informacje na temat poleceń dotyczących kopii zapasowych, zobacz BACKUP.

Aby uzyskać składnię i ogólne informacje na temat instrukcji RESTORE, zobacz instrukcje RESTORE.

Obsługa argumentów kopii zapasowej w Azure Blob Storage

Argument Supported Exception Comments
DATABASE Yes
LOG Yes
TO (URL) Yes W przeciwieństwie do DISK i TAPE, adres URL nie obsługuje określania ani tworzenia nazwy logicznej. Ten argument służy do określania ścieżki adresu URL dla pliku kopii zapasowej.
MIRROR TO Yes
WITH Opcje:
CREDENTIAL Yes WITH CREDENTIAL jest obsługiwana tylko w przypadku używania opcji BACKUP TO URL do tworzenia kopii zapasowej do Azure Blob Storage i tylko wtedy, gdy poświadczenie SQL Server jest definiowane przy użyciu klucza konta magazynu jako wpisu tajnego
FILE_SNAPSHOT Yes
ENCRYPTION Yes Po określeniu argumentu WITH ENCRYPTION kopia zapasowa SQL Server File-Snapshot gwarantuje, że cała baza danych została zaszyfrowana za pomocą TDE przed wykonaniem kopii zapasowej, a jeśli tak, szyfruje sam plik kopii zapasowej wykonanej metodą migawki plików przy użyciu algorytmu określonego dla TDE w tej bazie danych. Jeśli wszystkie dane w bazie danych w całej bazie danych nie są szyfrowane, tworzenie kopii zapasowej zakończy się niepowodzeniem (na przykład proces szyfrowania nie zostanie jeszcze ukończony).
DIFFERENTIAL Yes
COPY_ONLY Yes
COMPRESSION|NO_COMPRESSION Yes Nieobsługiwane w przypadku tworzenia kopii zapasowej migawki plików
DESCRIPTION Yes
NAME Yes
EXPIREDATE | RETAINDAYS No
NOINIT | INIT No Dołączanie do danych blob nie jest możliwe. Aby zastąpić kopię zapasową, użyj argumentu WITH FORMAT . Jednak, gdy korzysta się z kopii zapasowych migawek plików (za pomocą argumentu WITH FILE_SNAPSHOT), użycie argumentu WITH FORMAT nie jest dozwolone, aby uniknąć pozostawienia osieroconych migawek plików utworzonych przy użyciu oryginalnej kopii zapasowej.
NOSKIP | SKIP No
NOFORMAT | FORMAT Yes Tworzenie kopii zapasowej wykonanej do istniejącego obiektu blob kończy się niepowodzeniem, chyba że WITH FORMAT zostanie określone. Istniejący obiekt blob zostaje nadpisany, gdy WITH FORMAT jest określony. Jednakże przy korzystaniu z migawkowych kopii zapasowych plików (przy użyciu argumentu WITH FILE_SNAPSHOT), argument FORMAT nie jest dozwolony, aby uniknąć pozostawienia osieroconych migawek plików, które zostały utworzone przy użyciu oryginalnej migawkowej kopii zapasowej. Jednak, gdy korzysta się z kopii zapasowych migawek plików (za pomocą argumentu WITH FILE_SNAPSHOT), użycie argumentu WITH FORMAT nie jest dozwolone, aby uniknąć pozostawienia osieroconych migawek plików utworzonych przy użyciu oryginalnej kopii zapasowej.
MEDIADESCRIPTION Yes
MEDIANAME Yes
BLOCKSIZE Yes Nieobsługiwane dla stronicowego obiektu blob. Obsługiwane dla blokowych blobów. Zaleca się użycie BLOCKSIZE=65536, aby optymalnie wykorzystać 50 000 bloków dozwolonych w obiekcie blob typu blokowego.
BUFFERCOUNT Yes
MAXTRANSFERSIZE Yes Nieobsługiwane dla stronicowego obiektu blob. Obsługiwane dla blokowych blobów. Wartość domyślna to 1048576. Wartość może rosnąć do 4 MB w przyrostach wynoszących 65 536 bajtów.

Zaleca się użycie MAXTRANSFERSIZE=4194304, aby optymalnie wykorzystać 50 000 bloków dozwolonych w obiekcie blob typu blokowego.
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

Aby uzyskać więcej informacji na temat argumentów kopii zapasowej, zobacz BACKUP.

Obsługa argumentów przywracania w Azure Blob Storage

Argument Supported Exceptions Comments
DATABASE Yes
LOG Yes
FROM (URL) Yes Argument FROM URL służy do określania ścieżki adresu URL dla pliku kopii zapasowej.
WITH Opcje:
CREDENTIAL Yes WITH CREDENTIAL jest obsługiwana tylko w przypadku korzystania z opcji RESTORE FROM URL do przywracania z 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 Nieobsługiwane w przypadku tworzenia kopii zapasowej migawki
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

Aby uzyskać więcej informacji na temat argumentów przywracania, zobacz instrukcje RESTORE — argumenty.

Tworzenie kopii zapasowej za pomocą programu SSMS

Możesz utworzyć kopię zapasową bazy danych pod adresem URL za pomocą zadania Tworzenie kopii zapasowej w SQL Server Management Studio przy użyciu poświadczeń SQL Server.

Note

Aby utworzyć kopię zapasową migawki plikowej SQL Server lub zastąpić istniejący zestaw nośników, należy użyć Transact-SQL, PowerShell lub C# zamiast zadania tworzenia kopii zapasowej w SQL Server Management Studio.

W poniższych krokach opisano zmiany wprowadzone w zadaniu Tworzenie kopii zapasowej bazy danych w SQL Server Management Studio, aby umożliwić tworzenie kopii zapasowych w magazynie Azure:

  1. W Eksplorator obiektów połącz się z instancją silnika baz danych SQL Server, a następnie rozwiń tę instancję.

  2. Rozwiń węzeł Bazy danych, kliknij prawym przyciskiem myszy żądaną bazę danych, wskaż polecenie Zadania, a następnie wybierz polecenie Utwórz kopię zapasową....

  3. Na stronie Ogólne w sekcji Miejsce docelowe opcja Adres URL jest dostępna na liście rozwijanej Kopia zapasowa do: . Opcja URL jest używana do tworzenia kopii zapasowej do magazynu Azure. Wybierz pozycję Dodaj, a zostanie otwarte okno dialogowe Wybieranie miejsca docelowego kopii zapasowej :

    1. Kontener storage Azure: Nazwa kontenera storage Azure do przechowywania plików kopii zapasowych. Wybierz istniejący kontener z listy rozwijanej lub ręcznie wprowadź kontener.

    2. Zasady dostępu współdzielonego: Wprowadź sygnaturę dostępu współdzielonego dla ręcznie wprowadzonego kontenera. To pole nie jest dostępne, jeśli został wybrany istniejący kontener.

    3. Plik kopii zapasowej: Nazwa pliku kopii zapasowej.

    4. Nowy kontener: Służy do rejestrowania istniejącego kontenera, dla którego nie masz sygnatury dostępu współdzielonego. Zobacz Połączenie z subskrypcją Microsoft Azure (Kopia zapasowa na adres URL).

Note

Funkcja Add obsługuje wiele plików kopii zapasowych i kontenerów pamięci masowej dla jednego zestawu nośników.

Po wybraniu adresu URL jako miejsca docelowego niektóre opcje na stronie Opcje multimediów są wyłączone. Następujące artykuły zawierają więcej informacji na temat okna dialogowego Tworzenie kopii zapasowej bazy danych:

Tworzenie kopii zapasowej za pomocą planu konserwacji

Podobnie jak opisane wcześniej zadanie tworzenia kopii zapasowej, Kreator planu konserwacji w SQL Server Management Studio zawiera URL jako jedną z opcji docelowych oraz inne obiekty pomocnicze wymagane do utworzenia kopii zapasowej do magazynu Azure, takiego jak poświadczenie SQL. Jest on taki sam, aby uzyskać więcej informacji, zobacz sekcję Definiowanie zadań tworzenia kopii zapasowej w Kreatorze korzystania z planu konserwacji.

Note

Aby utworzyć zestaw współdzielonych kopii zapasowych paskowanych, kopię zapasową migawki pliku SQL Server lub poświadczenie SQL przy użyciu tokenu dostępu współdzielonego, należy użyć Transact-SQL, programu PowerShell lub C#, zamiast zadania Tworzenia kopii zapasowej w Kreatorze Planów Konserwacji.

Przywracanie za pomocą programu SSMS

Zadanie Przywracanie bazy danych zawiera adres URL jako urządzenie do przywracania. W poniższych krokach opisano użycie zadania przywracania w celu przywrócenia z Azure Blob Storage.

  1. Kliknij prawym przyciskiem myszy pozycję Bazy danych i wybierz polecenie Przywróć bazę danych....

  2. Na stronie Ogólne wybierz pozycję Urządzenie w sekcji Źródło .

  3. Wybierz przycisk przeglądaj (...), aby otworzyć okno dialogowe Wybieranie urządzeń kopii zapasowej .

  4. Wybierz URL z listy rozwijanej typ nośnika kopii zapasowej. Wybierz pozycję Dodaj , aby otworzyć okno dialogowe Wybieranie lokalizacji pliku kopii zapasowej .

    1. Kontener usługi Azure Storage: w pełni kwalifikowana nazwa kontenera usługi Azure Storage, który zawiera pliki backupu. Wybierz istniejący kontener z listy rozwijanej lub ręcznie wprowadź w pełni kwalifikowaną nazwę kontenera.

    2. Sygnatura dostępu współdzielonego: Służy do wprowadzania sygnatury dostępu współdzielonego dla wyznaczonego kontenera.

    3. Dodawać: Służy do rejestrowania istniejącego kontenera, dla którego nie masz sygnatury dostępu współdzielonego. Zobacz Połączenie z subskrypcją Microsoft Azure (Kopia zapasowa DO adresu URL).

    4. OK: SQL Server nawiązuje połączenie z magazynem Azure przy użyciu podanych informacji o poświadczeniach SQL i otwiera Lokuj plik kopii zapasowej w oknie dialogowym Microsoft Azure. Pliki kopii zapasowej znajdujące się w kontenerze magazynu są wyświetlane na tej stronie. Wybierz plik, którego chcesz użyć do przywrócenia, i wybierz przycisk OK. Spowoduje to powrót do okna dialogowego Wybieranie urządzeń kopii zapasowej i wybranie przycisku OK w tym oknie dialogowym spowoduje powrót do głównego okna dialogowego Przywracanie , w którym można ukończyć przywracanie.

Przykłady kodu

Ta sekcja zawiera następujące przykłady.

Note

Aby zapoznać się z samouczkiem dotyczącym używania SQL Server 2016 z Azure Blob Storage, zobacz Tutorial: use Azure Blob Storage with SQL Server

Tworzenie sygnatury dostępu współdzielonego

Poniższy przykład tworzy sygnatury dostępu współdzielonego, których można użyć do utworzenia SQL Server Credential w nowo utworzonym kontenerze. Skrypt tworzy sygnaturę dostępu współdzielonego skojarzoną z zapisanymi zasadami dostępu. Aby uzyskać więcej informacji, zobacz Sygnatury dostępu współdzielonego, część 1: Zrozumienie modelu SAS. Skrypt zapisuje również polecenie języka T-SQL wymagane do utworzenia poświadczeń na SQL Server.

Note

Przykład wymaga Azure PowerShell. Aby uzyskać informacje na temat instalowania i używania Azure PowerShell, zobacz Jak zainstalować i skonfigurować Azure PowerShell. Te skrypty zostały zweryfikowane przy użyciu Azure PowerShell 5.1.15063.

Sygnatura dostępu współdzielonego skojarzona z zapisanymi zasadami dostępu

# 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

Po pomyślnym uruchomieniu skryptu skopiuj polecenie CREATE CREDENTIAL do narzędzia zapytań, połącz się z wystąpieniem SQL Server i uruchom polecenie, aby utworzyć poświadczenie za pomocą sygnatury dostępu współdzielonego.

Tworzenie poświadczeń

W poniższych przykładach utworzono poświadczenia SQL Server do uwierzytelniania w Azure Blob Storage. Wykonaj jedną z następujących czynności.

  1. Korzystanie z sygnatury dostępu współdzielonego

    Jeśli uruchomisz poprzedni skrypt, aby utworzyć sygnaturę dostępu współdzielonego, skopiuj CREATE CREDENTIAL do edytora zapytań połączonego z wystąpieniem SQL Server i uruchom polecenie .

    Poniższy kod T-SQL jest przykładem tworzenia poświadczeń do używania sygnatury dostępu współdzielonego.

    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. Korzystanie z tożsamości konta magazynowego i klucza dostępu

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

Wykonywanie pełnej kopii zapasowej bazy danych

W poniższych przykładach wykonywana jest pełna kopia zapasowa bazy danych AdventureWorks2025 na Azure Blob Storage. Użyj jednego z następujących przykładów:

  1. Do adresu URL przy użyciu sygnatury dostępu współdzielonego

    BACKUP DATABASE AdventureWorks2022
        TO URL = 'https://<mystorageaccountname>.blob.core.windows.net/<mycontainername>/AdventureWorks2022.bak';
    GO
    
  2. Do adresu URL za pomocą tożsamości konta magazynu i klucza dostępu

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

Przywracanie do punktu w czasie przy użyciu opcji STOPAT

Poniższy przykład przywraca AdventureWorks2025 przykładową bazę danych do stanu w danym momencie i pokazuje operację przywracania.

Z adresu URL przy użyciu sygnatury dostępu współdzielonego

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