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


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

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

Ez a cikk az Azure Blob Storage biztonsági mentési célként való használatához szükséges fogalmakat, követelményeket és összetevőket ismerteti. 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

Az SQL Server 2025-től kezdve (17.x) URL-címre készíthet biztonsági másolatot felügyelt identitással. Tekintse át a felügyelt identitással (előzetes verzió) rendelkező URL-címre való biztonsági mentést – az Azure Arc által engedélyezett SQL Servert.

Overview

Az SQL Server 2012 Service Pack 1 CU2 és az SQL Server 2014 lehetővé tette, hogy biztonsági másolatot készítsen az Azure Blob Storage-ra mutató URL-címről, a már ismert T-SQL-szintaxis használatával biztonságosan írhat biztonsági másolatokat az Azure Storage-ba. Az SQL Server 2016 (13.x)File-Snapshot Biztonsági másolatokat vezetett be az Azure-beli adatbázisfájlokhoz , valamint a közös hozzáférésű aláírási (SAS) kulcsok használatával történő biztonsági mentést, amely biztonságos és egyszerű módszer a tanúsítványok Azure Storage-beli biztonsági szabályzatba való 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 az Azure Blob Storage-ról, vagy visszaállítsa őket.

A folyamat első lépéseként hozzon létre egy Azure Storage-fiókot az Azure-előfizetésében. 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. Az SQL Server használhatja az Azure Storage-fiók nevét és hozzáférési kulcsértékét a blobok Azure Blob Storage-ba való hitelesítéséhez és írásához és olvasásához, 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. Az Azure Storage-fiókokról további információt az Azure Storage-fiókokról és a közös hozzáférésű jogosultságkódokról szóló, 1. rész: Az SAS-modell ismertetése című témakörben talál. Az SQL Server hitelesítő adatai tárolják ezeket a hitelesítési adatokat, é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ó

Az 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 ahhoz, hogy az Azure Blob Storage-t biztonsági mentési eszköztípusként használja az URL-címre történő biztonsági mentéshez. Az SQL Server 2022 (16.x) kibővíti a BACKUP/RESTORE TO/FROM URL szintaxist úgy, hogy támogatást ad egy új S3-összekötőhöz a REST API használatával.

Ez a cikk információkat nyújt az Azure Blob Storage URL-re történő biztonsági mentéséről. Az S3-kompatibilis tárolók URL-címére történő biztonsági mentésről további információt az SQL Server S3-kompatibilis objektumtároló URL-címére való biztonsági mentésében talál.

Biztonsági mentés az Azure Storage blokkblobjára vagy lapblobjára

Az Azure Blob Storage-ban kétféle blob tárolható: blokk- és lapblobok. Az SQL Server 2016-os és újabb verziói esetében a blokkblob használata javasolt.

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 blobok blokkolására szolgáló biztonsági mentés csak az SQL Server 2016-os vagy újabb verziójában érhető el az Azure Blob Storage-ba történő biztonsági mentéshez. Ha SQL Server 2016-ot vagy újabb verziót futtat, készítsen biztonsági mentést blokkblobba a 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 nagy adatbázisok Azure Blob Storage-ba történő biztonsági mentésére az Azure SQL Managed Instance T-SQL-eltéréseiben felsorolt korlátozások, korlátozások és ismert problémák 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

Támogatás Linux, tárolók és felügyelt SQL-példányok esetében az Azure Arc által engedélyezve

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

  • Önálló operációs rendszer
  • Containers
  • Az Azure Arc által engedélyezett felügyelt SQL-példány
  • Bármely más Linux-alapú környezet

Az Azure Blob Storage URL-címére történő egyetlen támogatott biztonsági mentés 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. Az Azure Blob Storage eléréséhez először hozzon létre egy Azure Storage-fió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. Ha SQL Server-biztonsági másolatot szeretne írni az Azure Blob Storage-ba, létre kell hoznia legalább a gyökértárolót. 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. Az Azure Blob Storage-ban kétféle blob tárolható: blokk- és lapblobok. Az SQL Server biztonsági mentése 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>. További információ az Azure Blob Storage-ról: Bevezetés az Azure Blob Storage használatába. A lap- és blokkblobokról további információt a Blokk és a Lapblobok ismertetése című témakörben talál.

Az Azure Blob Storage-fiókok, -tárolók és blobok diagramja.

