Megosztás a következőn keresztül:


SQL Server biztonsági mentés URL-címre Azure Blob Storage-hoz

A következőre vonatkozik: :SQL ServerAzure SQL Managed Instance

Ez a cikk bemutatja a Azure Blob Storage biztonsági mentési célként való használatához szükséges fogalmakat, követelményeket és összetevőket. A biztonsági mentési és visszaállítási funkció ugyanolyan vagy hasonló, mint amikor DISK vagy TAPE használnak, néhány különbséggel. Ezek a különbségek és néhány példakód szerepel ebben a cikkben.

Tip

A 2025-ös SQL Server (17.x) verziótól kezdve biztonsági másolatot készíthet az URL-címről felügyelt identitással. Tekintse át a URL-re történő biztonsági mentést felügyelt identitással (előzetes verzió) – Azure Arc által engedélyezett SQL Server.

Overview

SQL Server 2012 Service Pack 1 CU2 és SQL Server 2014 lehetővé tette, hogy biztonsági másolatot készítsen a Azure Blob Storage mutatott URL-címről, a már ismert T-SQL-szintaxissal biztonságosan írhat biztonsági másolatokat Azure tárolóba. SQL Server 2016 (13.x) bevezette az Azure adatbázisfájlok File-Snapshot biztonsági mentéseit és a közös hozzáférésű aláírási (SAS) kulcsokat, egy biztonságos és egyszerű módszert az Azure Storage biztonsági szabályzatának hitelesítésére.

Fontos tisztában lenni az összetevőkkel és a köztük lévő interakcióval, hogy biztonsági másolatot készítsen a Azure Blob Storage biztonsági mentéséről vagy visszaállításáról.

A folyamat első lépése egy Azure Storage-fiók létrehozása az Azure-előfizetésben. Ez a tárfiók egy rendszergazdai fiók, amely teljes körű rendszergazdai engedélyekkel rendelkezik a tárfiókkal létrehozott összes tárolóra és objektumra. SQL Server használhatja a Azure tárfiók nevét és hozzáférési kulcsértékét a blobok hitelesítésére és írására és olvasására Azure Blob Storage, vagy használhat egy meghatározott tárolókon létrehozott közös hozzáférésű jogosultságkód-jogkivonatot, amely olvasási és írási jogosultságot biztosít. A Azure Storage Accounts kapcsolatos további információkért lásd: Az Azure Storage Accounts és a közös hozzáférésű jogosultságkódokkal kapcsolatos további információkért lásd: A megosztott hozzáférésű jogosultságkódok, 1. rész: Az SAS-modell ismertetése. A SQL Server hitelesítő adatok tárolják ezeket a hitelesítési információkat, és a biztonsági mentési vagy visszaállítási műveletek során használják.

Azure Storage és S3-kompatibilis tároló

SQL Server 2022 (16.x) lehetővé teszi a biztonsági mentések S3-kompatibilis objektumtárolóba való írását, a biztonsági mentési és visszaállítási funkciók pedig elméletileg hasonlóak a biztonsági mentés URL-címhez való használatához, Azure Blob Storage biztonsági mentési eszköztípusként. SQL Server 2022 (16.x) kibővíti a BACKUP/RESTORE TO/FROM URL szintaxist egy új S3-összekötő REST API-val való támogatásának hozzáadásával.

Ez a cikk információkat tartalmaz az Azure Blob Storage-hoz tartozó Backup to URL szolgáltatás használatáról. Az S3-kompatibilis tárolók URL-címére történő biztonsági mentésről további információért tekintse meg az SQL Server biztonsági mentés URL-címre S3-kompatibilis objektumtároló című dokumentumot.

Biztonsági mentés Azure Storage blokkblobra és lapblobra

A blobok kétféleképpen tárolhatók Azure Blob Storage: blokk- és oldalblobok. A 2016-os és újabb SQL Server előnyben részesíti a blokkblobot.

Ha a hitelesítő adatokban a tárkulcsot használják, akkor lap blobot használ a rendszer; ha megosztott hozzáférési jogosultságkódot használnak, akkor blokk blobot alkalmaznak.

