Aller au contenu

AWS Mis à jour le 2026-07-04

Restaurer depuis Glacier : expedited, standard et bulk, comparés honnêtement

Comment restaurer des objets depuis S3 Glacier Flexible Retrieval et Deep Archive — ce que les paliers expedited, standard et bulk livrent vraiment, ce que chacun coûte, et le runbook des grosses restaurations.

Restaurer depuis Glacier, c’est émettre une demande de restauration, attendre selon le palier payé, puis lire une copie temporaire avant qu’elle expire. Depuis Glacier Flexible Retrieval : expedited se termine typiquement en 1 à 5 minutes, standard en 3 à 5 heures, et bulk en 5 à 12 heures — et bulk est gratuit. Depuis Deep Archive : standard se termine en environ 12 heures, bulk en environ 48, et expedited n’existe pas. La comparaison honnête : bulk pour tout ce qui est planifié, standard pour le cas « aujourd’hui », et expedited seulement pour de vraies urgences sur un petit nombre d’objets — c’est l’option la plus chère et, sans capacité provisionnée, sa disponibilité n’est pas garantie.

Ce qui se passe

Les objets en Glacier Flexible Retrieval et Deep Archive ne sont pas lisibles directement. Un GetObject contre eux retourne InvalidObjectState. Vous appelez RestoreObject, S3 met en file une tâche de récupération au palier choisi, et à la fin, une copie temporaire de l’objet devient lisible à côté de l’original archivé, pour le nombre de jours demandé. Vous payez l’objet archivé et la copie temporaire en même temps pendant cette fenêtre, plus la récupération elle-même — facturée au Go récupéré et par millier de requêtes, expedited coûtant le plus cher au Go et bulk le moins (gratuit depuis Flexible Retrieval). Glacier Instant Retrieval est différent : aucune étape de restauration, les lectures sont synchrones — c’est sa raison d’être.

Expedited a une réserve de capacité qui compte exactement au pire moment : il est livré sur une capacité partagée, et pendant un événement régional où beaucoup de clients restaurent en même temps, les demandes expedited peuvent être rejetées avec une erreur de capacité insuffisante. Les unités de capacité provisionnée existent pour garantir le débit expedited — si votre plan de reprise dépend de restaurations expedited, cette dépendance doit être achetée, pas supposée. La mécanique complète est dans la documentation S3.

Quoi vérifier d’abord

  • Dans quelle classe les objets sont réellement. Flexible Retrieval et Deep Archive ont des paliers et des délais différents; Instant Retrieval n’exige aucune restauration.
  • Combien de données et combien d’objets. La récupération facture au Go et par millier de requêtes — un million de petits objets, c’est un problème de coût de requêtes, pas juste de bande passante.
  • La vraie échéance. « L’auditeur en a besoin cette semaine », c’est une tâche bulk. Ne payez pas le prix expedited pour une patience de palier standard.
  • Où vont les données ensuite. Restaurer pour lire une fois est différent de restaurer pour réhydrater en permanence — une restauration ne change pas la classe de stockage.

Comment vérifier

Confirmez la classe de stockage et toute restauration déjà en cours :

aws s3api head-object --bucket my-bucket --key backups/db-2025-11-01.tar.gz

Regardez StorageClass et le champ Restore : ongoing-request="true" signifie qu’une tâche roule; ongoing-request="false" avec une expiry-date signifie que la copie temporaire est lisible jusqu’à cette date. Pour trouver tout ce qui est archivé sous un préfixe :

aws s3api list-objects-v2 \
  --bucket my-bucket --prefix backups/ \
  --query 'Contents[?StorageClass==`DEEP_ARCHIVE`].[Key,Size]' \
  --output table

