Dela via


Metodtips för SQL Server-säkerhetskopiering till URL för S3-kompatibel objektlagring och felsökning

gäller för: SQL Server 2022 (16.x)

Den här artikeln innehåller metodtips och felsökningstips för säkerhetskopiering och återställning av SQL Server till S3-kompatibel objektlagring.

Mer information om hur du använder Azure Blob Storage för säkerhetskopiering eller återställning av SQL Server finns i:

Felsökning och vanliga felorsaker

Följande är några snabba sätt att felsöka fel när du säkerhetskopierar till eller återställer från den S3-kompatibla objektlagringen. Information om hur du undviker fel på grund av alternativ eller begränsningar som inte stöds finns i SQL Backup and Restore with S3-compatible object storage.

Se till att url:en är korrekt utformad

Här är ett exempel på en virtuell värd-URL som skapas korrekt när du utfärdar en T-SQL-säkerhetskopieringsfråga, till exempel följande:

BACKUP DATABASE AdventureWorks2022
TO URL = 's3://<bucketName>.<virtualHost>/<pathToBackup>/<backupFileName>' 

Eller för URL-sökvägsformat:

BACKUP DATABASE AdventureWorks2022
TO URL = 's3://<domainName>/<bucketName>/<pathToBackup>/<backupFileName>';

Granska i URL:en:

  1. URL:en börjar med s3:// schema.

  2. Det finns en S3-värd för lagring <virtualHost> eller en serverdomän <domainName> som körs med HTTPS. Slutpunkten verifieras av en CA som är installerad på SQL Server OS-värd.

  3. <bucketName> är namnet på den här bucketen där säkerhetskopian skrivs. Detta måste skapas innan du kör T-SQL-säkerhetskopieringen. Säkerhetskopieringen av T-SQL skapar inte bucketen för kunden. Om användaren till exempel inte skapar bucketen "nonExistingBucket" i förväg och kör en T-SQL-instruktion på följande sätt:

    BACKUP DATABASE AdventureWorks2022
    TO URL = 's3://<your-endpoint>/nonExistingBucket/AdventureWorks2022.bak';
    

    En URL som inte är korrekt utformad kan returnera följande:

    Msg 3201, Level 16, State 1, Line 50
    Cannot open backup device 's3://<your-endpoint>/nonExistingBucket/AdventureWorks2022.bak'. Operating system error 50(The request is not supported.).
    Msg 3013, Level 16, State 1, Line 50
    BACKUP DATABASE is terminating abnormally.
    
  4. <pathToBackup> behöver inte finnas innan du kör T-SQL-säkerhetskopieringen. Den skapas automatiskt på lagringsservern. Om användaren till exempel skapar bucketen "existingBucket" i förväg och inte sökvägen 'existingBucket/sqlbackups', kommer följande ändå att köras framgångsrikt.

BACKUP DATABASE AdventureWorks2022
TO URL =  's3://<your-endpoint>/existingBucket/sqlbackups/AdventureWorks2022.bak';

Skapa en autentiseringsuppgift på servernivå innan du kör säkerhetskopiering/återställning

Innan du kör säkerhetskopierings-/återställningsförfrågningar Transact-SQL mot S3-kompatibel lagring måste du skapa en behörighet på servernivå. Den här autentiseringsuppgiften måste innehålla åtkomstnyckeln och hemlighetsnyckeln som har konfigurerats av kunder på deras S3-kompatibla objektlagringsserver innan du skickar säkerhetskopierings-/återställningsfrågor.

Ett exempel på en autentiseringsuppgift som måste skapas för URL: s3://<your-endpoint>/myS3Bucket/sqlbackups/AdventureWorks2022.bak skulle vara följande:

CREATE CREDENTIAL [s3://<your-endpoint>/myS3Bucket/sqlbackups/AdventureWorks2022.bak]
WITH IDENTITY = 'S3 Access Key',
SECRET = '<AccessKeyID>:<SecretKeyID>';

I den här instruktionen får <AccessKeyID> inte innehålla ett : tecken. Om autentiseringsuppgifterna inte skapas innan du kör frågan om säkerhetskopiering/återställning visas följande felmeddelande:

Msg 3201, Level 16, State 1, Line 50
Cannot open backup device 's3://<your-endpoint>/myS3Bucket/sqlbackups/AdventureWorks2022.bak'. Operating system error 50(The request is not supported.).
Msg 3013, Level 16, State 1, Line 50
BACKUP DATABASE is terminating abnormally.

Namnet på autentiseringsuppgifterna krävs inte för att matcha den exakta URL-sökvägen. Här är ett exempel på hur sökning efter autentiseringsuppgifter fungerar. Om vi behöver söka i sökvägen s3://10.193.16.183:9000/myS3Bucket/sqlbackups/AdventureWorks2022.bakprovas följande namn på referenser:

  1. s3://10.193.16.183:8787/myS3Bucket/sqlbackups/AdventureWorks2022.bak
  2. s3://10.193.16.183:8787/myS3Bucket/sqlbackups
  3. s3://10.193.16.183:8787/myS3Bucket

Om det finns flera autentiseringsuppgifter som matchar sökningen, till exempel mer specifika s3://10.193.16.183:8787/myS3Bucket/sqlbackups och mer allmänna s3://10.193.16.183:8787/myS3Bucket, väljer du den mest specifika. På så sätt kan du konfigurera mer detaljerad åtkomstkontroll på katalognivå för vilka mappar som kan nås från SQL Server.

Alternativet stöds inte FILE_SNAPSHOT

För närvarande stöds inte alternativet BACKUP TSQL FILE_SNAPSHOT för S3-kompatibel objektlagring. Det här är ett Azure Blob Storage-specifikt alternativ.

Om användaren kör följande Transact-SQL till exempel:

BACKUP DATABASE AdventureWorks2022
TO URL = 's3://<your-endpoint>/myS3Bucket/sqlbackups/AdventureWorks2022.bak'
WITH FILE_SNAPSHOT;

Följande felmeddelande returneras:

Msg 3073, Level 16, State 1, Line 62
The option WITH FILE_SNAPSHOT is only permitted if all database files are in Azure Storage.
Msg 3013, Level 16, State 1, Line 62
BACKUP DATABASE is terminating abnormally.

Säkerhetskopieringsremsan överstiger 100 GB

För närvarande får storleken på en enskild säkerhetskopieringsfil som skapats av kunder i S3-kompatibel objektlagring under en säkerhetskopia inte överstiga 100 GB per fil, med standard MAXTRANSFERSIZE. Om säkerhetskopieringsremsan överskrider 100 GB genererar instruktionen för T-SQL-syntax för säkerhetskopiering följande felmeddelande:

Msg 3202, Level 16, State 1, Line 161
Write on 's3://<endpoint>:<port>/<bucket>/<path>/<db_name>.bak' failed: 87(The parameter is incorrect.)
Msg 3013, Level 16, State 1, Line 161
BACKUP DATABASE is terminating abnormally.

Den aktuella vägledningen för användarens säkerhetskopiering av stora databaser är att använda flera ränder för databassäkerhetskopian, var och en av tillåtna storlekar som är mindre än eller lika med 100 GB. Backup T-SQL stöder striping av upp till 64 URL:er, till exempel:

BACKUP DATABASE AdventureWorks2022
TO URL = 's3://<endpoint>:<port>/<bucket>/<path>/<db_file>_1.bak',
URL = 's3://<endpoint>:<port>/<bucket>/<path>/<db_file>_2.bak';

Ett annat alternativ för användare är att använda 'KOMPRIMERING'-alternativet.

BACKUP DATABASE AdventureWorks2022
TO URL = 's3://<your-endpoint>/myS3Bucket/sqlbackups/AdventureWorks2022.bak'
WITH COMPRESSION;

Maximal längd på URL

Den totala URL-längden är begränsad till 259 byte av motorn för säkerhetskopiering och återställning. Det innebär att s3://hostname/objectkey inte får överstiga 259 tecken. Om du bortser från s3:// kan användaren ange sökvägens längd (värdnamn + objektnyckel) till 259–5 = 254 tecken. Se SQL Server-säkerhetskopiering till URL – SQL Server. Instruktionen för T-SQL-syntax för säkerhetskopiering genererar följande felmeddelande:

SQL Server has a maximum limit of 259 characters for a backup device name. The BACKUP TO URL consumes 36 characters for the required elements used to specify the URL - 'https://.blob.core.windows.net//.bak', leaving 223 characters for account, container, and blob names put together'

Korrigering av klockförskjutning

S3-lagringen kan avvisa anslutningen, vilket ger ett "InvalidSignatureException"-fel tillbaka till SQL Server när tidsskillnaden mellan SQL Host och S3-servern är större än 15 minuter. På SQL Server visas den som:

Msg 3201, Level 16, State 1, Line 28
Cannot open backup device '<path>'. Operating system error 5(Access is denied.).
Msg 3013, Level 16, State 1, Line 28
BACKUP DATABASE is terminating abnormally.

Stöd för SQL Server på Linux

SQL Server använder WinHttp för att implementera klienten för HTTP REST-API:er som används. Det förlitar sig på OS-certifikatarkivet för valideringar av TLS-certifikaten som presenteras av HTTP-slutpunkten. SQL Server på Linux delegerar dock certifikatverifieringen till SQLPAL, som validerar slutpunkternas HTTPS-certifikat med certifikatet som levereras med PAL. Därför kan inte självsignerade certifikat som tillhandahålls av kunden användas i Linux för HTTPS-validering.

Under säkerhetskopiering/återställning får kunden följande felmeddelande i Linux:

Msg 3201, Level 16, State 1, Line 20
Cannot open backup device 's3://<endpoint>/<bucket>/testingDB.bak'. Operating system error 12175(failed to retrieve text for this error. Reason: 15105).
Msg 3013, Level 16, State 1, Line 20
BACKUP DATABASE is terminating abnormally.

För att komma förbi det här problemet måste följande fördefinierade plats skapas: /var/opt/mssql/security/ca-certificates. Placera självsignerade certifikat eller certifikat som inte levereras med PAL på den här platsen. SQL Server läser certifikaten från mappen under starten och lägger till dem i PAL-förtroendearkivet.

Upp till 50 filer kan lagras på den här platsen om mappen inte har skapats. När SQL Server startas visas SQL Server-felloggen:

2022-02-05 00:32:10.86 Server      Installing Client TLS certificates to the store.
2022-02-05 00:32:10.88 Server      Error searching first file in /var/opt/mssql/security/ca-certificates: 3(The system cannot find the path specified.)

Objektlås – behållande av raderingsfunktion stöds inte

Sql Server-säkerhetskopiering till S3-kompatibel objektlagringsfunktion stöder inte objektlås, även kallat funktionen Ta bort kvarhållning. Object Lock förhindrar att filer tas bort eller skrivs över under kvarhållningsperioden.

Den bucket- och mappplats som säkerhetskopieringen riktar in sig på får inte ha Objektlås aktiverat. Om den här funktionen är aktiverad och konfigurerad i din S3-kompatibla objektlagring misslyckas säkerhetskopieringen med följande meddelande:

Msg 3202, Level 16, State 1, Line 13
Write on 's3://<your-endpoint>/nonExistingBucket/AdventureWorks2022.bak' failed: 87 (The parameter is incorrect).
Msg 3013, Level 16, State 1, Line 13
BACKUP DATABASE is terminating abnormally.