Meilleures pratiques pour la récupération d’urgence avec Azure File Sync

Pour Azure File Sync, il existe trois domaines principaux à prendre en compte pour la récupération d’urgence : haute disponibilité, protection des données/sauvegarde et redondance des données. Cet article couvre chaque domaine et vous aide à choisir la configuration à utiliser pour votre propre solution de récupération d’urgence.

Dans un déploiement Azure File Sync, le point de terminaison cloud contient toujours une copie complète de vos données, tandis que le serveur local peut être affiché en tant que cache supprimable de vos données. En cas de sinistre côté serveur, vous pouvez effectuer une récupération en provisionnant un nouveau serveur, en y installant l’agent Azure File Sync et en le configurant comme nouveau point de terminaison de serveur.

En raison de leur nature hybride, certaines stratégies de récupération d’urgence et de sauvegarde de serveur traditionnelles ne fonctionnent pas avec Azure File Sync. Pour les serveurs inscrits, Azure File Sync ne prend pas en charge les opérations suivantes :

Avertissement

L’exécution de ces opérations peut entraîner des problèmes de synchronisation ou de fichiers hiérarchisés aboutissant à une perte de données éventuelle. Si vous avez effectué l’une de ces opérations, contactez le support Azure pour vous assurer que votre déploiement est sain.

• Le transfert/clonage de lecteurs de disque (volume) d’un serveur vers un autre pendant que le point de terminaison du serveur est toujours actif
• Restauration à partir d’une sauvegarde du système d’exploitation
• Clonage du système d’exploitation d’un serveur vers un autre serveur
• Rétablissement d’un point de contrôle de machine virtuelle précédent
• La restauration de fichiers hiérarchisés à partir d’une sauvegarde locale (tierce) sur le point de terminaison du serveur

Haute disponibilité

Vous pouvez utiliser deux stratégies différentes pour obtenir une haute disponibilité de votre serveur local. Vous pouvez configurer un cluster de basculement ou un serveur de secours. Deux facteurs sont déterminants pour choisir entre les deux configurations : votre degré d’investissement dans votre système et si le fait de réduire au minimum la durée pendant laquelle votre système est défaillant en cas de sinistre en vaut la peine financièrement.

Pour un cluster de basculement, il n’est pas nécessaire d’effectuer des étapes spéciales pour utiliser Azure File Sync. Pour un serveur de secours, vous devez effectuer les configurations suivantes :

Avoir un serveur secondaire avec des points de terminaison de serveur différents qui se synchronisent avec le même groupe de synchronisation que votre serveur principal, mais n’autorisent pas l’accès de l’utilisateur final au serveur. Cela permet à tous les fichiers d’être synchronisés du serveur principal vers le serveur de secours. Vous pouvez envisager d’activer la hiérarchisation de l’espace de noms uniquement afin que seul l’espace de noms soit téléchargé initialement. En cas de défaillance de votre serveur principal, vous pouvez utiliser DFS-N pour reconfigurer rapidement l’accès de l’utilisateur final à votre serveur de secours.

Protection des données/sauvegarde

La protection de vos données est un composant clé d’une solution de récupération d’urgence. Il existe deux méthodes principales pour effectuer cette opération avec vos partages de fichiers Azure : vous pouvez sauvegarder vos données dans le cloud ou localement. Nous vous recommandons vivement de sauvegarder vos données dans le cloud, car votre point de terminaison cloud contiendra une copie intégrale de vos données, tandis que les points de terminaison de serveur peuvent ne contenir qu’un sous-ensemble de vos données.

Sauvegarder vos données dans le cloud

Vous pouvez utiliser Sauvegarde Azure comme solution de sauvegarde cloud. Sauvegarde Azure gère la planification, la conservation et les restaurations de sauvegarde, entre autres. Si vous préférez, vous pouvez prendre manuellement des instantanés de partage et configurer votre propre solution de planification et de conservation, mais ce n’est pas idéal. Vous pouvez également utiliser des solutions tierces pour sauvegarder directement vos partages de fichiers Azure.