A block blob típusú biztonsági mentés csak a 2016-os vagy újabb SQL Server verzióban érhető el az Azure Blob Storage-hoz történő biztonsági mentés céljából. Ha a 2016-os vagy újabb SQL Server verziót használja, készítsen biztonsági mentést blokkblobra lapblob helyett.

A fő okok a következők:

  • A közös hozzáférésű jogosultságkód biztonságosabb módszer a blobok hozzáférésének engedélyezésére a tárkulcshoz képest.
  • Több blokkblobról is készíthet biztonsági másolatot a jobb biztonsági mentés és a teljesítmény visszaállítása érdekében, valamint támogathatja a nagyobb adatbázis-biztonsági mentést.
  • A blokkblob olcsóbb, mint az oldalblob.
  • Azoknak az ügyfeleknek, akiknek proxykiszolgálón keresztül kell biztonsági másolatot készíteniük a lapblobokról, a backuptourl.exe-t kell használniuk.

A nagyméretű adatbázisok Azure Blob Storage történő biztonsági mentésére a Azure SQL Managed Instance T-SQL-különbségek, korlátozások és ismert problémák felsorolt korlátozások vonatkoznak.

Ha az adatbázis túl nagy, akkor a következő lehetőségek állnak fenn:

  • Használjon biztonsági mentési tömörítést vagy
  • Biztonsági mentés több blokk-blobhoz

Azure Arc által lehetővé tett támogatás Linuxon, tárolókon és SQL Managed Instance esetén

Ha a SQL Server-példány Linuxon van üzemeltetve, beleértve a következőket:

  • Önálló operációs rendszer
  • Containers
  • Azure Arc által támogatott SQL Managed Instance
  • Bármely más Linux-alapú környezet

A Azure Blob Storage egyetlen támogatott biztonsági mentése a blobok blokkolása a közös hozzáférésű jogosultságkód használatával.

Azure Blob Storage

Tárfiók: A tárfiók az összes tárolási szolgáltatás kiindulópontja. A Azure Blob Storage eléréséhez először hozzon létre egy Azure tárfiókot. További információ: Tárfiók létrehozása

Konténer: A tároló blobok egy csoportját biztosítja, és korlátlan számú blobot tárolhat. Ahhoz, hogy SQL Server biztonsági másolatot írjon az Azure Blob Storage-ba, legalább a gyökértárolót létre kell hoznia. Létrehozhat egy megosztott hozzáférésű jogosultságkód-jogkivonatot egy tárolón, és csak egy adott tároló objektumaihoz adhat hozzáférést.

Blob: Bármilyen típusú és méretű fájl. A blobok kétféleképpen tárolhatók Azure Blob Storage: blokk- és oldalblobok. SQL Server biztonsági mentés a használt Transact-SQL szintaxistól függően bármelyik blobtípust használhatja. A blobok a következő URL-címformátummal címezhetők: https://< storage account.blob.core.windows.net/>< container>/<blob>. A Azure Blob Storage további információ: Bevezetés Azure Blob Storage. A lap- és blokkblobokról további információt a Blokk és a Lapblobok ismertetése című témakörben talál.

Diagram az Azure Blob Storage fiókokról, tárolókról és blobokról.

Azure Snapshot: Pillanatkép egy adott időpontban készített Azure blobról. További információt a Blob pillanatképének létrehozása című témakörben talál. SQL Server biztonsági mentés mostantól támogatja az Azure Blob Storage-ban tárolt adatbázisfájlok pillanatkép mentését. További információ: File-Snapshot Biztonsági másolatok adatbázisfájlokhoz Azure.

SQL Server összetevők

URL-cím: Az URL-cím egy egységes erőforrás-azonosítót (URI) ad meg egy egyedi biztonsági mentési fájlhoz. Az URL-cím a SQL Server biztonsági mentési fájl helyének és nevének megadására szolgál. Az URL-címnek egy tényleges blobra kell mutatnia, nem csak egy tárolóra. Ha a blob nem létezik, létrejön. Ha egy meglévő blob van megadva, BACKUP sikertelen lesz, kivéve, ha a WITH FORMAT beállítás a blob meglévő biztonsági mentési fájljának felülírására van megadva.

Íme egy minta URL-érték: https://ACCOUNTNAME.blob.core.windows.net/<CONTAINER>/FILENAME.bak.

Note

A HTTP használatával történő URL-alapú biztonsági mentés nem támogatott.

