Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Vous pouvez utiliser le service Sauvegarde Azure pour sauvegarder des bases de données SQL Server dans des machines virtuelles Azure hébergées sur la plateforme cloud Microsoft Azure. Cet article résume les limitations et les paramètres généraux de prise en charge des scénarios et des déploiements de sauvegarde de SQL Server dans des machines virtuelles Azure.
Prise en charge du scénario
| Support | Details |
|---|---|
| Déploiements pris en charge | Les machines virtuelles Azure de la Place de marché SQL et les machines virtuelles autres que celles de la Place de marché (sur lesquelles SQL Server est installé manuellement) sont prises en charge. |
| Régions prises en charge | Sauvegarde Azure pour les bases de données SQL Server est disponible dans toutes les régions, à l’exception de France Sud (FRS). |
| Systèmes d’exploitation pris en charge | Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows Server 2012 (toutes les versions), Windows Server 2008 R2 SP1 Une configuration supplémentaire est requise pour Windows Server 2008 et 2008 R2. Découvrez comment définir l’autorisation de machine virtuelle. Linux n’est pas actuellement pris en charge. |
| Versions de SQL Server prises en charge | SQL Server 2022 Express, SQL Server 2022, SQL Server 2019, SQL Server 2017, comme détaillé dans la page cycle de vie des produits de recherche, SQL Server 2016 et SPs, comme détaillé dans la page de cycle de vie des produits de recherche, SQL Server 2014, SQL Server 2012. Entreprise, Standard, Web, Développeur, Express. Les versions de base de données locales Express ne sont pas prises en charge. |
| Versions .NET prises en charge | .NET Framework 4.6.2 ou version ultérieure installée sur la machine virtuelle |
| Déploiements pris en charge | Les machines virtuelles Azure de la Place de marché SQL et les machines virtuelles autres que celles de la Place de marché (sur lesquelles le Serveur SQL est installé manuellement) sont prises en charge. La prise en charge des instances autonomes est toujours sur les groupes de disponibilité. Notez que les bases de données SQL qui font partie d’un groupe de disponibilité AlwaysOn et qui sont synchronisées à partir de SQL Managed Instance ne sont pas prises en charge. |
| Restauration entre régions | Pris en charge pour les bases de données protégées en instance autonome et/ou dans le cadre d’un groupe de disponibilité SQL. En savoir plus. |
| Restauration avec plusieurs abonnements | Pris en charge via le Portail Azure et Azure CLI. En savoir plus. |
Considérations et limitations relatives aux fonctionnalités
| Setting | Limite maximale |
|---|---|
| Nombre de bases de données pouvant être protégées sur un serveur (et dans un coffre) | 2000 |
| Taille de la base de données prise en charge (au-delà, des problèmes de performances peuvent survenir) | 6 To* |
| Nombre de fichiers pris en charge dans une base de données | 1000 |
| Nombre de sauvegardes complètes prises en charge par jour | Une sauvegarde planifiée. Trois sauvegardes à la demande. Nous vous recommandons de ne pas déclencher plus de trois sauvegardes par jour. Toutefois, pour permettre à l’utilisateur de réaliser de nouvelles tentatives en cas d’échec, la limite matérielle pour les sauvegardes à la demande est définie à neuf tentatives. |
| Copie des journaux de transaction | Lorsque vous activez la copie des journaux de transaction sur la base de données SQL Server que vous sauvegardez, nous vous recommandons de désactiver les sauvegardes de journaux dans la stratégie de sauvegarde. En effet, la copie des journaux de transaction (qui envoie automatiquement les journaux des transactions de la base de données principale à la base de données secondaire) interfère avec les sauvegardes de journaux activées via Sauvegarde Azure. Par conséquent, si vous activez la copie des journaux de transaction, assurez-vous que seules les sauvegardes complètes et/ou différentielles de votre stratégie sont activées. |
| Période de conservation des sauvegardes à la demande | Pour les sauvegardes complètes/ maximales ou incrémentielles, la durée de conservation par défaut est de 45 jours. Pour une sauvegarde complète en copie seule, vous pouvez définir une période de rétention personnalisée. |
| Limite de restauration pour SQL dans une machine virtuelle Azure | 20 |
| Nombre de bases de données pouvant être sauvegardées simultanément | 20 par VM |
| Nombre de bases de données pouvant être restaurées simultanément | 15 par VM |
| Nombre de bases de données pouvant être restaurées simultanément sous forme de fichiers | 15 par VM |
| Nombre de restaurations autorisées par base de données | 20 par jour |
*La limite de taille de base de données dépend du taux de transfert de données que nous prenons en charge et de la configuration de la limite de durée de sauvegarde. Ce n’est pas la limite maximale. En savoir plus sur les performances du débit de sauvegarde.
- La sauvegarde SQL Server peut être configurée dans le portail Azure ou PowerShell. CLI n’est pas pris en charge.
- La solution est prise en charge sur les deux types de déploiements : machines virtuelles Azure Resource Manager et machines virtuelles classiques.
- Tous les types de sauvegarde (complète/différentielle/journal) et les modes de récupération (simple/complet/journalisé en bloc) sont pris en charge.
- Pour les bases de données en lecture seule : les sauvegardes complètes et de copie uniquement complètes sont les seuls types de sauvegarde pris en charge.
- La compression native SQL est prise en charge si elle est explicitement activée par l’utilisateur dans la stratégie de sauvegarde. Sauvegarde Azure remplace les valeurs par défaut au niveau de l’instance par la clause COMPRESSION / NO_COMPRESSION en fonction de la valeur de ce contrôle, tel que défini par l’utilisateur.
- La sauvegarde des base de données compatibles avec TDE est prise en charge. Pour restaurer une base de données chiffrée avec TDE sur un autre serveur SQL Server, vous devez d’abord restaurer le certificat sur le serveur de destination. La compression de sauvegarde pour les bases de données compatibles TDE pour SQL Server 2016 et les versions plus récentes est disponible, mais à une taille de transfert inférieure, comme expliqué ici.
- Les opérations de sauvegarde et de restauration des bases de données miroirs et des instantanés de base de données ne sont pas prises en charge.
- L’instance de cluster de basculement (FCI) SQL Server n’est pas prise en charge.
- Les bases de données dont le nom contient des extensions ne sont pas prises en charge. Cela est dû au fait que le serveur IIS effectue le filtrage des demandes d’extension de fichier. Notez toutefois que nous avons sélectionné les noms
.ad,.cset.master, qui peuvent être utilisés dans les noms de base de données. En savoir plus sur les directives de nommage des bases de données pour Sauvegarde Azure. - Le chiffrement FIPS n’est actuellement pas pris en charge avec les charges de travail de sauvegarde SQL.
Performances de débit de sauvegarde
Le service Sauvegarde Azure prend en charge un taux de transfert de données cohérent de 350 Mbits/s pour les sauvegardes complètes et différentielles de bases de données SQL volumineuses (de 500 Go). Pour des performances optimales, vérifiez que les conditions suivantes sont réunies :
- La machine virtuelle sous-jacente (contenant l'instance de SQL Server qui héberge la base de données) est configurée avec le débit réseau requis. Si le débit maximal de la machine virtuelle est inférieur à 200 Mbits/s, le service Sauvegarde Azure ne pourra pas transférer les données à la vitesse optimale.
En outre, le débit configuré pour le disque qui contient les fichiers de base de données doit être suffisant. En savoir plus sur le débit et les performances du disque dans les machines virtuelles Azure. - Les processus exécutés sur la machine virtuelle ne consomment pas la bande passante de celle-ci.
- Les planifications de sauvegarde sont réparties sur un sous-ensemble de bases de données. Plusieurs sauvegardes exécutées simultanément sur une machine virtuelle se partagent le taux de consommation du réseau. Découvrez comment contrôler le nombre de sauvegardes simultanées.
- Le débit maximal pris en charge pour les sauvegardes de journaux est de 50 Mbits/s, en fonction de l’évolution moyenne des journaux observée dans la plupart des environnements. Si vous rencontrez constamment une activité de journal élevée et que vous rencontrez des performances de sauvegarde réduites, contactez le support Microsoft pour obtenir de l’aide supplémentaire.
Note
- Le débit plus élevé est automatiquement limité lorsque les conditions suivantes sont remplies :
- Toutes les bases de données doivent être supérieures à la taille de 4 To.
- Les bases de données doivent être hébergées sur des machines virtuelles Azure avec une métrique de débit du disque non mis en cache supérieure à 800 Mbit/s.
- Téléchargez le planificateur de ressources détaillé pour calculer le nombre approximatif de bases de données protégées recommandé par serveur en fonction des ressources de machine virtuelle, de la bande passante et de la stratégie de sauvegarde.
Étapes suivantes
Découvrez comment sauvegarder une base de données SQL Server s'exécutant sur une machine virtuelle Azure.