Meilleures pratiques et dépannage de sauvegarde SQL Server vers une URL

Article
03/06/2017

Cette rubrique présente des bonnes pratiques et des conseils de dépannage pour la sauvegarde et la restauration SQL Server dans le service Blob Azure.

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

Sauvegarde et restauration SQL Server avec le service Stockage Blob Microsoft Azure
Tutoriel : Sauvegarde et restauration SQL Server avec le service Stockage Blob Azure

Gestion des sauvegardes

La liste suivante comprend des recommandations générales sur la gestion des sauvegardes :

Nous vous recommandons d'utiliser un nom de fichier unique pour chaque sauvegarde afin d'éviter tout remplacement accidentel des objets blob.
Lors de la création d'un conteneur, nous vous recommandons de configurer le niveau d'accès sur Privé, afin que seuls les utilisateurs ou comptes qui peuvent fournir les informations d'identification requises puissent lire ou écrire les objets blob dans le conteneur.
Pour les bases de données SQL Server qui se trouvent sur une instance de SQL Server s’exécutant sur une machine virtuelle Azure, utilisez un compte de stockage qui se trouve dans la même région que la machine virtuelle, afin d’éviter les coûts de transfert des données entre les régions. L'utilisation de la même région garantit également des performances optimales pour les opérations de sauvegarde et de restauration.
L'échec d'une activité de sauvegarde peut générer un fichier de sauvegarde non valide. Nous vous recommandons d'identifier périodiquement les sauvegardes en échec et de supprimer les fichiers d'objets blob. Pour plus d'informations, consultez Deleting Backup Blob Files with Active Leases
L'utilisation de WITH COMPRESSION pendant la sauvegarde peut réduire les coûts du stockage et des transactions de stockage. Elle peut également réduire le temps nécessaire pour terminer le processus de sauvegarde.

Gestion des fichiers volumineux

L’opération de sauvegarde SQL Server utilise plusieurs threads pour optimiser le transfert de données vers les services de stockage Blob Azure. Toutefois, les performances dépendent de divers facteurs, tels que la bande passante de l'éditeur de logiciels et la taille de la base de données. Si vous envisagez de sauvegarder des bases de données ou groupes de fichiers volumineux à partir d'une base de données SQL Server locale, nous vous recommandons de commencer par tester le débit. Les contrats SLA de stockage Azure ont des durées de traitement maximales pour les objets blob que vous pouvez prendre en compte.
L'utilisation de l'option WITH COMPRESSION, comme recommandé dans la section Gestion de la sauvegarde, est très importante lors de la sauvegarde de fichiers volumineux.

Dépannage des problèmes de sauvegarde vers une URL ou de restauration depuis une URL

Voici quelques méthodes rapides qui vous aideront à résoudre les erreurs survenant lors de la sauvegarde ou de la restauration vers/depuis le service de stockage Blob Azure.

Pour éviter les erreurs dues à des options ou limitations non prises en charge, consultez la liste des limitations et la prise en charge des informations sur les commandes BACKUP et RESTORE dans l’article Sauvegarde et restauration SQL Server avec Stockage Blob Azure Service.

Erreurs d'authentification :

WITH CREDENTIAL est une nouvelle option qui est nécessaire pour effectuer une sauvegarde ou une restauration à partir du service de stockage Blob Azure. Les défaillances liées aux informations d'identification peuvent être les suivantes :

Les informations d'identification spécifiées dans la commande BACKUP ou RESTORE n'existent pas. Pour éviter ce problème, vous pouvez inclure des instructions T-SQL afin de créer les informations d'identification si elles n'existent pas dans l'instruction de sauvegarde. Voici un exemple que vous pouvez utiliser :
```
IF NOT EXISTS  
(SELECT * FROM sys.credentials   
WHERE credential_identity = 'mycredential')  
CREATE CREDENTIAL <credential name> WITH IDENTITY = 'mystorageaccount'  
,SECRET = '<storage access key> ;  
```
Les informations d'identification existent, mais le compte de connexion utilisé pour exécuter la commande de sauvegarde ne dispose pas des autorisations appropriées pour accéder aux informations d'identification. Utilisez un compte de connexion dans le rôle db_backupoperator avec des autorisations Modifier des informations d’identification .
Vérifiez le nom du compte de stockage et la valeur des clés. Les informations stockées dans les informations d’identification doivent correspondre aux valeurs de propriétés du compte de stockage Azure utilisé lors des opérations de sauvegarde et de restauration.

Erreurs/Échecs de sauvegarde :

Les sauvegardes parallèles dans un même objet blob provoquent l'échec d'une des sauvegardes avec l'erreur Échec de l’initialisation .
Utilisez les journaux d'erreurs suivants pour vous aider à résoudre les erreurs de sauvegarde :
- Définissez l'indicateur de trace 3051 pour activer la journalisation dans un journal des erreurs spécifique au format suivant :
  
  BackupToUrl-instname-dbname-action-PID.log<<>>>< Où <action> est l’une des actions suivantes :
  - DB
  - FILELISTONLY
  - LABELONLY
  - HEADERONLY
  - VERIFYONLY