En cas d’incident, vous pouvez restaurer à partir d’un instantané de partage, qui est une copie en lecture seule à un point dans le temps de votre partage de fichiers. Ces instantanés étant en lecture seule, ils ne sont pas affectés par les ransomware. Pour les jeux de données volumineux, dans lesquels les opérations de restauration de partage complet prennent beaucoup de temps, vous pouvez activer l’accès direct de l’utilisateur à l’instantané afin que les utilisateurs puissent copier les données dont ils ont besoin sur leur lecteur local, pendant que la restauration se termine.

Les instantanés sont stockés directement dans votre partage de fichiers Azure, que vous les déposiez manuellement ou que Sauvegarde Azure le fasse pour vous. Vous devez donc activer la suppression réversible pour protéger vos instantanés contre la suppression accidentelle de votre partage de fichiers.

Pour plus d’informations, consultez À propos de la sauvegarde des partages de fichiers Azure ou contactez votre fournisseur de sauvegarde pour déterminer s’il prend en charge la sauvegarde des partages de fichiers Azure.

Sauvegarder vos données localement

Si vous activez la hiérarchisation cloud, n’implémentez pas une solution de sauvegarde locale. Lorsque la hiérarchisation cloud est activée, seul un sous-ensemble de vos données est stocké localement sur votre serveur et le reste de vos données est stocké dans votre point de terminaison cloud. Selon la solution de sauvegarde que vous utilisez pour une sauvegarde locale, les fichiers hiérarchisés seront :

• ignorés et non sauvegardés (en raison de leur attribut FILE_ATTRIBUTE_RECALL_ONDATA_ACCESS), ou
• sauvegardés uniquement en tant que fichier hiérarchisé et peuvent ne pas être accessibles lors de la restauration en raison de modifications apportées au partage dynamique, ou
• rappelés sur votre disque, ce qui entraînera des frais de sortie élevés.

Si vous préférez utiliser une solution de sauvegarde locale, les sauvegardes doivent être effectuées sur un serveur dans le groupe de synchronisation dont la hiérarchisation cloud est désactivée. Lorsque vous effectuez une restauration, utilisez les options de restauration au niveau du volume ou au niveau du fichier. Les fichiers restaurés en utilisant l’option de restauration au niveau du fichier sont synchronisés avec tous les points de terminaison dans le groupe de synchronisation et les fichiers existants sont remplacés par la version restaurée à partir de la sauvegarde. Les restaurations au niveau du volume ne remplacent pas les versions plus récentes des fichiers dans le point de terminaison cloud ou d’autres points de terminaison de serveur.

Les instantanés VSS (notamment l’onglet Versions précédentes) sont à présent pris en charge sur les volumes pour lesquels la hiérarchisation cloud est activée. Cela vous permet d’effectuer des restaurations libre-service au lieu de demander à un administrateur d’effectuer les restaurations à votre place. Toutefois, vous devez activer la compatibilité des versions précédentes par le biais de PowerShell, ce qui a pour effet d’augmenter les coûts de stockage des instantanés. Les instantanés VSS ne protègent pas contre les sinistres sur le point de terminaison de serveur lui-même et ne doivent donc être utilisés qu’avec les sauvegardes côté cloud. Pour plus d’informations, consultez Restauration libre-service via Versions précédentes et VSS.

Redondance des données

Pour garantir la robustesse de la solution de récupération d’urgence, ajoutez une forme de redondance des données à votre infrastructure. Il existe quatre offres de redondance pour Azure Files : le stockage localement redondant (LRS), le stockage redondant interzone (ZRS), le stockage géo-redondant (GRS) et le stockage géo-redondant interzone (GZRS).