Le runbook

  1. Émettez la restauration avec un palier explicite et une fenêtre courte. Days est la durée pendant laquelle la copie temporaire reste lisible — vous payez le stockage en double pendant cette fenêtre, alors limitez-la au nécessaire :

    aws s3api restore-object \
  --bucket my-bucket \
  --key backups/db-2025-11-01.tar.gz \
  --restore-request '{"Days":7,"GlacierJobParameters":{"Tier":"Standard"}}'

  2. Pour des milliers d’objets, utilisez S3 Batch Operations, pas une boucle shell. Générez un manifeste (S3 Inventory fait très bien l’affaire — voir S3 Inventory et Storage Lens), puis créez une tâche de restauration Batch Operations dans S3 > Batch Operations > Create job. Elle réessaie les échecs et produit un rapport de fin; une boucle sur restore-object ne donne ni l’un ni l’autre.

  3. Faites-vous notifier au lieu de sonder. Configurez une notification d’événement sur s3:ObjectRestore:Completed vers SNS ou EventBridge. Sonder head-object sur une grosse restauration est lent et bruyant.

  4. Lisez ou copiez les données avant la fermeture de la fenêtre. La copie temporaire expire en silence. Si l’objectif est une réhydratation permanente, copiez l’objet sur lui-même vers la classe cible pendant qu’il est restauré :

    aws s3 cp s3://my-bucket/backups/db-2025-11-01.tar.gz \
  s3://my-bucket/backups/db-2025-11-01.tar.gz \
  --storage-class STANDARD

  5. Pour une vraie urgence sur une poignée d’objets, utilisez expedited — depuis Flexible Retrieval seulement. Mettez "Tier":"Expedited" dans la demande. En cas d’erreur de capacité insuffisante : réessayez, repliez-vous sur standard, ou achetez de la capacité provisionnée. Deep Archive n’a pas de palier expedited, point final — planifiez autour d’un plancher de 12 heures là-bas.

Quand ce n’est pas la bonne approche

Si les mêmes données sont restaurées plus d’une ou deux fois par année, elles sont dans la mauvaise classe — déplacez-les vers Glacier Instant Retrieval ou Standard-IA et cessez de payer le péage de restauration; les compromis sont dans Classes de stockage S3 décodées. Si l’échéance se compte réellement en minutes et que les données dorment en Deep Archive, aucun runbook ne règle ça — le choix de classe a déjà décidé du résultat. Et restaurer un compartiment entier de plusieurs téraoctets « pour chercher quelque chose », c’est la façon coûteuse de découvrir qu’il vous fallait un rapport d’inventaire.

Erreurs courantes

  • Restaurer avec "Days": 30 par défaut et payer un mois de stockage doublé pour un fichier lu une seule fois.
  • Scripter des restaurations expedited sur des milliers d’objets — la prime au Go se multiplie vite, et la capacité partagée peut vous rejeter en plein milieu.
  • Supposer qu’une restauration change la classe de stockage; l’objet reste archivé, et la copie temporaire expire en silence.
  • Bâtir un plan de reprise sur la récupération expedited sans capacité provisionnée, puis frapper des erreurs de capacité pendant un événement régional où tout le monde restaure en même temps.

Prévention

  • Écrivez la décision de restauration dans la décision d’archivage : avant que des données entrent en Deep Archive, documentez le délai de restauration acceptable et qui approuve une dépense expedited.
  • Gardez un rapport S3 Inventory sur les compartiments archivés pour bâtir des manifestes de restauration sans lister des millions de clés.
  • Testez une petite restauration bulk une fois par année — la mécanique, le chemin de notification et l’étape de copie.
  • Si la reprise dépend de restaurations rapides, chiffrez la capacité provisionnée dans le plan ou changez de classe de stockage.

Les restaurations Glacier sont prévisibles quand le palier correspond à l’échéance, et pénibles quand l’échéance n’a jamais été écrite. Si personne dans votre équipe ne possède vraiment l’environnement AWS de bout en bout, c’est la racine de la plupart de ces problèmes — Stack Harbor opère des comptes AWS au quotidien sous Opérations AWS, et vous pouvez réserver une revue AWS.