2026 : que faire en cas d’échec de la réécriture AOF de Redis 8.0 ? Vérifiez d’abord le disque et la chaîne de restauration

La réécriture AOF échoue et une alerte de stockage apparaît, mais le serveur contient encore des données en production.

Décision — la réécriture AOF de Redis 8.0 a échoué : vérifiez d’abord l’état de persistance, l’espace disponible et l’ensemble des fichiers ; ne supprimez pas l’AOF et ne redémarrez pas à l’aveugle. Validez ensuite la restauration sur une copie isolée.

Cet article est destiné aux DBA qui doivent déterminer si l’échec compromet une restauration, aux équipes d’application et d’exploitation qui évaluent une alerte de disque ou un redémarrage, ainsi qu’aux responsables qui planifient le stockage et les sauvegardes hors machine.

Dernière vérification : 4 novembre 2026. Le statut de Redis 8.0 et les règles de maintenance sont à revérifier dans la page officielle de gestion des versions Redis avant toute décision de mise à niveau.

Échec de réécriture AOF de Redis 8.0 : distinguez le symptôme de sa cause

Une réécriture AOF produit une représentation plus compacte des données persistées ; elle ne revient pas à supprimer sans risque les anciens fichiers à la main. Pendant l’opération, Redis doit continuer à servir les écritures et à préserver les données utiles à la persistance. Un espace libre qui semble suffisant au premier regard ne prouve donc ni que l’opération peut aboutir ni que les fichiers existants sont intacts. Les explications officielles sur la persistance et les fichiers AOF multiples décrivent cette relation entre les fichiers et la réécriture.

Commencez par séparer les situations suivantes, car elles n’appellent pas les mêmes actions :

Cette grille sert à orienter l’enquête, pas à poser un diagnostic à partir d’un seul symptôme. Une alerte de capacité ne démontre pas que l’AOF est corrompu ; inversement, un volume qui affiche de l’espace libre ne garantit pas que Redis puisse écrire correctement. Si les données sont seulement un cache reconstructible, la priorité opérationnelle peut différer de celle d’un service pour lequel Redis porte une responsabilité de persistance. Faites préciser cette responsabilité par l’équipe applicative avant d’accepter une perte ou une reconstruction.

Que faut-il examiner en premier après un échec ? L’état de persistance indiqué par Redis, la place disponible sur le système de fichiers qui héberge les données, les journaux et le processus de réécriture. Gardez les sorties et les journaux avant de modifier la configuration : ils peuvent distinguer un problème de capacité d’un échec d’écriture ou d’un processus toujours actif.

Pour obtenir un premier état sans lancer d’opération corrective :

redis-cli INFO persistence

Relevez les indicateurs de réécriture en cours, le statut de la dernière réécriture et le statut de la dernière écriture AOF. Les noms et interprétations des champs doivent être vérifiés dans la référence officielle de la commande INFO, en tenant compte de la version réellement exécutée. La commande BGREWRITEAOF déclenche une réécriture ; ce n’est pas un outil de réparation. Ne la relancez pas simplement pour faire disparaître une alerte sans avoir compris le premier échec.

Espace et inodes : calculez le besoin avant de toucher aux fichiers

Examinez le système de fichiers qui contient effectivement les fichiers Redis, et pas uniquement l’espace déclaré sur le volume brut ou le répertoire parent. Contrôlez aussi les montages, les quotas éventuels, les erreurs du noyau et la disponibilité des inodes. La documentation de df explique les informations remontées sur l’espace des systèmes de fichiers ; la sortie doit être lue dans le contexte des montages de votre serveur.

df -h /chemin/du/repertoire-redis
df -i /chemin/du/repertoire-redis
findmnt /chemin/du/repertoire-redis

Ces commandes servent à observer. Elles ne corrigent ni une saturation, ni une erreur d’écriture, ni un montage défaillant. Comparez le résultat avec la taille des fichiers Redis, l’évolution de l’espace libre et l’activité observée pendant l’incident. La réécriture peut demander de conserver simultanément des fichiers existants et ceux qui sont produits ; l’espace à prévoir dépend donc de l’état réel de votre instance et de l’évolution des écritures. Évitez de remplacer ce calcul par un coefficient universel : une valeur fixe ne tient pas compte de votre jeu de données, de la place déjà occupée ni de la configuration du stockage.