Credential: A SQL Server hitelesítő adatok olyan objektumok, amelyek a SQL Server kívüli erőforráshoz való csatlakozáshoz szükséges hitelesítési adatok tárolására szolgálnak. Itt SQL Server biztonsági mentési és visszaállítási folyamatok hitelesítő adatokat használnak a Azure Blob Storage, valamint a tároló- és blobobjektumok hitelesítéséhez. A hitelesítő adatok a tárfiók nevét és a tárfiók hozzáférési kulcsértékeit , vagy a tároló URL-címét és a közös hozzáférésű jogosultságkód jogkivonatát tárolják. A hitelesítő adatok létrehozása után az utasítások szintaxisa BACKUP/RESTORE határozza meg a blob típusát és a szükséges hitelesítő adatokat.

A megosztott hozzáférési aláírás létrehozásának példáit lásd a cikk későbbi részében, itt: Közös hozzáférési aláírás létrehozása. A SQL Server hitelesítő adatok létrehozásának példáit szintén a cikk későbbi részében találja, itt: A hitelesítő adatok létrehozása.

További információ a hitelesítő adatokról: Credentials (Database Engine).

A hitelesítő adatok használatára vonatkozó egyéb példákkal kapcsolatban lásd: A SQL Server Agent proxy létrehozása.

Azure nem módosítható tárterület támogatása

SQL Server 2025 (17.x) támogatja a Azure nem módosítható tárolást, amely védelmet nyújt a ransomware támadások ellen. A nem módosítható tárterületre írt fájlok nem módosíthatók vagy törölhetők, az megváltoztathatatlanság által meghatározott módon.

Általában SQL Server biztonsági másolatok két lépésben jönnek létre. A biztonsági mentési fájl kezdetben .bak nullákkal jön létre, majd a fájl adatokkal frissül. Mivel a nem módosítható tároló fájlmódosítása nem engedélyezett a fájl megírása és véglegesítése után, a biztonsági mentési folyamat most kihagyja a kezdeti lépést a biztonsági mentési fájl nullákkal való létrehozásához. Ehelyett a teljes biztonsági mentés egy lépésben jön létre, amikor blokkblobokhoz íródik.

Azure tároló kétféle nem módosíthatóságot, tárolószintet és verziószintet biztosít. Jelenleg csak a tárolószintű nem módosítható tárolók támogatottak.

Ha változatlan tárolót szeretne használni az SQL Server 2025 (17.x) URL-címre történő mentése esetén, kövesse az alábbi lépéseket:

  1. Konfigurálja az Azure tároló módosíthatatlanságát.

  2. A BACKUP kiadásával biztonsági másolatot készít az adatbázisról a Azure tárolóba. Ha a nem módosítható tárterületen használja a WITH FORMAT beállítást, és egy biztonsági mentés már létezik ugyanazzal a névvel, hibaüzenet jelenik meg, és a biztonsági mentés sikertelen lesz.

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

A Azure Blob Storage biztonsága

Az alábbiakban biztonsági szempontokat és követelményeket kell figyelembe venni, amikor biztonsági másolatot készítünk a Azure Blob Storage biztonsági mentéséről vagy visszaállításáról.

  • Ha tárolót hoz létre Azure Blob Storage számára, javasoljuk, hogy állítsa be a hozzáférést private. A privát hozzáférés beállítása korlátozza a hozzáférést a felhasználókhoz vagy fiókokhoz, amelyek képesek megadni a Azure-fiók hitelesítéséhez szükséges információkat.

    Important

    SQL Server megköveteli, hogy egy Azure fióknév és hozzáférési kulcs hitelesítése, vagy a közös hozzáférésű jogosultságkód és hozzáférési jogkivonat egy SQL Server hitelesítő adatban legyen tárolva. Ezek az információk a biztonsági mentési vagy visszaállítási műveletek végrehajtásakor a Azure fiók hitelesítésére szolgálnak.

    Warning

    Azure Storage támogatja a tárfiók megosztott kulcsának tiltását. Ha a megosztott kulcs engedélyezése le van tiltva, SQL Server biztonsági mentés URL-címe nem fog működni.

  • A BACKUP vagy RESTORE parancsok kiadására használt felhasználói fióknak az db_backup operátor adatbázis-szerepkörében kell lennie, és rendelkeznie kell a bármelyik hitelesítő adat módosítása engedélyekkel.

