Freigeben über

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 Sichern und Wiederherstellen 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 in der 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 platziert 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. Er wird auf dem Speicherserver automatisch 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

Bevor Sie Transact-SQL-Abfragen zur Sicherung/Wiederherstellung für S3-kompatiblen Speicher ausführen, müssen Sie Anmeldeinformationen auf Serverebene erstellen. Diese Anmeldeinformationen müssen den Zugriffsschlüssel und den geheimen Schlüssel enthalten, die von Kunden auf ihrem S3-kompatiblen Objektspeicherserver eingerichtet wurden, bevor Sicherungs-/Wiederherstellungsabfragen ausgegeben 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 Sie den Pfad s3://10.193.16.183:9000/myS3Bucket/sqlbackups/AdventureWorks2022.bak abfragen müssen, werden die folgenden Namen von Anmeldeinformationen versucht:

  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 mehrere Anmeldeinformationen der Suche entsprechen, z. B. die spezifischeren Informationen s3://10.193.16.183:8787/myS3Bucket/sqlbackups und die allgemeineren Informationen s3://10.193.16.183:8787/myS3Bucket, wählen Sie die spezifischsten aus. Damit können Sie auf Verzeichnisebene eine detailliertere Zugriffskontrolle dafür einrichten, zu welchen Ordnern Sie vom SQL Server aus Zugang haben.

Nicht unterstützte Option FILE_SNAPSHOT

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

Ein Beispiel: Der Benutzer führt die folgende Transact-SQL-Anweisung aus:

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.

Sicherungs-Bereichsstreifen überschreitet 100 GB

Derzeit darf die Größe einer einzelnen Sicherungsdatei, die von Kunden in S3-konformem Objektspeicher erstellt wird, während einer Sicherung 100 GB nicht übersteigen. Dabei wird standardmäßig MAXTRANSFERSIZE verwendet. Wenn der Sicherungs-Bereichsstreifen 100 GB überschreitet, löst die Transact-SQL-Syntaxanweisung für die Sicherung 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 Empfehlung für die Sicherung großer Datenbanken von Benutzern lautet, mehrere Bereichsstreifen für die Datenbanksicherung zu verwenden, deren 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-Syntaxanweisung 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. In SQL Server wird dies wie folgt 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. Dies basiert auf dem Zertifikatsspeicher des Betriebssystems für Überprüfungen der TLS-Zertifikate, die vom HTTP(S)-Endpunkt präsentiert werden. SQL Server für Linux dagegen delegiert die Zertifikatüberprüfung an SQLPAL. Dieser Mechanismus überprüft die HTTPS-Zertifikate der Endpunkte anhand des mit PAL gelieferten Zertifikats. 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 in Linux die folgende Fehlermeldung:

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. Der SQL Server liest beim Start die Zertifikate aus dem Ordner 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, die auch Löschaufbewahrungsfunktion genannt wird, nicht. Die Objektsperre verhindert, dass Dateien für die Dauer des Aufbewahrungszeitraums gelöscht oder überschrieben werden.

Für den Bucket und den Speicherort des Ordners, den Sie sichern möchten, darf die Objektsperre nicht aktiviert sein. Wenn diese Funktion 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