• Stockage localement redondant (LRS) : avec LRS, chaque fichier est stocké trois fois au sein d’un cluster de stockage Azure. Cela le protège de la perte de données due à des défaillances matérielles, telles qu’un lecteur de disque défectueux. Toutefois, si un sinistre tel qu’un incendie ou une inondation se produit à l’intérieur du centre de données, tous les réplicas d’un compte de stockage utilisant un stockage localement redondant risquent d’être perdus ou irrécupérables.
• Stockage redondant dans une zone (ZRS) : avec ZRS, trois copies de chaque fichier stocké, mais ces copies sont physiquement isolées dans trois clusters de stockage distincts dans différentes zones de disponibilité Azure. Les Zones de disponibilité sont des emplacements physiques uniques au sein d’une région Azure. Chaque zone de disponibilité est composée d'un ou de plusieurs centres de données équipés d'une alimentation, d'un système de refroidissement et d'un réseau indépendants. Une écriture sur le stockage n’est pas acceptée tant qu’elle n’est pas écrite sur les clusters de stockage dans les trois zones de disponibilité.
• Stockage géoredondant (GRS) : avec GRS, vous avez deux régions, une région primaire et une région secondaire. Les fichiers sont stockés trois fois au sein d’un cluster de stockage Azure dans la région primaire. Les écritures sont répliquées de façon asynchrone dans une région secondaire définie par Microsoft. Le stockage GRS fournit six copies de vos données réparties entre deux régions Azure.
• Stockage géo-redondant interzone (GZRS) : Considérer le GZRS comme un ZRS, mais avec une géo-redondance. Avec GZRS, les fichiers sont stockés trois fois sur trois clusters de stockage distincts dans la région primaire. Toutes les écritures sont ensuite répliquées de façon asynchrone dans une région secondaire définie par Microsoft.

Pour garantir la robustesse de la solution de récupération d’urgence, la plupart des clients doivent envisager d’utiliser le stockage redondant interzone (ZRS). Le stockage ZRS ajoute un coût supplémentaire minimal si l’on tient compte des avantages de la redondance des données ajoutée et il est également le plus fluide en cas de panne. Si la stratégie ou les exigences réglementaires de votre organisation nécessitent la géoredondance de vos données, envisagez d’utiliser le stockage GRS ou GZRS.

Géo-redondance

Si votre compte de stockage est configuré avec la réplication GRS ou GZRS, Microsoft lance le basculement du service de synchronisation de stockage si la région primaire est jugée irrémédiablement irrécupérable ou indisponible pendant une longue période. Aucune action n’est requise de votre part en cas de sinistre.

Bien que vous puissiez demander manuellement un basculement de votre service de synchronisation de stockage vers votre région jumelée GRS ou GZRS, nous vous déconseillons de le faire en dehors des pannes régionales à grande échelle, le processus n’étant pas fluide et pouvant entraîner des frais supplémentaires. Pour initier le processus, ouvrez un ticket de support et demandez à ce que vos comptes de stockage Azure qui contiennent votre partage de fichiers Azure et votre service de synchronisation de stockage fassent l’objet d’un basculement.

Avertissement

Vous devez contacter le support pour demander le basculement de votre service de synchronisation de stockage si vous lancez ce processus manuellement. Tenter de créer un service de synchronisation de stockage à l’aide des mêmes points de terminaison de serveur dans la région secondaire peut entraîner la conservation de données supplémentaires dans votre compte de stockage, car l’installation précédente d’Azure File Sync ne sera pas nettoyée.

Une fois le basculement effectué, les points de terminaison de serveur basculent pour se synchroniser automatiquement avec le point de terminaison cloud dans la région secondaire. Toutefois, les points de terminaison de serveur doivent être rapprochés des points de terminaison cloud. Cela peut entraîner des conflits de fichiers, car les données de la région secondaire peuvent ne pas être détectées dans la région primaire.

Étape suivante

En savoir plus sur la sauvegarde des partages de fichiers Azure