Que faire si le volume se remplit pendant la réécriture ? Préservez d’abord les fichiers Redis. Repérez les fichiers temporaires sans rapport avec l’instance et vérifiez qu’ils peuvent être supprimés selon les règles de votre exploitation ; sinon, évaluez l’extension du stockage ou le déplacement contrôlé des données. Ne supprimez pas un fichier AOF utilisé et ne modifiez pas le manifeste pour libérer de la place : vous pourriez rendre la chaîne de restauration incohérente.

Vous pouvez aussi examiner la configuration de persistance, mais sans la modifier pour contourner l’incident. La documentation de CONFIG SET précise la portée de cette commande ; une modification dynamique qui semble débloquer l’écriture peut changer le comportement attendu après redémarrage. Consignez la valeur initiale, la raison du changement et le moyen de revenir en arrière avant d’envisager une telle action.

Processus actif ou bloqué : croisez plusieurs signaux

Quand l’espace semble disponible, vérifiez si la réécriture est toujours en cours et si les écritures AOF sont signalées comme réussies. L’état Redis doit être rapproché des processus du système, de l’activité du stockage et des journaux. Un processus visible ne prouve pas que l’opération progresse ; un indicateur isolé ne révèle pas non plus la cause d’un arrêt apparent.

ps -eo pid,stat,etime,cmd
iostat -xz
journalctl -k --since "30 minutes ago"

Adaptez les outils à votre système et à votre politique de conservation des journaux. Si un outil d’observation manque ou si ses unités ne sont pas familières à l’équipe, ne déduisez pas une panne de stockage d’une seule ligne de sortie. Conservez plutôt les horodatages, l’état Redis et les événements système dans le même dossier d’incident. Cela aide à vérifier si l’erreur d’écriture précède l’échec de réécriture, si la tâche évolue encore ou si un événement de montage a coïncidé avec le problème.

Les discussions communautaires ou les rapports isolés peuvent signaler des cas à examiner, mais ne suffisent pas à établir que Redis 8.0 présente un défaut général. La version, le système de fichiers, la configuration et le mode de déploiement peuvent différer. Sans élément reproductible, gardez le diagnostic ouvert et documentez les versions, la construction utilisée et les journaux pertinents avant de choisir une correction.

Fichiers AOF incomplets : préservez l’original et réparez une copie

Redis peut gérer plusieurs fichiers AOF ; une sauvegarde cohérente ne consiste donc pas forcément à copier un fichier portant l’extension attendue. Il faut identifier l’ensemble concerné, notamment le manifeste, le fichier de base et les fichiers incrémentaux utilisés par l’instance. La documentation officielle sur la persistance et les fichiers AOF multiples décrit leur rôle. Une copie partielle, ou constituée à des moments différents alors que Redis écrit encore, peut ne pas représenter un état restaurable.

Comment copier complètement un AOF à fichiers multiples utilisé avec Redis 7 et versions ultérieures ? Identifiez le répertoire de persistance configuré et tous les éléments référencés par le manifeste, puis utilisez une méthode qui préserve un état cohérent : par exemple une sauvegarde adaptée à votre système, ou une procédure contrôlée qui empêche les écritures pendant la copie. Vérifiez que l’ensemble copié comprend les composants attendus par le manifeste. Ne supposez pas qu’un simple cp lancé pendant l’activité suffit à produire une sauvegarde cohérente.

Avant d’essayer une réparation, conservez l’original sans le modifier et créez une copie de travail. Si vous utilisez redis-check-aof, vérifiez les options prises en charge par la version concernée et appliquez une éventuelle correction à cette copie uniquement :

redis-check-aof /chemin/vers/la-copie-aof

La documentation officielle consacrée à l’inspection et à la réparation AOF doit guider le choix du fichier et des options, car une réparation peut écarter une partie finale endommagée. Notez précisément les fichiers traités, les options utilisées et les messages de sortie. La réussite de l’outil signifie qu’il a terminé son opération ; elle ne prouve pas que les données métier attendues sont toutes présentes.

Ne supprimez pas à la main des entrées du manifeste et ne déduisez pas un ordre de fichiers à partir de leurs seuls noms. Si la structure ou le comportement diffère de la documentation applicable à votre version, arrêtez la manipulation et demandez une revue technique à partir d’une copie.

Restauration douteuse : testez le résultat hors production

Une copie de sauvegarde lisible n’est pas encore une restauration validée. Lancez Redis dans un environnement isolé, à partir d’une copie et avec une configuration maîtrisée, sans accès involontaire aux données ou aux clients de production. Vérifiez que le jeu de données est chargé, puis comparez les résultats aux invariants de l’application : types de clés attendus, clés essentielles, comportement d’expiration et données de flux lorsqu’ils sont utilisés.

