Matrice de prise en charge pour la sauvegarde des objets blob Azure
Cet article récapitule les disponibilités régionales, les scénarios pris en charge et les limitations des sauvegardes opérationnelles et archivées de blobs.
La sauvegarde opérationnelle des blobs est disponible dans toutes les régions du cloud public, à l’exception des régions France Sud et Afrique du Sud Ouest. Elle est également disponible dans les régions de cloud souverain, c’est-à-dire toutes les régions Azure Government et les régions de la Chine (sauf la région Chine Est).
La sauvegarde coffretée pour les objets blob est disponible dans toutes les régions de cloud public.
Scénarios pris en charge et non pris en charge pour la sauvegarde d’objets blob Azure
La sauvegarde opérationnelle des objets blob utilise la restauration à un instant dans le passé des objets blob, le contrôle de version des objets blob, la suppression réversible des objets blob, le flux de modification pour les objets blob et le verrou de suppression pour fournir une solution de sauvegarde locale. Par conséquent, les limitations qui s’appliquent à ces fonctionnalités s’appliquent également à la sauvegarde opérationnelle.
Scénarios pris en charge :
La sauvegarde opérationnelle prend en charge les objets blob de blocs dans les comptes de stockage de standard à usage général v2 uniquement. Les comptes de stockage avec un espace de noms hiérarchique activé (c’est-à-dire, les comptes ADLS Gen2) ne sont pas pris en charge.
En outre, les objets blob de pages, les objets blob d’ajout et les objets blob Premium dans votre compte de stockage ne sont pas restaurés et seuls les objets blob de blocs sont restaurés.
La sauvegarde de blobs est également prise en charge quand le compte de stockage a des points de terminaison privés.
Autres limitations :
Si vous avez supprimé un conteneur au cours de la période de conservation, ce conteneur ne sera pas restauré lors de l’opération de restauration à un instant dans le passé. Si vous tentez de restaurer une plage d’objets blob incluant des objets blob dont le conteneur a été supprimé, l’opération de récupération jusqu’à une date et heure échouera. Pour plus d’informations sur la protection des conteneurs contre la suppression, consultez Suppression réversible pour les conteneurs.
Les conteneurs avec conservation légale activée ne sont pas pris en charge.
Si un objet blob a été déplacé entre les niveaux chaud et froid pendant la période comprise entre le moment présent et le point de restauration, l’objet blob est restauré à son niveau précédent. La restauration d’objets blob de blocs du niveau archive n’est pas prise en charge. Par exemple, si un objet blob a été déplacé du niveau d’accès chaud au niveau de stockage archive deux jours auparavant et qu’une opération de restauration est effectuée sur un point trois jours auparavant, l’objet blob n’est pas restauré vers le niveau d’accès chaud. Pour restaurer un objet blob archivé, commencez par le déplacer en dehors du niveau archive. Pour plus d’informations, consultez Réalimenter les données d’objets blob à partir du niveau Archive.
Un bloc qui a été chargé via Put Block ou Put Block à partir d’une URL, mais qui n’est pas commité via Put Block List, ne fait pas partie d’un blob et n’est donc pas restauré dans une opération de restauration.
Un objet blob avec un bail actif ne peut pas être restauré. Si un objet blob avec un bail actif est inclus dans la plage d’objets blob à restaurer, l’opération de restauration échoue de façon automatique. Arrêtez tout bail actif avant de démarrer l’opération de restauration.
Les instantanés ne sont pas créés ou supprimés dans le cadre d’une opération de restauration. Seul l’objet blob de base est restauré à son état précédent.
Si les blobs en cours de restauration comptent des blobs immuables, ces derniers ne sont pas restaurés à l’état qu’ils avaient au point de récupération sélectionné. Toutefois, les autres objets blob pour lesquels l’immuabilité n’est pas activée seront restaurés comme prévu au point de récupération sélectionné.
Vous pouvez sauvegarder uniquement les blobs de blocs dans un compte de stockage v2 universel standard en utilisant la solution de sauvegarde archivée pour les blobs.
La sauvegarde en coffre d’objets blob est également prise en charge lorsque le compte de stockage a des points de terminaison privés.
Actuellement, les comptes de stockage HNS ne sont pas pris en charge. Cela comprend les comptes ADLS Gen2, les comptes utilisant NFS 3.0 et les protocoles SFTP pour les blobs.
Vous pouvez effectuer jusqu’à cinq sauvegardes par compte de stockage par jour.
Vous pouvez sauvegarder des comptes de stockage avec jusqu’à 100 conteneurs, il n’existe aucune limite quant au nombre d’objets blob au sein de ces conteneurs. Vous pouvez également sélectionner un sous-ensemble de conteneurs à sauvegarder (jusqu’à 100 conteneurs).
Si votre compte de stockage contient plus de 100 conteneurs, vous devez sélectionner jusqu’à 100 conteneurs à sauvegarder.
Pour sauvegarder les nouveaux conteneurs qui ont été créés après la configuration de la sauvegarde pour le compte de stockage, modifiez la protection du compte de stockage. Ces conteneurs ne sont pas sauvegardés automatiquement.
Les comptes de stockage à sauvegarder doivent contenir au moins un conteneur. Si le compte de stockage ne contient aucun conteneur ou si aucun conteneur n’est sélectionné, une erreur peut apparaître lorsque vous configurez la sauvegarde.
Seuls $web et $root les conteneurs système sont pris en charge pour la sauvegarde coffretée.
Si vous arrêtez la protection (sauvegarde archivée) sur un compte de stockage, cela ne supprime pas la stratégie de réplication d’objets créée sur le compte de stockage. Dans ces scénarios, vous devez supprimer manuellement les stratégies de réplication d’objets.
Vous pouvez éviter les perturbations des sauvegardes vaulted Azure Blob lors d’un basculement de compte de stockage en suivant une séquence spécifique : mettre la sauvegarde en pause, supprimer la politique de réplication d’objets au niveau du compte de stockage, finaliser le basculement, puis reprendre la sauvegarde. Ce processus n’impacte pas les points de récupération existants. Cependant, il déclenche une réplication complète des blobs lors de la prochaine opération de sauvegarde. La politique de réplication des objets est automatiquement recréée lors du cycle de sauvegarde suivant.
Lorsque vous supprimez des sauvegardes, Sauvegarde Azure supprime automatiquement la stratégie de réplication d’objets de la source. Si des verrous personnalisés existent, supprimez la politique manuellement. Si vous arrêtez la protection, cela déconnecte uniquement le compte de stockage du coffre de sauvegarde et des outils, tels que le Centre de sauvegarde. Cette action ne désactive pas la restauration jusqu’à une date et heure des objets blob, le contrôle de version ni les paramètres de flux de modifications.
La sauvegarde d’objets blob de niveau Archive n’est pas prise en charge. Les objets blob de niveau froid et sporadique sont restaurés dans le niveau chaud.
L’opération de sauvegarde n’est pas prise en charge pour les objets blob chargés à l’aide des API Data Lake Storage.
Lorsque vous supprimez et recréez un compte conteneur dans le stockage portant le même nom, la réplication d’objets ne reconnaît pas le changement. Par conséquent, les futurs points de récupération continuent d’inclure les objets blob plus anciens et leurs versions.
De même, si vous supprimez et recréez un conteneur portant le même nom, la réplication d’objets ne suit pas la modification et les futurs points de récupération incluent toujours les objets blob et versions précédents.
Si vous suspendez et reprenez la protection ou supprimez la stratégie de réplication d’objets sur le compte de stockage source, la stratégie déclenche une sauvegarde complète.
Les coffres de sauvegarde avec l’identité managée affectée par l’utilisateur (UAMI) ne sont pas compatibles avec les sauvegardes azure Blob Vaulted. Seul l’identité managée affectée par le système fonctionne, car le coffre doit accéder au compte de stockage où les objets blob sont stockés. Le coffre utilise son identité managée affectée par le système pour cet accès.
L’activation des sauvegardes n’est pas prise en charge pour le conteneur d’objets blob configuré avec la réplication native à l’aide de la fabrique de données.
La protection d’un conteneur qui fait partie d’une réplication d’objets n’est pas prise en charge, en tant que source ou destination. La tentative de sauvegarde d’un tel conteneur entraîne une défaillance de sauvegarde.
Les conteneurs avec conservation légale activée ne sont pas pris en charge.