Best Practices und Problembehandlung für SQL Server-Sicherungsvorgänge über URLs für S3-kompatiblen Objektspeicher

  • Artikel

Gilt für: SQL Server 2022 (16.x)

Dieser Artikel beschreibt Best Practices und Tipps zur Problembehandlung für SQL Server-Sicherungs- und -Wiederherstellungsvorgänge in S3-kompatiblem Objektspeicher.

Weitere Informationen zur Verwendung von Azure Blob Storage für SQL Server-Sicherungs- oder -Wiederherstellungsvorgänge finden Sie hier:

Problembehandlung und häufige Fehlerursachen

Im Folgenden finden Sie einige schnelle Lösungen zur Behebung von Sicherungs- und Wiederherstellungsfehlern in S3-kompatiblem Objektspeicher. Informationen zum Vermeiden von Fehlern aufgrund nicht unterstützter Optionen oder Einschränkungen finden Sie unter SQL Backup and Restore mit S3-kompatiblem Objektspeicher.

Stellen Sie sicher, dass eine ordnungsgemäß formatierte URL vorhanden ist.

Nachfolgend finden Sie ein Beispiel für eine virtuelle Host-URL, die beim Ausgeben einer T-SQL-Sicherungsabfrage ordnungsgemäß formatiert wurde:

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

Im URL-Pfadformat:

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

Überprüfen Sie die URL:

  1. Die URL beginnt mit dem Schema s3://.

  2. Der virtuelle Host <virtualHost> oder die Serverdomäne <domainName> für den S3-Speicher ist vorhanden und wird mit HTTPS ausgeführt. Der Endpunkt wird anhand einer Zertifizierungsstelle überprüft, die auf dem SQL Server-Betriebssystemhost installiert ist.

  3. <bucketName> ist der Name dieses Buckets, in dem die Sicherung geschrieben wird. Dieser muss erstellt werden, bevor die T-SQL-Anweisung für die Sicherung ausgeführt wird. Die T-SQL-Anweisung für die Sicherung erstellt den Bucket für den Kunden nicht. Ein Beispiel: Ein Benutzer erstellt den Bucket „nonExistingBucket“ vorher nicht und führt eine T-SQL-Anweisung wie die folgende:

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

    Eine nicht ordnungsgemäß formatierte URL gibt möglicherweise Folgendes zurück:

    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. Der <pathToBackup> muss vor dem Ausführen der T-SQL-Sicherungsanweisung nicht vorhanden sein. Sie wird automatisch auf dem Speicherserver erstellt. Wenn der Benutzer den Bucket „existingBucket“ vorher erstellt, nicht aber den Pfad 'existingBucket/sqlbackups', wird Folgendes dennoch erfolgreich ausgeführt:

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

Erstellen von Anmeldeinformationen auf Serverebene vor dem Ausführen der Sicherung/Wiederherstellung

Vor dem Ausführen von Transact-SQL-Abfragen auf S3-kompatiblem Speicher müssen Sie eine Anmeldeinformationen auf Serverebene erstellen. Diese Anmeldeinformationen müssen den Zugriffsschlüssel und geheimen Schlüssel enthalten, der von Kunden auf ihrem S3-kompatiblen Objektspeicherserver eingerichtet wurde, bevor Sicherungs-/Wiederherstellungsabfragen ausgestellt werden.

Hier ein Beispiel für Anmeldeinformationen, die für die URL s3://<your-endpoint>/myS3Bucket/sqlbackups/AdventureWorks2022.bak erstellt werden müssen:

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

In dieser Anweisung darf <AccessKeyID> kein :-Zeichen enthalten. Wenn die Anmeldeinformationen vor dem Ausführen der Sicherungs-/Wiederherstellungsabfrage nicht erstellt werden, wird dem Benutzer die folgende Fehlermeldung angezeigt:

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.

Der Name der Anmeldeinformationen muss nicht genau mit dem URL-Pfad übereinstimmen. Hier sehen Sie ein Beispiel, wie Lookupvorgänge für Anmeldeinformationen funktionieren. Wenn wir den Pfad s3://10.193.16.183:9000/myS3Bucket/sqlbackups/AdventureWorks2022.bakabfragen müssen, werden die folgenden Anmeldeinformationsnamen ausprobiert:

  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

Wenn die Suche nach mehreren Anmeldeinformationen übereinstimmen soll, z. B. spezifischer und allgemeiners3://10.193.16.183:8787/myS3Bucket, wählen Sie die spezifischste s3://10.193.16.183:8787/myS3Bucket/sqlbackups aus. Auf diese Weise können Sie eine differenziertere Zugriffssteuerung auf Verzeichnisebene für die Ordner einrichten, auf die über SQL Server zugegriffen werden kann.