A Azure Blob Storage biztonsági mentésének/visszaállításának korlátozásai

  • SQL Server a lapblobok által támogatott biztonsági mentés maximális méretét 1 TB-ra korlátozza. A blokkblobokkal támogatott biztonsági mentés maximális mérete körülbelül 195,3 GB (50 000 blokk * 4 MB MAXTRANSFERSIZE). A blokkblobok támogatják a csíkozást a lényegesen nagyobb biztonsági mentési méretek támogatásához – a korlát legfeljebb 64 URL-cím, ami a következő képletet eredményezi: 64 stripes * 50,000 blocks * 4MB maxtransfersize = 12.8 TB.

    Important

    Bár az egyetlen blokkblob által támogatott maximális biztonsági mentési méret körülbelül 195,3 GB, lehetséges, hogy SQL Server kisebb blokkméretekben ír, ami azt eredményezheti, hogy SQL Server eléri az 50 000 blokkkorlátot a teljes biztonsági mentés átvitele előtt. A blokkkorlát elkerülése érdekében csíkozza a biztonsági másolatokat (még akkor is, ha 200 GB-nál kisebbek), különösen, ha különbségi vagy tömörítetlen biztonsági másolatokat használ.

  • A tranzakciónapló biztonsági mentései figyelmen kívül hagyják a felhasználó által megadott MAXTRANSFERSIZE értéket, amikor több biztonsági mentési fájlba készítenek biztonsági másolatot. Ehelyett 64 KB-ot használ, ha több fájl van megadva, függetlenül a MAXTRANSFERSIZE biztonsági mentési parancs értékétől. Ezért a tranzakciónapló URL-címre történő biztonsági mentésének maximális mérete körülbelül 195,3 GB (50 000 blokk * 4 MB MAXTRANSFERSIZE * 1 fájl VAGY 50 000 blokk * 64 KB * 64 fájl). A tömörítés lehetővé teszi egy nagyobb tranzakciónapló biztonsági mentését, de a tömörítési arányok eltérőek lesznek.

  • Biztonsági mentési vagy visszaállítási utasításokat Transact-SQL, SMO, PowerShell-parancsmagok vagy a SQL Server Management Studio Biztonsági mentés vagy visszaállítás varázslóval adhat ki.

  • Ha Azure Storage fiókról készít biztonsági másolatot, SQL Server csak a közös hozzáférésű jogosultságkóddal (SAS) rendelkező jogkivonatokkal vagy tárfiókkulcsokkal történő hitelesítést támogatja. Az összes többi hitelesítési módszer, beleértve a Microsoft Entra ID (formerly Azure Active Directory) hitelesítést is, nem támogatott.

  • Logikai eszköznév létrehozása nem támogatott. Ezért az URL-cím biztonsági mentési eszközként való hozzáadása sp_dumpdevice vagy SQL Server Management Studio használatával nem támogatott.

  • A meglévő biztonsági mentési blobokhoz való hozzáfűzés nem támogatott. Egy meglévő blob biztonsági mentései csak a WITH FORMAT beállítással írhatók felül. Ha azonban fájl-pillanatkép biztonsági mentést használ (az WITH FILE_SNAPSHOT argumentum használatával), az WITH FORMAT argumentum nem teszi lehetővé az árva fájl-pillanatképek elhagyását, amelyeket az eredeti fájl-pillanatkép biztonsági mentésével hoztak létre.

  • Egyetlen biztonsági mentési műveletben több blobra történő biztonsági mentés csak blokkblobok és közös hozzáférésű jogosultságkód (SAS) jogkivonat használatával támogatott az SQL Credential tárfiókkulcsa helyett.

  • A lapblobok BLOCKSIZE megadása nem támogatott.

  • A MAXTRANSFERSIZE beállítása nincs támogatva lapblobok esetén.

  • A biztonsági másolatkészlet beállításainak megadása – RETAINDAYS és EXPIREDATE nem támogatottak.

  • SQL Server legfeljebb 259 karakter hosszúságú lehet a biztonsági mentési eszköz neve. A BACKUP TO URL rendszer 36 karaktert használ az URL-cím https://.blob.core.windows.net//.bakmegadásához szükséges elemekhez, így a fiók, a tároló és a blobnevek 223 karaktert tartalmaznak.

  • SQL Server 2019-es (15.x) és korábbi verziókban a közös hozzáférésű jogosultságkód (SAS) jogkivonatok legfeljebb 256 karakter hosszúságúak lehetnek, ami korlátozza a használható jogkivonatok típusát (például a felhasználói delegálási kulcs jogkivonatai nem támogatottak).

  • Ha a kiszolgáló egy proxykiszolgálón keresztül fér hozzá az Azure-hoz, használja a 1819-es nyomkövető jelzőt, majd állítsa be a WinHTTP proxykonfigurációt az alábbi módszerek egyikével:

    • A proxycfg.exe segédprogram a Windows XP vagy a Windows Server 2003 és korábbi verziókon.
    • A netsh.exe segédprogram Windows Vista és 2008-Windows Server vagy újabb verziókon.
  • Az Azure Blob Storage változtathatatlan tárhelye SQL Server 2025 előtt nem támogatott. Állítsa a nem módosítható tárolási házirendet hamisra.

  • A SQL Server 2025-ös és újabb verziók támogatása: Azure nem módosítható tárterület támogatása.

    • Azure tároló kétféle nem módosíthatóságot, tárolószintet és verziószintet biztosít. Jelenleg csak a tárolószintű nem módosítható tárolók támogatottak.
  • Az URL-címre történő biztonsági mentés nem támogatott a prémium szintű tárterületen.

