échec du délai d'expiration pour la récupération d'archives Glacier après 5 heures

Samoar 40 Points de réputation
2026-09-25T14:50:04.69+00:00

Nous rencontrons un problème avec un job de récupération d'archives AWS Glacier qui n'arrive pas à se terminer dans la fenêtre de 5 heures. Le système renvoie une erreur de timeout lors de l'exécution de l'événement asynchrone, ce qui semble bloquer la fin du traitement par le service.

Cela nous empêche de récupérer les données nécessaires pour notre environnement.

Pourriez-vous nous aider à vérifier plusieurs points :

Comment pouvons-nous contrôler et ajuster notre stratégie de sondage (polling) pour mieux suivre l'état d'avancement du job ?

Serait-il possible de vérifier pourquoi l'événement asynchrone expire et comment nous pouvons augmenter les délais d'attente (timeouts) côté client ?

Quelles sont les meilleures pratiques pour gérer ce type d'échec de récupération sur des volumes de données volumineux ?

Quelles étapes devrions-nous suivre pour relancer la procédure de récupération sans risquer un nouveau timeout ?

Windows pour les entreprises | Windows 365 Entreprise
0 commentaires

1 réponse

Trier par : Le plus utile
Le plus utile Les plus récents Les plus anciens
  1. Tracy Le 13,050 Points de réputation Conseiller indépendant
    2026-09-25T15:40:27.54+00:00

    Bonjour Samoar,

    L échec après 5 heures provient généralement d une attente synchrone côté client HTTP qui dépasse le délai de socket, alors que la récupération Standard ou Bulk sur Amazon S3 Glacier peut nécessiter entre 3 et 12 heures selon le volume. Au lieu de maintenir une connexion ouverte ou d effectuer des requêtes de sondage trop fréquentes qui finissent par expirer, il est recommandé de dissocier le suivi du cycle de vie du job. Configurez des notifications d événement directes vers une file d attente Amazon SQS ou un sujet Amazon SNS lors de l initialisation de la requête de restauration.

    Côté applicatif ou script, augmentez les paramètres read_timeout et connect_timeout de votre client SDK au-delà des valeurs par défaut pour éviter les coupures prématurées lors des échanges d API. Dès que la notification de fin de traitement est reçue via la file SQS, déclenchez le téléchargement de l archive par blocs en utilisant des requêtes par plage d octets (Range GET) pour fiabiliser le transfert des gros volumes. Si ces recommandations vous permettent de mener à bien la récupération de vos archives, je vous invite à accepter la réponse.

    Tracy Le.

    Cette réponse a-t-elle été utile ?

    0 commentaires

Votre réponse

Les réponses peuvent être marquées comme « Acceptées » par l’auteur de la question et « Recommandées » par les modérateurs, ce qui aide les utilisateurs à savoir que la réponse a résolu le problème de l’auteur.