Nicht unterstützte Option FILE_SNAPSHOT

Derzeit wird die BACKUP-TSQL-Option FILE_SNAPSHOT für den S3-kompatiblen Objektspeicher nicht unterstützt. Dies ist eine Azure Blob Storage-spezifische Option.

Wenn der Benutzer beispielsweise den folgenden Transact-SQL-Code ausführt:

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

Die folgende Fehlermeldung wird zurückgegeben:

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.

Sicherungsstreifen größer als 100 GB

Derzeit kann die Größe einer einzelnen Sicherungsdatei, die von Kunden im S3-kompatiblen Objektspeicher während einer Sicherung erstellt wurde, 100 GB pro Datei nicht überschreiten, wobei die Standardeinstellung MAXTRANSFERSIZEverwendet wird. Wenn der Sicherungsstreifen über 100 GB hinausgeht, löst die T-SQL-Sicherungssyntax-Anweisung die folgende Fehlermeldung aus:

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.

Die aktuelle Anleitung für die Sicherung großer Datenbanken des Benutzers verwendet mehrere Streifen für die Datenbanksicherung, wobei jede zulässige Größe kleiner oder gleich 100 GB ist. Die T-SQL-Anweisung BACKUP unterstützt das Striping von bis zu 64 URLs, z. B.:

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

Eine alternative Option für Benutzer besteht darin, die Option COMPRESSION zu verwenden:

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

Maximale Länge der URLs

Die Gesamtlänge von URLs ist durch die Backup- und Wiederherstellungs-Engine auf 259 Byte beschränkt. Das bedeutet, dass s3://hostname/objectkey 259 Zeichen nicht überschreiten darf. Abgesehen von s3:// können Benutzer Pfade (Hostname + Objektschlüssel) mit einer Länge von 259 - 5 = 254 Zeichen eingeben. Mehr dazu erfahren Sie unter SQL Server-Sicherung über URLs – SQL Server. Die T-SQL-Syntax-Anweisung für die Sicherung löst die folgende Fehlermeldung aus:

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'

Korrektur von Uhrabweichungen

Wenn der Zeitunterschied zwischen SQL-Host und S3-Server größer ist als 15 Minuten, kann der S3-Speicher die Verbindung ablehnen und den Fehler „InvalidSignatureException“ an SQL Server zurückgeben. Auf SQL Server wird folgendes angezeigt:

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.

Unterstützung für SQL Server für Linux

SQL Server verwendet WinHttp, um den Client von genutzten HTTP-REST-APIs zu implementieren. Es basiert auf dem Zertifikatspeicher des Betriebssystems für überprüfungen der TLS-Zertifikate, die vom HTTP(s)-Endpunkt angezeigt werden. SQL Server für Linux delegiert jedoch die Zertifikatüberprüfung an SQLPAL, wodurch die HTTPS-Zertifikate der Endpunkte mit dem Zertifikat überprüft werden, das mit PAL ausgeliefert wurde. Daher können selbstsignierte Zertifikate von Kunden für die HTTPS-Validierung unter Linux nicht verwendet werden.

Während der Sicherung/Wiederherstellung erhält der Kunde die folgende Fehlermeldung unter 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.

Um dieses Problem zu umgehen, muss der folgende vordefinierte Speicherort erstellt werden: /var/opt/mssql/security/ca-certificates. Platzieren Sie selbstsignierte Zertifikate oder Zertifikate, die nicht an diesem Standort mit PAL ausgeliefert wurden. SQL Server liest die Zertifikate aus dem Ordner während des Starts und fügt sie dem PAL-Vertrauensspeicher hinzu.

An diesem Speicherort können bis zu 50 Dateien gespeichert werden. Wenn der Ordner beim Start von SQL Server noch nicht erstellt wurde, zeigt das SQL Server-Fehlerprotokoll Folgendes an:

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.)

Objektsperre – Die Löschaufbewahrung wird nicht unterstützt.

Die SQL Server-Sicherung auf S3-kompatible Objektspeicherfunktion unterstützt die Objektsperre nicht, auch als Löschaufbewahrungsfunktion bezeichnet. Die Objektsperre verhindert, dass Dateien für die Dauer des Aufbewahrungszeitraums gelöscht oder überschrieben werden.

Der Bucket- und Ordnerspeicherort, der von Ihrem Sicherungsvorgang bestimmt ist, darf die Objektsperre nicht aktiviert sein. Wenn dieses Feature in Ihrem S3-kompatiblen Objektspeicher aktiviert und konfiguriert ist, schlägt der Sicherungsvorgang mit der folgenden Meldung fehl:

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.

Zugehöriger Inhalt