C’est un scénario bien connu des équipes IT. Les sauvegardes s’exécutent comme prévu, les jobs se terminent avec succès et tout semble sous contrôle. Les fenêtres de sauvegarde se ferment, les indicateurs sont au vert et les équipes passent à autre chose.
Les sauvegardes tombent alors dans l’oubli… jusqu’au jour où il faut réellement les restaurer.
C’est à ce moment-là que la réalité du stockage cloud rattrape les équipes. Le stockage d’objets sur Amazon S3 ou Azure Blob a connu une croissance spectaculaire, tant en volume qu’en importance stratégique. Il héberge aujourd’hui des données applicatives critiques, des flux de télémétrie, des contenus multimédias, des archives de conformité et bien plus encore.
Certains de ces environnements contiennent des centaines de millions d’objets et plusieurs téraoctets de données. En restaurer un n’a donc rien d’une formalité. C’est précisément là que Rubrik fait la différence en priorisant la restauration pour Amazon S3 et Azure Blob, réduisant ainsi considérablement le temps nécessaire pour remettre en ligne vos environnements de stockage essentiels et, par extension, pour rétablir votre activité.
Pourquoi la restauration du stockage d’objets est si chronophage
Pour bien comprendre ce scénario, il faut d’abord saisir pourquoi la sauvegarde paraît souvent si rapide, alors que la restauration semble si lente. Lors de la sauvegarde du stockage d’objets, les solutions de protection des données s’appuient généralement sur des lectures parallèles optimisées pour capturer les données avec efficacité. Cette opération est conçue pour s’exécuter en arrière-plan, sans perturber les charges applicatives.
La restauration, en revanche, obéit à une logique totalement différente. La restitution des objets dans un bucket, ou compartiment, nécessite un appel API distinct pour chaque objet. Or, les API des fournisseurs cloud appliquent des limites de débit à ces opérations de type PUT. Lorsqu’il s’agit de millions d’objets, même un processus de restauration hautement parallélisé peut donc prendre bien plus de temps que l’opération de sauvegarde initiale. Chaque objet correspond à une transaction. Et chaque transaction prend du temps. À cette échelle, les contraintes mathématiques sont implacables.
Il ne s’agit pas d’une faiblesse de la solution de sauvegarde. C’est une contrainte structurelle, inhérente au fonctionnement même des API de stockage d’objets.
Avec les services natifs, c’est tout ou rien
Si les services cloud natifs de type AWS Backup ou Azure Backup assurent une protection de base efficace du stockage d’objets, leur modèle de reprise reste toutefois très limité. On peut soit restaurer l’intégralité du bucket ou du container Blob, soit restaurer quelques fichiers ou objets isolés, soit ne rien restaurer du tout. Il n’existe aucun mécanisme de priorisation lors d’une restauration complète de bucket.
Pour les buckets ou containers Blob de grande taille, une restauration complète peut s’étendre sur plusieurs heures, voire plusieurs jours. Pendant ce temps, les applications et services qui dépendent de ce stockage restent à l’arrêt. Vos équipes attendent. Vos clients attendent. L’impact business s’accentue à chaque minute qui passe, indépendamment du fait que les données réellement nécessaires aux utilisateurs et aux applications en aval aient été restaurées ou non.
Le problème tient au fait que la plupart des solutions de protection des données considèrent les buckets et containers Blob comme des ensembles monolithiques. Or, dans la pratique, tous les objets n’ont pas la même valeur. Certains sont indispensables à la reprise de l’activité, tandis que d’autres relèvent de l’archivage, de l’historique ou de données à faible priorité. Les solutions de sauvegarde natives ne permettent pas d’exprimer cette distinction, ni aux organisations d’agir en conséquence.
Du moins, jusqu’à présent.
Nouveau : la restauration priorisée de Rubrik pour S3 et Blob
La fonctionnalité de restauration priorisée de Rubrik pour Amazon S3 et Azure Blob redonne aux administrateurs le contrôle des processus de restauration. Plutôt que de considérer le rétablissement d’un bucket ou d’un container Blob comme une opération unique et indifférenciée, Rubrik permet d’identifier précisément les objets les plus critiques et de les restaurer en priorité.
Grâce à des « glob patterns », vous pouvez définir les fichiers ou chemins de dossiers essentiels à la continuité de vos opérations. Rubrik place alors la restauration de ces objets en tête de file, afin que vos données les plus critiques soient de nouveau disponibles pendant que le reste du bucket se restaure en arrière-plan.
Dans le cas d’Amazon S3, vous pouvez par exemple prioriser :
Les fichiers de configuration applicative actifs, stockés sous un préfixe connu (par exemple : config/*)
Des types d’objets spécifiques identifiés par leurs extensions, nécessaires au bon fonctionnement d’une application en aval
Tout modèle nommé correspondant à vos priorités opérationnelles de reprise
Vous avez un doute sur les objets concernés ? Aucun problème. Rubrik offre également la possibilité de prévisualiser rapidement les objets qui seront priorisés.
Le reste du bucket (données d’archivage, snapshots historiques et objets à moindre priorité) poursuit automatiquement sa restauration une fois les objets critiques rétablis. La restauration complète a bien lieu, mais dans le bon ordre. Et si nécessaire, vous pouvez également choisir de ne restaurer que les données priorisées.
L’impact du RTO en conditions réelles
L'objectif de temps de restauration (RTO) ne correspond pas uniquement au délai nécessaire pour un rétablissement complet : il représente le temps qui s’écoule avant que l’activité puisse réellement reprendre. Dans le contexte du stockage d’objets à grande échelle, ces deux notions renvoient à des réalités très différentes.
Avec un modèle de restauration « tout ou rien », le RTO effectif est dicté par l’objet le plus lent, à savoir le dernier restauré dans le bucket ou le container Blob. Avec la restauration priorisée, le RTO effectif correspond uniquement au temps nécessaire pour restaurer les objets indispensables au redémarrage des applications et des services, ce qui peut ne représenter qu’une fraction du temps de restauration total.
Cet écart est déterminant dans des scénarios réels d’interruption de service. Si les objets critiques requis par votre application de production ne représentent que 5 % du bucket, la restauration priorisée peut vous permettre de redevenir opérationnel en une fraction du temps qu’exigerait une restauration complète. Les 95 % restants poursuivent leur restauration en arrière-plan, sans plus bloquer le fonctionnement normal de l’entreprise.
Une reprise alignée sur vos priorités, pas sur l’ordre alphabétique
Le stockage d’objets est devenu un pilier essentiel des applications modernes. À mesure que les buckets et containers Blob gagnent en volumétrie, l’écart entre une sauvegarde terminée et une restauration réellement exploitable s’est considérablement creusé. La restauration priorisée pour Amazon S3 et Azure Blob comble cet écart en rétablissant en premier les éléments les plus critiques.
Car lorsqu’un édifice commence à s’effondrer, il ne faut pas renforcer indifféremment tous les murs et cloisons, mais d’abord les murs porteurs. Et vite !
Pour découvrir la restauration priorisée de Rubrik en action sur Amazon S3 et Azure Blob, participez à l’un de nos ateliers de démo interactifs sur la plateforme Rubrik Explore.