Meilleures pratiques et résolution des problèmes liés à la sauvegarde SQL Server sur URL pour le stockage d’objets compatible S3

S’applique à : SQL Server 2022 (16.x)

Cet article décrit les bonnes pratiques et les conseils de dépannage relatifs à la sauvegarde et à la restauration SQL Server dans le stockage d’objets compatible S3.

Pour plus d’informations sur l’utilisation du Stockage Blob Azure pour les opérations de sauvegarde et de restauration SQL Server, consultez :

• Sauvegarde et restauration SQL Server avec le stockage d’objets compatible S3
• Sauvegarde SQL Server vers l’URL pour le stockage d’objets compatible S3

Résolution des problèmes et causes courantes d’erreur

Voici quelques méthodes rapides qui vous aideront à résoudre les erreurs survenant lors de la sauvegarde ou de la restauration depuis le stockage d’objets compatible S3. Pour éviter les erreurs en raison d’options ou de limitations non prises en charge, consultez Sauvegarde et restauration SQL avec stockage d’objets compatible S3.

Vérifier qu’une URL correctement formée existe

Voici un exemple d’URL d’hôte virtuel formée correctement lors de l’émission d’une requête de sauvegarde T-SQL comme suit :

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

Ou pour le style de chemin d’URL :

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

Examinez l’URL :

1. L’URL commence par le schéma s3://.

2. L’hôte virtuel de stockage S3 <virtualHost> ou le domaine de serveur <domainName> existe et s’exécute à l’aide du protocole HTTPS. Le point de terminaison sera validé par une autorité de certification installée sur l’hôte de système d’exploitation SQL Server.

3. <bucketName> est le nom du compartiment dans lequel la sauvegarde est écrite. Cette opération doit être créée avant d’exécuter la sauvegarde T-SQL. La sauvegarde T-SQL ne crée pas le compartiment pour le client. Par exemple, si l’utilisateur ne crée pas le compartiment « nonExistingBucket » au préalable et exécute une instruction T-SQL comme suit :

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

   Une URL qui n’est pas correctement formée peut retourner les éléments suivants :

   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. L’existance de <pathToBackup> n’est pas nécessaire avant d’exécuter la sauvegarde T-SQL. Il est créé automatiquement dans le serveur de stockage. Par exemple, si l’utilisateur crée le compartiment « existingBucket » au préalable et non le chemin d’accès 'existingBucket/sqlbackups', les éléments suivants s’exécutent toujours correctement :

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

Créer des informations d’identification au niveau du serveur avant d’exécuter la sauvegarde/restauration

Avant d’exécuter des requêtes Transact-SQL de sauvegarde/restauration dans un stockage compatible S3, vous devez créer des informations d’identification au niveau du serveur. Ces informations d’identification doivent contenir la clé d’accès et la clé secrète configurées par les clients sur leur serveur de stockage d’objets compatible S3 avant d’émettre des requêtes de sauvegarde/restauration.

Voici un exemple d’informations d’identification qui doivent être créées pour l’URL : s3://<your-endpoint>/myS3Bucket/sqlbackups/AdventureWorks2022.bak :

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

Dans cette instruction <AccessKeyID> n’est pas autorisé à contenir un caractère :. Si les informations d’identification ne sont pas créées avant d’exécuter la requête de sauvegarde/restauration, l’utilisateur voit le message d’erreur suivant :

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.

Le nom des informations d’identification n’est pas requis pour correspondre au chemin exact de l’URL. Voici un exemple de recherche d’informations d’identification. Si nous devons interroger le chemin d’accès s3://10.193.16.183:9000/myS3Bucket/sqlbackups/AdventureWorks2022.bak, les noms d’informations d’identification suivants sont essayés :

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

Si plusieurs informations d’identification correspondent à la recherche, par exemple, plus spécifique s3://10.193.16.183:8787/myS3Bucket/sqlbackups et plus générique s3://10.193.16.183:8787/myS3Bucket, choisissez la recherche la plus spécifique. Cela vous permet de configurer un contrôle d’accès plus granulaire au niveau du répertoire pour les dossiers auxquels vous pouvez accéder à partir de SQL Server.

Option non prise en charge FILE_SNAPSHOT