- Vous pouvez également trouver des informations en consultant le Journal des événements Windows - Sous Journaux d’application avec le nom « SQLBackupToUrl ».
En cas de restauration d'une sauvegarde compressée, vous pouvez rencontrer l'erreur suivante :
- Une exception SqlException 3284 s'est produite. Gravité : 16 État : 5
  Message Filemark sur l’appareil 'https://mystorage.blob.core.windows.net/mycontainer/TestDbBackupSetNumber2_0.bak' n’est pas aligné. Réexécutez l'instruction Restore avec la même taille de bloc que celle utilisée pour créer le jeu de sauvegarde : '65536' semble une valeur possible.
  
  Pour résoudre cette erreur, réexécutez l'instruction BACKUP en spécifiant BLOCKSIZE = 65536.
Erreur lors de la sauvegarde en raison d’objets blob pour lesquels un bail est actif : L’échec d’une activité de sauvegarde peut aboutir à des objets blob avec des bails actifs.

Si une instruction de sauvegarde est retentée, l'opération de sauvegarde échoue avec une erreur semblable à celle qui suit :

La sauvegarde vers l’URL a reçu une exception du point de terminaison distant. Message d’exception : le serveur distant a renvoyé une erreur : (412) Il existe actuellement un bail sur l’objet blob et aucun ID de bail n’a été spécifié dans la demande.

Si une instruction de restauration est tentée sur un fichier de sauvegarde d'objet blob dont le bail est actif, l'opération de restauration échoue avec une erreur semblable à celle qui suit :

Message d'exception : Le serveur distant a retourné une erreur : (409) Conflit.

Lorsqu'une telle erreur se produit, les fichiers d'objets blob doivent être supprimés. Pour plus d'informations sur ce scénario et la résolution du problème, consultez Deleting Backup Blob Files with Active Leases

Erreurs de proxy

Si vous utilisez des serveurs proxy pour l'accès à Internet, les erreurs suivantes peuvent survenir :

Limitation de la connexion par les serveurs proxy :

Les serveurs proxy peuvent avoir des paramètres qui limitent le nombre de connexions par minute. Le processus de sauvegarde vers l'URL est un processus multithread et, par conséquent, il peut dépasser cette limite. Si cela se produit, le serveur proxy supprime la connexion. Pour résoudre ce problème, modifiez les paramètres du proxy afin que SQL Server n'utilise pas le proxy. Voici quelques exemples des types d'erreur ou des messages qui peuvent s'afficher dans le journal des erreurs :

Écrivez sur «http://storageaccount.blob.core.windows.net/container/BackupAzurefile.bak" ; échec : la sauvegarde dans l’URL a reçu une exception du point de terminaison distant. Message d'exception : impossible de lire les données de la connexion de transport : la connexion a été fermée.
Une erreur d’E/S irrécupérable s’est produite sur le fichier "http://storageaccount.blob.core.windows.net/container/BackupAzurefile.bak:" ; L’erreur n’a pas pu être collectée à partir du point de terminaison distant.

Msg 3013, Niveau 16, État 1, Ligne 2

La sauvegarde de base de données s'est terminée anormalement.
BackupIoRequest::ReportIoError : échec d’écriture sur l’appareil de sauvegarde 'http://storageaccount.blob.core.windows.net/container/BackupAzurefile.bak'. Erreur de système d'exploitation. La sauvegarde vers l'URL a reçu une exception du point de terminaison distant. Message d'exception : impossible de lire les données de la connexion de transport : la connexion a été fermée.

Si vous activez la journalisation détaillée à l'aide de l'indicateur de trace 3051, vous pouvez également voir le message suivant dans les journaux :

HTTP status code 502, Erreur du proxy de message d’état HTTP (Le nombre de requêtes HTTP par minute a dépassé la limite configurée. Contactez votre administrateur ISA Server. )

Les paramètres du proxy par défaut ne sont pas sélectionnés :

Parfois, les paramètres par défaut ne sont pas récupérés, ce qui entraîne des erreurs d’authentification proxy telles que celle illustrée ci-dessous :Une erreur d’E/S irrécupérable s’est produite sur le fichier "http://storageaccount.blob.core.windows.net/container/BackupAzurefile.bak:" ; La sauvegarde vers l’URL a reçu une exception du point de terminaison distant. Message d’exception : le serveur distant a retourné une erreur : (407)Authentification proxy requise.

Pour résoudre ce problème, créez un fichier de configuration qui permet au processus de sauvegarde vers l'URL d'utiliser les paramètres du proxy par défaut à l'aide des étapes suivantes :

Créez un fichier de configuration nommé BackuptoURL.exe.config avec le xml suivant :

<?xml version ="1.0"?>  
<configuration>   
                <system.net>   
                                <defaultProxy enabled="true" useDefaultCredentials="true">   
                                                <proxy usesystemdefault="true" />   
                                </defaultProxy>   
                </system.net>  
</configuration>

Placez le fichier de configuration dans le dossier Binn de l’instance de SQL Server. Par exemple, si mon SQL Server est installé sur le lecteur C de l’ordinateur, placez le fichier de configuration ici : C:\Program Files\Microsoft SQL Server\MSSQL12.<InstanceName>\MSSQL\Binn.

Dépannage de la sauvegarde managée de SQL Server sur Azure

Étant donné que la sauvegarde managée de SQL Server est générée par dessus la sauvegarde vers l'URL, les conseils de dépannage décrits dans les premières sections s'appliquent aux bases de données ou aux instances qui utilisent la sauvegarde managée de SQL Server. Des informations sur la résolution des problèmes SQL Server sauvegarde managée sur Azure sont décrites en détail dans Résolution des problèmes SQL Server sauvegarde managée sur Azure.

Voir aussi

Restauration à partir des sauvegardes stockées dans Azure

Share via