Azure Snapshot: Pillanatkép egy adott időpontban készült Azure-blobról. További információt a Blob pillanatképének létrehozása című témakörben talál. Az SQL Server biztonsági mentése mostantól támogatja az Azure Blob Storage-ban tárolt adatbázisfájlok Azure-pillanatkép-biztonsági mentését. További információ: File-Snapshot Biztonsági másolatok adatbázisfájlokhoz az 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 az SQL Server biztonsági mentési fájljának 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.

Megbízólevél: Az SQL Server-hitelesítő adatok olyan objektumok, amelyek az SQL Serveren kívüli erőforráshoz való csatlakozáshoz szükséges hitelesítési információk tárolására szolgálnak. Itt az SQL Server biztonsági mentési és visszaállítási folyamatai hitelesítő adatokat használnak az Azure Blob Storage- és 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ésű jogosultságkódok létrehozásáról példákat talál a cikk későbbi részében, a megosztott hozzáférésű jogosultságkódok létrehozása szakaszban, és az SQL Server hitelesítő adatok létrehozásáról a hitelesítő adatok létrehozása szakaszban talál példákat.

A hitelesítő adatokról további információt a Hitelesítő adatok (adatbázismotor) című témakörben talál.

A hitelesítő adatokat tartalmazó egyéb példákról az SQL Server-ügynökproxy létrehozása című témakörben talál további információt.

Az Azure nem módosítható tárolási támogatása

Az SQL Server 2025 (17.x) támogatja az Azure nem módosítható tárterületét, 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.

Az SQL Server biztonsági másolatai általában 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.

Ha nem módosítható tárolót szeretne használni az SQL Server 2025 (17.x) URL-címére történő biztonsági mentéssel, kövesse az alábbi lépéseket:

  1. Az Azure Storage-tároló nem módosíthatóságának konfigurálása.

  2. Adja ki a biztonsági mentést az adatbázis Azure Storage-tárolóba való biztonsági mentéséhez. 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>';
    

Az Azure Blob Storage biztonsága

Az alábbiakban biztonsági szempontokat és követelményeket kell figyelembe venni az Azure Blob Storage-ra való biztonsági mentéskor vagy az Azure Blob Storage-ból való visszaállításkor.

  • Az Azure Blob Storage tárolójának létrehozásakor javasoljuk, hogy állítsa be a privát hozzáférését. A privát hozzáférés beállítása korlátozza azon felhasználók vagy fiókok hozzáférését, amelyek képesek megadni az Azure-fiók hitelesítéséhez szükséges információkat.

    Important

    Az SQL Server megköveteli, hogy egy Azure-fióknév és hozzáférési kulcs hitelesítése, vagy egy 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 az Azure-fiók hitelesítésére szolgálnak.

    Warning

    Az Azure Storage támogatja a megosztott kulcs engedélyezésének letiltását egy tárfiók esetében. Ha a megosztott kulcs engedélyezése le van tiltva, az SQL Server biztonsági mentésének 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.

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

  • Az SQL Server 1 TB méretre korlátozza a biztonsági mentések támogatott maximális méretét lapblob használata esetén. A blokkblobokkal támogatott biztonsági mentés maximális mérete körülbelül 200 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 200 GB, az SQL Server kisebb blokkméretekben írhat, ami azt eredményezheti, hogy az 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.

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

  • Azure Storage-fiókra való biztonsági mentéskor az 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. Minden más hitelesítési módszer, beleértve a Microsoft Entra-azonosítóval (korábban Azure Active Directory) történő hitelesítést is, nem támogatott.

  • Logikai eszköznév létrehozása nem támogatott. Ezért az URL-cím nem adható hozzá biztonsági mentési eszközként, sem sp_dumpdevice-on keresztül, sem az SQL Server Management Studio használatával, mivel 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.

  • Az SQL Server legfeljebb 259 karakter hosszúságú lehet egy biztonsági mentési eszköz nevére vonatkozóan. 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.

  • Az SQL Server 2019 (15.x) és a korábbi verziók legfeljebb 256 karakter hosszúságúak a közös hozzáférésű jogosultságkód (SAS) jogkivonatok esetében, 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ó proxykiszolgálón keresztül fér hozzá az Azure-hoz, használja az 1819 nyomkövetési jelzőt, majd állítsa be a WinHTTP proxykonfigurációt az alábbi módszerek egyikével:

    • A proxycfg.exe segédprogram Windows XP vagy Windows Server 2003 és korábbi rendszereken.
    • A netsh.exe segédprogram Windows Vista és Windows Server 2008 vagy újabb rendszereken.
  • Az Azure Blob Storage nem módosítható tárolója nem támogatott. Állítsa a nem módosítható tárolási házirendet hamisra.

  • 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 az Azure Blob Storage-ban