Támogatott argumentumok és utasítások a Azure Blob Storage

Az Azure Blob Storage támogatása a biztonsági mentési/visszaállítási utasításokhoz

Biztonsági mentési/visszaállítási utasítás Supported Exceptions Comments
BACKUP Yes BLOCKSIZE és MAXTRANSFERSIZE támogatottak blokkblobok esetében. Nincsenek támogatva a lapblobok esetében. BACKUP blokkblobhoz szükséges egy megosztott hozzáférési aláírás, amely SQL Server hitelesítő adatokban van tárolva. BACKUP a lapblobhoz a tárolófiók kulcsát menteni kell egy SQL Server hitelesítő adatként, és meg kell adnia a WITH CREDENTIAL argumentumot.
RESTORE Yes Meg kell határozni egy SQL Server hitelesítő adatot, és meg kell adni a WITH CREDENTIAL argumentumot, ha a SQL Server hitelesítő adat a tárfiókkulcsot használja titkos kulcsként
RESTORE FILELISTONLY Yes Meg kell határozni egy SQL Server hitelesítő adatot, és meg kell adni a WITH CREDENTIAL argumentumot, ha a SQL Server hitelesítő adat a tárfiókkulcsot használja titkos kulcsként
RESTORE HEADERONLY Yes Meg kell határozni egy SQL Server hitelesítő adatot, és meg kell adni a WITH CREDENTIAL argumentumot, ha a SQL Server hitelesítő adat a tárfiókkulcsot használja titkos kulcsként
RESTORE LABELONLY Yes Meg kell határozni egy SQL Server hitelesítő adatot, és meg kell adni a WITH CREDENTIAL argumentumot, ha a SQL Server hitelesítő adat a tárfiókkulcsot használja titkos kulcsként
RESTORE VERIFYONLY Yes Meg kell határozni egy SQL Server hitelesítő adatot, és meg kell adni a WITH CREDENTIAL argumentumot, ha a SQL Server hitelesítő adat a tárfiókkulcsot használja titkos kulcsként
RESTORE REWINDONLY No

A biztonsági mentési utasítások szintaxisát és általános információiért lásd: BACKUP.

A visszaállítási utasításokkal kapcsolatos szintaxist és általános információkat a VISSZAÁLLÍTÁSi utasítások című témakörben talál.

Biztonsági mentési argumentumok támogatása a Azure Blob Storage