Distinguez le chemin de restauration AOF de celui fondé sur un instantané RDB. Un résultat acceptable avec l’un ne démontre pas que l’autre sauvegarde est exploitable. Les mécanismes et compromis généraux de persistance sont présentés dans la documentation Redis sur la persistance. Lorsque vous comparez les jeux de données, tenez compte du moment où chaque sauvegarde a été créée et des écritures attendues après cet instant. Une différence peut découler du point de restauration visé ; elle ne doit pas être déclarée sans importance sans validation applicative.

Comment confirmer qu’un AOF réparé permet réellement la restauration ? Démarrez une instance isolée avec la copie réparée, contrôlez son état et faites exécuter par l’application ou par des tests représentatifs les vérifications de données qui comptent pour votre service. Le contrôle doit couvrir les données et leur comportement, pas uniquement l’absence d’erreur au démarrage. Tant que ces vérifications échouent ou restent incomplètes, ne remplacez pas les fichiers de production et ne déclarez pas la restauration complète.

Décision de stockage : séparez capacité, redondance et sauvegarde

Choisissez la suite à donner selon ce que les contrôles ont établi, et non selon l’hypothèse qu’un changement de serveur résoudra une erreur AOF. Cette liste sert de décision opérationnelle :

• Si le système de fichiers manque réellement d’espace et que les fichiers sont cohérents, alors libérez uniquement des éléments sans lien avec Redis ou augmentez la capacité ; sinon, conservez l’état des fichiers et cherchez une autre cause.
• Si les erreurs système montrent un problème de stockage, alors suspendez les opérations risquées et faites examiner le montage et le périphérique ; sinon, confrontez les indicateurs Redis aux processus et aux journaux avant toute modification.
• Si une copie complète restaure les données attendues dans un environnement isolé, alors préparez une procédure de retour en service avec validation applicative ; sinon, gardez l’original intact et poursuivez l’analyse.
• Si votre sauvegarde dépend uniquement du même serveur, alors ajoutez une copie hors machine et exercez sa restauration ; sinon, vérifiez que cette copie indépendante est effectivement exploitable.
• Si Redis 8.0 reste en service, alors inscrivez la révision de version dans votre plan de maintenance ; dans tous les cas, ne considérez pas une mise à niveau comme un substitut à la sauvegarde.

Au 4 novembre 2026, la page de gestion des versions Redis indique le 1er décembre 2026 comme date de fin de support de Redis 8.0. Confirmez ce statut dans la source officielle au moment de planifier votre maintenance : une échéance de support motive une revue de version, mais ne démontre pas que la réécriture a échoué à cause de la version.

Une machine dédiée ne crée pas automatiquement de redondance. Sans RAID matériel, vous devez choisir votre propre stratégie, par exemple une duplication logicielle ou la réplication, et maintenir des sauvegardes hors machine. Le stockage direct peut aider à adapter la disposition des données, mais il ne protège ni contre une suppression accidentelle ni contre une copie incohérente.

Pour examiner un serveur physique, comparez les caractéristiques disponibles sur la page d’accueil d’OSFP Cloud à vos besoins réels : les configurations présentées incluent deux NVMe de 1 To en accès direct, sans RAID matériel, et des options d’ajout de stockage. Ces caractéristiques peuvent servir à planifier capacité et organisation des fichiers ; elles ne constituent ni une restauration Redis ni une garantie de conservation des données. Pour le choix entre capacité, disposition et protection, consultez également les éléments de planification du stockage et de la mémoire et vérifiez la fiche produit applicable avant de décider.

Si Redis est un cache reconstructible, que votre charge reste modeste et que vous ne souhaitez pas gérer sauvegardes, mises à niveau et incidents de stockage, une offre de base de données gérée ou un environnement partagé peut être plus adapté qu’un serveur physique. En revanche, si vous avez besoin de ressources matérielles dédiées et que votre équipe sait exploiter Redis, un serveur physique loué peut éviter le partage des ressources de calcul avec d’autres locataires. Il ne supprime toutefois ni les limites d’une copie AOF incohérente, ni le besoin de réplication, ni la nécessité de tester la restauration.

Avant de retenir une configuration chez OSFP Cloud, confrontez donc les options de stockage réellement proposées à votre estimation d’espace et à votre plan de sauvegarde hors machine. Choisissez le matériel pour répondre à un besoin de capacité ou d’exploitation clairement établi ; gardez la réparation AOF, la validation isolée et la sauvegarde comme des opérations distinctes.