Stockage objet : la sauvegarde est-elle nécessaire ?
Un stockage de type bloc dans le cloud mal sauvegardé peut se traduire par une perte de données. Si le stockage objet est plus résilient, mieux vaut être prudent.
Si les données stockées dans un service cloud de stockage en mode bloc ne sont pas correctement sauvegardées, elles peuvent être perdues à jamais. Le stockage de type objet est très différent du stockage en mode bloc et il offre de meilleures protections intégrées. Voici comment il fonctionne.
Qu'est-ce que le stockage objet ?
Tout fournisseur de cloud public dispose d'un service de stockage objet. C'est le cas de Simple Storage Service (S3) d'Amazon, de Blob Store d'Azure, de Cloud Storage de Google, d'Object Storage Unit chez Outscale et d'Object Storage chez OVH. Les systèmes de stockage objet sont des systèmes de fichiers sans structure hiérarchique de répertoires et sous-répertoires. Pour identifier et localiser un fichier, un système de fichiers combine la structure du répertoire et le nom de fichier. Par contre, chaque objet stocké dans un système de stockage objet reçoit un identifiant unique (UID) basé sur son contenu. C'est la métadonnée associée à l'objet. L'UID sert alors à la fois à identifier un objet et à le récupérer. L'UID est créé en exécutant le contenu du fichier à l'aide d'un algorithme cryptographique, comme le SHA-1 (Secure Hash Algorithm). (Pour mieux comprendre le fonctionnement du SHA-1, vous pouvez créer votre propre hachage SHA-1 en insérant ici un texte aléatoire.) Tout élément - un fichier, un bloc, un groupe de fichiers ou de blocs, ou une partie d'un bloc ou d'un fichier - peut être enregistré comme objet.
L'une des grandes différences entre le stockage objet et le stockage bloc, c'est que chaque objet stocké en mode objet est automatiquement répliqué dans au moins trois zones de disponibilité. Cela signifie que si deux zones de disponibilité sont détruites ou inaccessibles en cas de sinistre naturel ou de panne, toutes les données restent toujours stockées dans le système de stockage objet. Par contre, dans le cas du stockage en mode bloc, les données ne sont généralement répliquées qu'à l'intérieur d'une seule zone de disponibilité, de sorte qu'une seule panne importante peut détruire les données. Le fonctionnement de la réplication est également très différent. La réplication d'objets se fait au niveau de l'objet alors que, dans le cas du stockage bloc, la réplication se fait au niveau du bloc de stockage dans le cloud et les systèmes RAID classiques. Par ailleurs, les objets ne sont jamais modifiés. Si un objet doit être modifié, il est simplement stocké comme nouvel objet. Si la gestion de versions est activée, la version précédente de l'objet est sauvegardée à des fins historiques. Si le versioning n'est pas actif, la version précédente est simplement supprimée. C'est très différent du stockage par blocs, où les fichiers ou les blocs sont édités sur place, et les versions précédentes ne sont jamais sauvegardées, sauf si vous utilisez un système de protection supplémentaire.
Sauvegarde mais dans une autre région
Tous les fournisseurs de cloud public offrent des services de stockage objet. C'est le cas de Simple Storage Service (S3) d'Amazon, de Blob Store d'Azure, de Cloud Storage de Google, d'Object Storage Unit chez Outscale et d'Object Storage chez OVH. Il est par exemple possible d'utiliser ces systèmes de stockage objet pour protéger ses données même en cas de catastrophe régionale qui détruirait toutes les zones de disponibilité. Amazon s'appuie sur la réplication interrégionale, et laisse au client le soin de configurer sa réplication. Le stockage géo-redondant de Microsoft inclut la réplication à travers les régions, et Google offre un service identique de stockage sur deux ou plusieurs régions qui fait la même chose. En combinant ce système à des fonctions de versioning intégrées à tous les systèmes de stockage objet, les données stockées dans ces systèmes sont beaucoup plus résilientes que les données stockées dans les systèmes de stockage en blocs proposés par chacun de ces fournisseurs. Il est également possible de sauvegarder son stockage objet en local avec des acteurs comme Cloudian, Scality ou Minio qui sont tous compatibles S3.
À la différence des volumes de blocs et des systèmes de fichiers, conçus pour la performance, l'intégrité des données est l'objectif principal du stockage objet. Par exemple, il est possible d'utiliser à tout moment l'identifiant unique pour s'assurer qu'une copie donnée d'un objet n'a pas été corrompue. Pour cela, le système a simplement besoin de ré-exécuter l'objet en repassant par le processus qui a servi à créer l'identifiant unique. Si l'UID est toujours le même, le contenu de l'objet n'a pas changé. Si le contenu de l'objet a changé à cause d'une corruption des bits de données ou pour toute autre raison, l'anomalie est détectée automatiquement par le système, car l'UID sera différent. Il peut alors réparer automatiquement l'objet en récupérant une copie non corrompue stockée dans une autre région. À ce stade, aucun dispositif de blocs ou de système de fichiers n'offre ce niveau d'intégrité des données qu'il stocke.
Attention à la configuration
Le stockage objet est de plus en plus utilisé malgré l'Open Bucket Problem, où des données importantes et sensibles sont stockées dans un bucket dont les autorisations n'ont pas été gérées correctement. (Un bucket est une sorte de très grand conteneur avec des objets connexes.) Plusieurs grosses bases de données clients ont été exposées à ce problème, en grande partie parce que les clients ne comprenaient tout simplement pas comment fonctionnait le stockage objet. Certes, un bucket ouvert permet à l'entreprise de distribuer facilement des fichiers à de nombreuses personnes en leur donnant simplement le lien direct vers cet objet. Mais avec un bucket ouvert, l'entreprise peut livrer accidentellement ses secrets commerciaux au monde entier.
Suivre les meilleures pratiques
Une simple recherche dans Google sur les meilleures pratiques de votre fournisseur de stockage objet favori vous permettra d'obtenir les ressources dont vous avez besoin pour prendre les bonnes mesures. Par exemple, cette page web d'AWS fait plusieurs suggestions de bon sens, comme désactiver de l'accès public et réécrire des permissions pour tous. Microsoft, tout comme Google, consacrent également une page web aux meilleures pratiques. Vous devriez également pouvoir trouver un certain nombre d'articles de tierces parties pour vous guider tout au long du processus. Parmi les conseils qui reviennent souvent, celui de n'identifier que l'accès requis pour une application donnée et de n'accorder que ce niveau d'accès et rien de plus. Il est probablement beaucoup plus facile d'accorder à chaque application un accès complet aux buckets de stockage objet, mais, en terme de sécurité, c'est vraiment le meilleur moyen de s'exposer à un désastre. Utilisez aussi l'administration basée sur les rôles pour accorder et révoquer facilement un accès selon les besoins.
Faut-il sauvegarder son stockage objet ?
Le choix de sauvegarder ou non un stockage objet n'est pas aussi simple que celui de sauvegarder ou non un volume de blocs. Contrairement aux volumes de blocs, le stockage objet inclut automatiquement de nombreux niveaux de protection pour vous protéger contre divers éléments susceptibles de nuire à votre entreprise, y compris une protection « write-once-read-many (WORM) optionnelle. Si vous suivez toutes les meilleures pratiques - y compris la réplication interrégionale - on peut dire qu'aucune situation ne risque de mettre vraiment vos données en péril et vous obliger de recourir à une sauvegarde. L'aide d'un expert en protection des données peut s'avérer utile pour définir une stratégie de préservation solide.
Cela dit, il est difficile d'argumenter avec ceux qui disent que, parce que les services de stockage objet sont écrits par des humains, il peut y avoir des erreurs. Ils estiment que si les données qui résident dans un stockage objet sont des données critiques, alors il faut les sauvegarder. Il est important de préciser qu'il y a plusieurs manières de sauvegarder ces données. Il est possible, par exemple, d'utiliser un niveau de service complètement différent (AWS Glazier Deep Archive, Azure Archive Storage, ou Google Coldline) pour conserver une copie de vos données objet « au cas où ». Si vos données sont importantes, il faut envisager de les sauvegarder en s'appuyant sur ce type de services en s'assurant que la sauvegarde se trouve dans un compte et une région différents, tout comme pour le stockage en blocs.
Attention au mode de stockage que vous utilisez
Les volumes de blocs doivent être sauvegardés, alors, faites en sorte que ce soit le cas. Les instantanés de stockage de blocs doivent également être répliqués dans une autre région et sur un autre compte. Le stockage objet offre un niveau de résilience beaucoup plus élevé, puisqu'il est automatiquement répliqué dans plusieurs zones de disponibilité. Mais, encore une fois, aucune solution n'est infaillible. Alors informez-vous et décidez par vous-mêmes ce qui est le plus approprié à votre activité et à votre situation.