Argument Supported Exception Comments
DATABASE Yes
LOG Yes
TO (URL) Yes DISK és TAPE ellentétben az URL nem támogatja a logikai név megadását vagy létrehozását. Ezzel az argumentumpal adhatja meg a biztonsági mentési fájl URL-elérési útját.
MIRROR TO Yes
WITH beállítások:
CREDENTIAL Yes WITH CREDENTIAL csak akkor támogatott, ha BACKUP TO URL lehetőséget használ az Azure Blob Storage biztonsági mentéséhez, és csak akkor, ha a SQL Server hitelesítő adat a tárfiók kulcsával van definiálva titkos kulcsként
FILE_SNAPSHOT Yes
ENCRYPTION Yes A WITH ENCRYPTION argumentum megadásakor az SQL Server fájlpillanat mentés biztosítja, hogy a teljes adatbázis TDE-titkosítással legyen titkosítva a biztonsági mentés megkezdése előtt, és ha igen, a fájlpillanat mentési fájlt az adatbázisban megadott TDE-algoritmussal titkosítja. Ha a teljes adatbázis adatbázisának összes adata nincs titkosítva, a biztonsági mentés meghiúsul (például a titkosítási folyamat még nem fejeződött be).
DIFFERENTIAL Yes
COPY_ONLY Yes
COMPRESSION|NO_COMPRESSION Yes A fájl-pillanatkép biztonsági mentése nem támogatott
DESCRIPTION Yes
NAME Yes
EXPIREDATE | RETAINDAYS No
NOINIT | INIT No A blobokhoz való hozzáfűzés nem lehetséges. A biztonsági mentés felülírásához használja az argumentumot WITH FORMAT . Ha azonban fájl-pillanatkép biztonsági mentést használ (az WITH FILE_SNAPSHOT argumentum használatával), az WITH FORMAT argumentum nem kerülheti el az eredeti biztonsági mentéssel létrehozott árva fájl-pillanatképek elhagyását.
NOSKIP | SKIP No
NOFORMAT | FORMAT Yes A meglévő blobra készített biztonsági mentés sikertelen, hacsak nincs WITH FORMAT megadva. A meglévő blob felülíródik, ha WITH FORMAT meg van adva. Ha azonban fájl-pillanatkép biztonsági mentést használ (az WITH FILE_SNAPSHOT argumentum használatával), az FORMAT argumentum nem teszi lehetővé az árva fájl-pillanatképek elhagyását, amelyeket az eredeti fájl-pillanatkép biztonsági mentésével hoztak létre. Ha azonban fájl-pillanatkép biztonsági mentést használ (az WITH FILE_SNAPSHOT argumentum használatával), az WITH FORMAT argumentum nem kerülheti el az eredeti biztonsági mentéssel létrehozott árva fájl-pillanatképek elhagyását.
MEDIADESCRIPTION Yes
MEDIANAME Yes
BLOCKSIZE Yes A lapblobok nem támogatottak. A blokktárolók (block blob) esetében támogatott. Javasoljuk BLOCKSIZE=65536 , hogy optimalizálja a blokkblobban engedélyezett 50 000 blokk kihasználását.
BUFFERCOUNT Yes
MAXTRANSFERSIZE Yes A lapblobok nem támogatottak. A blokktárolók (block blob) esetében támogatott. Az alapértelmezett érték a 1048576. Az érték legfeljebb 4 MB lehet 65 536 bájtos növekményekben.

Javasoljuk MAXTRANSFERSIZE=4194304 , hogy optimalizálja a blokkblobban engedélyezett 50 000 blokk kihasználását.
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

A biztonsági mentés argumentumairól további információt a BACKUP című témakörben talál.

A visszaállítási argumentumok támogatása a Azure Blob Storage

Argument Supported Exceptions Comments
DATABASE Yes
LOG Yes
FROM (URL) Yes Az FROM URL argumentum a biztonsági mentési fájl URL-címének megadására szolgál.
WITH beállítások:
CREDENTIAL Yes WITH CREDENTIAL csak akkor támogatott, ha a RESTORE FROM URL beállítást használja az Azure Blob Storage-ból való visszaállításhoz.
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 A pillanatképek biztonsági mentése nem támogatott
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

A visszaállítási argumentumokról további információt a VISSZAÁLLÍTÁSi utasítások – Argumentumok című témakörben talál.

Biztonsági mentés az SSMS-sel

Az adatbázist egy URL-címre mentheti a Biztonsági mentési művelet használatával az SQL Server Management Studio-ban egy SQL Server hitelesítő adatot használva.