Biztonsági mentési/visszaállítási utasítások támogatása az Azure Blob Storage-ban

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 sql serveres hitelesítő adatokban mentett közös hozzáférésű jogosultságkód szükséges. BACKUP a lapblobhoz az SQL Server hitelesítő adataiban mentett tárfiókkulcs szükséges, és meg kell adni az WITH CREDENTIAL argumentumot.
RESTORE Yes Meg kell határozni egy SQL Server-hitelesítő adatot, és meg kell adni az WITH CREDENTIAL argumentumot, ha az 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 az WITH CREDENTIAL argumentumot, ha az 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 az WITH CREDENTIAL argumentumot, ha az 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 az WITH CREDENTIAL argumentumot, ha az 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 az WITH CREDENTIAL argumentumot, ha az 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 az Azure Blob Storage-ban

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 az Azure Blob Storage-ra való biztonsági mentési lehetőséget használja BACKUP TO URL, és ha az SQL Server hitelesítő adatot a tárfiók kulcsával titkos kulcsként definiálják.
FILE_SNAPSHOT Yes
ENCRYPTION Yes Az argumentum megadásakor az WITH ENCRYPTION SQL Server File-Snapshot Backup biztosítja, hogy a teljes adatbázis TDE-titkosítással legyen titkosítva a biztonsági mentés előtt, és ha igen, titkosítja magát a fájl-pillanatkép biztonsági mentési fájlt az adatbázis TDE-hez megadott algoritmusával. 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.

Visszaállítási argumentumok támogatása az Azure Blob Storage-ban

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 az Azure Blob Storage-ból való visszaállítási lehetőséget használja RESTORE FROM URL .
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 SQL Server Management Studio biztonsági mentési feladatán keresztül egy SQL Server Credential használatával biztonsági másolatot készíthet az adatbázis URL-címére.

Note

Sql Server-fájl-pillanatkép biztonsági mentéséhez vagy meglévő médiakészlet felülírásához a Transact-SQL, a PowerShell vagy a C# parancsot kell használnia az SQL Server Management Studio Biztonsági mentési feladata helyett.

Az alábbi lépések az SQL Server Management Studióban a biztonsági mentési adatbázis feladatának módosításait ismertetik, amelyek lehetővé teszik az Azure Storage-ra való biztonsági mentést:

  1. Az Object Explorer-ben csatlakozzon az SQL Server adatbázismotor 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. Az URL-beállítással biztonsági másolatot hozhat létre az Azure Storage-ba. 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 Storage-tároló: A biztonsági mentési fájlok tárolására szolgáló Azure Storage-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 az SQL Server Management Studio Karbantartási terv varázslója url-címet is tartalmaz a célbeállítások egyikeként, valamint az Azure Storage-ra való biztonsági mentéshez szükséges egyéb támogató objektumokat, például az SQL Credentialt. 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

Sávos biztonsági mentési készlet, SQL Server-fájl-pillanatkép biztonsági mentése vagy SQL-hitelesítő adatok közös hozzáférésű jogkivonat használatával történő létrehozásához a Karbantartási terv varázsló Biztonsági mentés feladata helyett a Transact-SQL, a PowerShell vagy a C# parancsot 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. Az alábbi lépések az Azure Blob Storage-ból való visszaállítást ismertetik a visszaállítási feladat segítségével:

  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 Storage-tároló: A biztonsági mentési fájlokat tartalmazó Azure Storage-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É: Az SQL Server a megadott SQL Hitelesítő adatokkal csatlakozik az Azure Storage-hoz, és megnyitja a Biztonsági mentési fájl megkeresése párbeszédpanelt a Microsoft Azure-ban . 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

Az SQL Server 2016 Azure Blob Storage-tal való használatáról a következő oktatóanyagban olvashat: Az Azure Blob Storage használata az 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 SQL Server-hitelesítő adatokat hozhat létre 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 SQL Serveren való létrehozásához szükséges T-SQL-parancsot is megírja.

Note

A példához az Azure PowerShell szükséges. Az Azure PowerShell telepítésével és használatával kapcsolatos információkért tekintse meg az Azure PowerShell telepítését és konfigurálását ismertető témakört. Ezeket a szkripteket az Azure PowerShell 5.1.15063 használatával ellenőriztük.

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 egy SQL Server-példányhoz, é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 az Azure Blob Storage-ba történő 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 parancsot az SQL Server-példányhoz 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 az adatbázis teljes adatbázis-biztonsági mentését hajtják végre az AdventureWorks2025 Azure Blob Storage-ba. 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