Pratiques recommandées pour la sauvegarde et la restauration (service de stockage d'objets blob Windows Azure)

Article
02/18/2014

Cette rubrique présente les pratiques recommandées et des conseils de dépannage pour la sauvegarde et la restauration SQL Server dans le service d'objets blob Windows Azure.

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

Sauvegarde et restauration SQL Server avec le service de stockage d'objets blob Windows Azure
Didacticiel : Mise en route avec la sauvegarde et la restauration SQL Server dans le service de stockage d'objets blob Windows 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 d'objets blob Windows Azure, 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 situées sur une instance de SQL Server s'exécutant sur un ordinateur virtuel Windows Azure, utilisez un compte de stockage situé dans la même région que l'ordinateur virtuel afin d'éviter les coûts de transfert de 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 Suppression de fichiers de sauvegarde d'objets blob avec des baux actifs.
Utilisez l'option WITH COMPRESSION pendant la sauvegarde pour 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 d'objets blob Windows 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 sur site, nous vous recommandons de commencer par tester le débit. Les SLA du stockage Windows Azure imposent des temps de traitement maximum pour les objets blob dont vous devez tenir 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.

Optimisation des restaurations

Pour réduire le temps d'écriture des restaurations, ajoutez le droit d'utilisateur Effectuer les tâches de maintenance de volume au compte d'utilisateur de SQL Server. Pour plus d'informations, consultez Initialisation des fichiers de base de données

Considérations relatives aux performances

Les performances de sauvegarde et de restauration peuvent varier en fonction de la bande passante réseau, de la taille de la base de données et de l'emplacement du service de stockage Windows Azure par rapport à l'emplacement sur site. Pour évaluer les performances de sauvegarde et de restauration pour votre environnement, nous vous recommandons de tester des sauvegardes et des restaurations et de mesurer le débit et les performances. Les éléments suivants doivent être pris en compte lors de la sauvegarde dans le service de stockage d'objets blob Windows Azure :

Les durées de sauvegarde et de restauration sont proportionnelles à la bande passante réseau.
La bande passante réseau minimale de la sauvegarde est de 1 Mo par seconde. La sauvegarde peut échouer avec des erreurs de délai d'attente, si la bande passante est inférieure à 1 Mo par seconde.
La durée de restauration est également proportionnelle au temps de réponse du réseau, notamment si vous essayez de restaurer un fichier d'une région Windows Azure géographiquement différente de l'instance de SQL Server vers laquelle vous essayez d'effectuer la restauration. Dans ce cas, le test est très important pour vérifier que vous êtes en mesure de répondre à vos exigences en matière d'objectif de temps de récupération (RTO).

Résolution des problèmes de sauvegarde/restauration vers/depuis le service de stockage d'objets blob Windows Azure

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 d'objets blob Windows Azure.

Pour éviter les erreurs dues à des options ou limitations non prises en charge, consultez la liste des limitations, ainsi que l'aide sur les commandes BACKUP et RESTORE dans l'article Sauvegarde et restauration SQL Server avec le service de stockage d'objets blob Windows Azure.

Erreurs d'authentification :

WITH CREDENTIAL est une nouvelle option requise pour la sauvegarde ou la restauration vers/depuis le service de stockage d'objets blob Windows 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 du rôle db_backupoperator disposant des autorisations Alter any credential.
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 Windows 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-<nominstance>-<nombd>-action-<PID>.log, où <action> a l'une des valeurs suivantes :
  - DB
  - FILELISTONLY
  - LABELONLY
  - HEADERONLY
  - VERIFYONLY
- Vous pouvez également trouver des informations en examinant le journal des événements Windows nommé « SQLBackupToUrl » sous Journaux d'application.
Erreur lors de la sauvegarde en raison d'objets blob avec un bail actif : l'activité de sauvegarde en échec peut générer des objets blob avec des baux 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 retourné une erreur : (412) Il y a actuellement un bail sur l'objet blob et aucun ID de bail n'a été spécifié dans la requête.

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 Suppression de fichiers de sauvegarde d'objets blob avec des baux actifs

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 :

Échec d'écriture sur « 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 : impossible de lire les données de la connexion de transport : la connexion a été fermée.
Une erreur d'E/S non récupérable s'est produite dans 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'unité 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 :

Code d'état HTTP 502, message d'état HTTP, erreur de proxy (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 sélectionnés et provoquent des erreurs d'authentification du proxy telles que celle affichée ci-dessous :Une erreur d'E/S non récupérable s'est produite dans 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 du proxy nécessaire.

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 code 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 instance SQL Server est installée sur le lecteur C de l'ordinateur, placez le fichier de configuration ici : C:\Program Files\Microsoft SQL Server\MSSQL11.<NomInstance>\MSSQL\Binn.