Note

SQL Server fájl-pillanatkép biztonsági mentés létrehozásához vagy meglévő médiakészlet felülírásához Transact-SQL-t, PowerShell-t vagy C#-ot kell használnia, ahelyett hogy a SQL Server Management Studio biztonsági mentési feladatát használná.

Az alábbi lépések a biztonsági mentési adatbázis feladatának SQL Server Management Studio módosításait ismertetik, amelyek lehetővé teszik a biztonsági mentést Azure tárterületre:

  1. Az Object Explorer-ben csatlakozzon a SQL Server Database Engine egy példányához, majd bontsa ki a példányt.

  2. Bontsa ki az Adatbázisok elemet, kattintson a jobb gombbal a kívánt adatbázisra, mutasson a Feladatok pontra, majd válassza a Biztonsági mentés... lehetőséget.

  3. A Általános lap Cél szakaszában az URL opció a Biztonsági mentés legördülő listában érhető el. A URL beállítással biztonsági másolatot készíthet Azure tárterületről. Válassza a Hozzáadás lehetőséget, és megnyílik a Biztonsági mentési cél kiválasztása párbeszédpanel:

    1. Azure tároló: A biztonsági mentési fájlok tárolására szolgáló Azure tároló neve. Válasszon ki egy meglévő tárolót a legördülő listából, vagy adja meg manuálisan a tárolót.

    2. Megosztott hozzáférési szabályzat: Adja meg a megosztott hozzáférésű jogosultságkódot egy manuálisan beírt tárolóhoz. Ez a mező nem érhető el, ha egy meglévő tárolót választottak.

    3. Biztonsági mentési fájl: A biztonsági mentési fájl neve.

    4. Új tároló: Olyan meglévő tároló regisztrálására szolgál, amelyhez nem rendelkezik közös hozzáférésű jogosultságkóddal. Lásd: Csatlakozás Microsoft Azure-előfizetéshez (Backup TO URL).

Note

A Hozzáadás több biztonsági mentési fájlt és tárolót támogat egyetlen médiakészlethez.

Ha az URL-címet választja célként, a Médiabeállítások lapon bizonyos beállítások le lesznek tiltva. Az alábbi cikkek további információt tartalmaznak a Biztonsági mentési adatbázis párbeszédpanelről:

Biztonsági mentés karbantartási tervvel támogatva

A korábban ismertetett biztonsági mentési feladathoz hasonlóan a karbantartási tervvarázsló az SQL Server Management Studio-ban tartalmazza az URL-t, mint célbeállítási lehetőséget, valamint az Azure tárolóra, például az SQL Credentialt, való biztonsági mentéshez szükséges egyéb támogató objektumokat. Azonos funkcióval rendelkezik. További információért nézze meg a Biztonsági mentési feladatok definiálása szakaszt a Karbantartási terv varázsló használata című részben.

Note

Csíkozott biztonsági másolatkészlet, SQL Server fájl-pillanatkép biztonsági mentése, vagy megosztott hozzáférési jogkivonat használatával SQL-azonosító adatok létrehozásához a Karbantartási terv varázsló Biztonsági mentési feladata helyett Transact-SQL, PowerShell vagy C# nyelvet kell használnia.

Visszaállítás SSMS-sel