Actuellement, l’option BACKUP TSQL FILE_SNAPSHOT n’est pas prise en charge pour le stockage d’objets compatible S3. Il s’agit d’une option spécifique à Stockage Blob Azure.

Si l’utilisateur exécute le Transact-SQL suivant, par exemple :

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

Le message d’erreur suivant est retourné :

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.

Frange de sauvegarde supérieure à 100 Go

Actuellement, la taille d’un fichier de sauvegarde unique créé par les clients dans le stockage d’objets compatible S3 pendant une sauvegarde ne peut pas dépasser 100 Go par fichier, à l’aide de la valeur par défaut MAXTRANSFERSIZE. Si la frange de sauvegarde dépasse 100 Go, l’instruction de syntaxe T-SQL de sauvegarde lève le message d’erreur suivant :

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.

Les instructions actuelles relatives aux bases de données volumineuses de sauvegarde de l’utilisateur utilisent plusieurs franges pour la sauvegarde de bases de données, chacune des tailles autorisées inférieures ou égales à 100 Go. Le T-SQL BACKUP prend en charge l’entrelacement jusqu’à 64 URL, par exemple :

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

Une autre option pour les utilisateurs consiste à utiliser l’option « COMPRESSION » :

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

Longueur maximale de l’URL

La longueur totale de l’URL est limitée à 259 octets par le moteur de sauvegarde et de restauration. Cela signifie que s3://hostname/objectkey ne doit pas dépasser 259 caractères. Laisser de côté s3:// permet à l’utilisateur d’entrer la longueur du chemin d’accès (nom d’hôte + clé d’objet) de 259 - 5 = 254 caractères. Reportez-vous à Sauvegarde SQL Server vers l’URL - SQL Server. L’instruction de syntaxe T-SQL de sauvegarde lève le message d’erreur suivant :

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'

Correction d’asymétrie d’horloge

Le stockage S3 peut rejeter la connexion, ce qui renvoie une erreur « InvalidSignatureException » à SQL Server chaque fois que la différence de temps entre l’hôte SQL et le serveur S3 est supérieure à 15 minutes. Sur SQL Server il s’affiche comme suit :

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.

Support SQL Server sur Linux

SQL Server utilise WinHttp pour implémenter le client des API REST HTTP qu’il utilise. Il s’appuie sur le magasin de certificats du système d’exploitation pour la validation des certificats TLS présentés par le point de terminaison HTTP(s). Toutefois, SQL Server sur Linux délègue la validation de certificat à SQLPAL qui valide les certificats HTTPS des points de terminaison avec le certificat fourni avec PAL. Par conséquent, les certificats auto-signés fournis par le client ne peuvent pas être utilisés sur Linux pour la validation HTTPS.

Pendant la sauvegarde/restauration, le client obtient le message d’erreur suivant sur 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.

Pour résoudre ce problème, l’emplacement prédéfini suivant doit être créé : /var/opt/mssql/security/ca-certificates. Placez des certificats auto-signés ou des certificats non fournis avec PAL dans cet emplacement. SQL Server lit les certificats à partir du dossier au démarrage et les ajoute au magasin de confiance PAL.

Jusqu’à 50 fichiers peuvent être stockés à cet emplacement, si le dossier n’est pas créé, lorsque SQL Server est démarré, le journal des erreurs SQL Server s’affiche :

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

Verrou d’objet : la rétention de suppression n’est pas prise en charge

La sauvegarde SQL Server vers la fonctionnalité de stockage d’objets compatible S3 ne prend pas en charge le verrou d’objet, également appelé fonctionnalité de conservation pour la suppression. Le verrou d’objet empêche la suppression ou le remplacement des fichiers pendant la durée de sa période de rétention.

L’emplacement du compartiment et du dossier ciblé par votre opération de sauvegarde ne doit pas avoir le verrou d’objet activé. Si cette fonctionnalité est activée et configurée dans votre stockage d’objets compatible S3, l’opération de sauvegarde échoue avec le message suivant :

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.

Contenu connexe

• Sauvegarde et restauration SQL Server avec le stockage d’objets compatible S3
• Sauvegarde SQL Server vers l’URL pour le stockage d’objets compatible S3
• BACKUP (Transact-SQL)
• RESTORE (Transact-SQL)