A visszaállítási adatbázis-feladat url-címet tartalmaz, amelyről vissza lehet állítani. A következő lépések ismertetik, hogyan használhatjuk a visszaállítási feladatot az Azure Blob Storage-ból történő visszaállításhoz:

  1. Kattintson a jobb gombbal az Adatbázisok elemre, és válassza az Adatbázis visszaállítása... lehetőséget.

  2. Az Általános lapon válassza az Eszköz lehetőséget a Forrás szakaszban.

  3. A Tallózás (...) gombra kattintva nyissa meg a Biztonsági mentési eszközök kiválasztása párbeszédpanelt.

  4. Válassza ki az URL-címet a Biztonsági mentés adathordozótípus: legördülő listából. Válassza a Hozzáadás lehetőséget a Biztonsági mentési fájl helyének kiválasztása párbeszédpanel megnyitásához.

    1. Azure tároló: A biztonsági mentési fájlokat tartalmazó Azure tároló teljes neve. Válasszon ki egy meglévő tárolót a legördülő listából, vagy adja meg manuálisan a teljes tárolónevet.

    2. Közös hozzáférésű jogosultságkód: A kijelölt tároló közös hozzáférésű jogosultságkódjának megadására szolgál.

    3. Hozzáad: Olyan meglévő tároló regisztrálására szolgál, amelyhez nem rendelkezik közös hozzáférésű jogosultságkóddal. Lásd: Csatlakozás Microsoft Azure-előfizetéshez (Backup TO URL).

    4. OK: SQL Server a megadott SQL Hitelesítő adatok használatával csatlakozik Azure tárolóhoz, és megnyitja a Biztonsági mentési fájl áthelyezése Microsoft Azure párbeszédpanelen. Ezen a lapon megjelennek a tárolóban található biztonsági mentési fájlok. Jelölje ki a visszaállítani kívánt fájlt, és válassza az OK gombot. Ezzel visszakerül a Biztonsági mentési eszközök kiválasztása párbeszédpanelre, és a párbeszédpanelen az OK gombra kattintva visszakerül a fő visszaállítási párbeszédpanelre, ahol elvégezheti a visszaállítást.

Példakódok

Ez a szakasz az alábbi példákat tartalmazza.

Note

A SQL Server 2016 és az Azure Blob Storage együttes használatának oktatóanyagáért lásd: Oktatóanyag: Azure Blob Storage használata a SQL Serverrel

Közös hozzáférésű jogosultságkód létrehozása

Az alábbi példa közös hozzáférésű jogosultságkódokat hoz létre, amelyekkel létrehozhat SQL Server hitelesítő adatokat egy újonnan létrehozott tárolón. A szkript létrehoz egy megosztott hozzáférésű jogosultságkódot, amely egy tárolt hozzáférési szabályzathoz van társítva. További információ: Közös hozzáférésű jogosultságkódok, 1. rész: Az SAS-modell ismertetése. A szkript a hitelesítő adatok létrehozásához szükséges T-SQL-parancsot is megírja SQL Server.

Note

A példához Azure PowerShell szükséges. A Azure PowerShell telepítésével és használatával kapcsolatos információkért lásd: Az Azure PowerShell. Ezek a szkriptek az 5.1.15063-Azure PowerShell használatával lettek ellenőrizve.

Tárolt hozzáférési szabályzathoz társított közös hozzáférésű jogosultságkód

# 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

A szkript sikeres futtatása után másolja a CREATE CREDENTIAL parancsot egy lekérdezési eszközre, csatlakozzon a SQL Server egy példányához, és futtassa a parancsot a hitelesítő adatok közös hozzáférésű jogosultságkóddal való létrehozásához.

Hitelesítő adatok létrehozása

Az alábbi példák SQL Server hitelesítő adatokat hoznak létre Azure Blob Storage hitelesítéshez. Tegye az alábbiak egyikét.

  1. Közös hozzáférésű jogosultságkód használata

    Ha az előző szkriptet futtatta a közös hozzáférésű jogosultságkód létrehozásához, másolja a CREATE CREDENTIAL a SQL Server példányához csatlakoztatott lekérdezésszerkesztőbe, és futtassa a parancsot.

    A következő T-SQL egy példa, amely létrehozza a hitelesítő adatokat a közös hozzáférésű jogosultságkód használatához.

    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. Tárfiók identitásának és hozzáférési kulcsának használata

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

Teljes adatbázis biztonsági mentésének végrehajtása

Az alábbi példák a AdventureWorks2025 adatbázis teljes adatbázis-biztonsági mentését hajtják végre a Azure Blob Storage. Használja az alábbi minták egyikét:

  1. URL megosztott hozzáférési aláírással

    BACKUP DATABASE AdventureWorks2022
        TO URL = 'https://<mystorageaccountname>.blob.core.windows.net/<mycontainername>/AdventureWorks2022.bak';
    GO
    
  2. URL-cím a tárfiók identitásával és hozzáférési kulcsával

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

Időponthoz kötött visszaállítás a STOPAT használatával

Az alábbi példa egy időpontban állítja vissza a AdventureWorks2025 mintaadatbázis állapotát, és egy visszaállítási műveletet mutat be.

URL-címről megosztott hozzáférési aláírás használatával

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