L’équipe de développement s’apprête à activer un drapeau de fonctionnalité qui change la forme des objets en cache dans Redis production. Le plan de repli est « si quelque chose tourne mal, on restaure le cluster depuis le snapshot quotidien de 04 h 00 ». Personne n’a réellement testé la restauration. L’ingénieur de garde pose la bonne question — « qu’est-ce que la restauration fait vraiment? » — et reçoit une réponse vague. La vraie réponse est qu’ElastiCache restaure en créant un nouveau cluster à partir du snapshot. Il n’écrase pas l’existant. Cela prend aussi 15 à 60 minutes selon la taille du cluster. Le plan de repli tel qu’écrit aurait causé plus d’indisponibilité que la panne contre laquelle il protégeait. Voici ce que les backups font vraiment.

Ce qui se passe

Les snapshots ElastiCache sont des sauvegardes ponctuelles du dataset Redis vers S3 (dans un bucket géré par AWS, pas un bucket client — ils sont exposés via l’API ElastiCache, pas S3 directement). Les snapshots sont pris via le mécanisme BGSAVE de Redis — un fork du processus principal écrit le fichier RDB en arrière-plan pendant que le cluster continue de servir le trafic. La performance de lecture n’est pas affectée; la latence d’écriture peut brièvement remonter durant le fork sur des nœuds sous forte pression mémoire.

Trois boutons contrôlent comment les snapshots se passent.

SnapshotRetentionLimit est le nombre de snapshots quotidiens automatiques qu’ElastiCache conserve. Valeurs de 0 à 35. Le mettre à 0 désactive les snapshots automatiques entièrement. Le mettre à 7 conserve une semaine de snapshots quotidiens roulants. Le mettre à 35 conserve la fenêtre maximale de 35 jours. Il n’y a pas d’option intégrée pour des snapshots horaires automatiques — quotidien est la granularité.

SnapshotWindow est la fenêtre de 60 minutes chaque jour pendant laquelle le snapshot automatique tourne. Choisissez une fenêtre durant un trafic d’écriture bas — le fork est moins coûteux quand la mémoire est stable. La fenêtre est en UTC. Une fenêtre 03:00–04:00 UTC est 22:00–23:00 EST.

Snapshots manuels sont initiés par l’utilisateur et n’ont pas de limite de compte (au-delà des quotas du compte AWS, typiquement généreux). Les snapshots manuels survivent à la suppression du cluster — si vous supprimez le cluster, les snapshots automatiques partent avec, mais les snapshots manuels restent jusqu’à ce que vous les supprimiez explicitement. C’est le patron « prendre un snapshot avant de faire quelque chose de risqué ».

La restauration est la partie qui surprend les gens. Il n’y a pas de restauration sur place. L’API de restauration prend un snapshot et crée un nouveau cluster à partir de lui. Le nouveau cluster a un endpoint différent. La configuration applicative doit changer pour pointer vers le nouveau cluster, ou vous devez repointer via DNS. L’ancien cluster est intouché. Vous pouvez supprimer l’ancien cluster après la vérification de la restauration, mais c’est une étape séparée.

Ce que les snapshots couvrent et ce qu’ils ne couvrent pas. Les snapshots sont des dumps au format RDB — chaque clé, chaque valeur, chaque TTL — capturés au moment du BGSAVE. Ils ne capturent pas les écritures en vol entre le début du BGSAVE et sa complétion (ces écritures n’iront dans le nouveau cluster que quand vous relancerez la charge contre lui). Ils ne capturent pas la configuration Redis qui vit dans le groupe de paramètres — celle-ci suit le cluster, pas le snapshot. Ils ne capturent pas les paramètres VPC, groupe de sous-réseaux ou groupe de sécurité — ce sont des propriétés de l’objet cluster, pas des données.

Pourquoi « repartir avec un cache vide » est parfois plus sûr. Si le cluster est corrompu à cause d’un mauvais patron d’écriture (un déploiement bogué a écrit des objets avec le mauvais schéma; un attaquant a empoisonné le cache; un FLUSHALL manuel a tourné en production), restaurer depuis le snapshot d’hier ramène le mauvais état tel qu’il existait à 04 h 00 — possiblement incluant la même corruption si elle s’est produite avant 04 h 00. L’alternative propre est de supprimer le cluster, en créer un nouveau vide, et laisser l’application reconstruire le cache au premier accès. Les premières minutes sont lentes (tempête de cache miss), mais le cache est prouvablement propre. C’est souvent le bon choix après un événement de corruption.

Comment vérifier

Trois commandes vous disent quels backups existent et s’ils sont utilisables.

Lister les snapshots automatiques et manuels.

aws elasticache describe-snapshots \
  --replication-group-id saas-prod \
  --query 'Snapshots[].[SnapshotName,SnapshotStatus,SnapshotSource,NodeSnapshots[0].SnapshotCreateTime]' \
  --output table

La sortie montre le nom du snapshot (généré par le système pour automatique, fourni par l’utilisateur pour manuel), le statut (available, creating, deleting), la source (automated ou manual), et l’heure réelle de création. Vérifiez trois choses : le compte correspond à votre SnapshotRetentionLimit, le snapshot automatique le plus récent date des 24 dernières heures, et tout snapshot manuel pré-changement est toujours présent.

Vérifier la fenêtre et la rétention de snapshot.

aws elasticache describe-replication-groups \
  --replication-group-id saas-prod \
  --query 'ReplicationGroups[].[ReplicationGroupId,SnapshotWindow,SnapshotRetentionLimit]' \
  --output table

Un cluster de production devrait avoir SnapshotRetentionLimit d’au moins 7. Un cluster avec 0 est silencieusement non assuré — il n’y a pas de snapshots automatiques et l’équipe ne s’en rend probablement pas compte.

Tester une restauration dans un compte non production. La seule façon de savoir qu’une restauration fonctionne est d’en faire une. Choisissez un snapshot récent, restaurez-le vers un nouveau nom de cluster, connectez-vous au nouveau cluster, vérifiez que quelques clés sont présentes :

aws elasticache create-replication-group \
  --replication-group-id saas-prod-restore-test \
  --replication-group-description "Test de restauration" \
  --snapshot-name saas-prod-2026-05-25-04-00 \
  --cache-node-type cache.r6g.xlarge \
  --num-cache-clusters 2 \
  --automatic-failover-enabled

Attendez qu’il devienne disponible (10–60 minutes selon la taille du snapshot), puis connectez-vous via le nouvel endpoint :

redis-cli -h saas-prod-restore-test.abc123.ng.0001.use1.cache.amazonaws.com PING
redis-cli -h saas-prod-restore-test.abc123.ng.0001.use1.cache.amazonaws.com DBSIZE
redis-cli -h saas-prod-restore-test.abc123.ng.0001.use1.cache.amazonaws.com KEYS 'sess:*' | head -5

DBSIZE devrait correspondre au compte approximatif du cluster source au moment du snapshot. Puis supprimez le cluster de test pour ne pas laisser une ressource oisive en marche.

La correction

Le patron opérationnel qui fonctionne pour les backups ElastiCache.

Étape 1 : régler la rétention à 7–14 jours pour les clusters de production. Le défaut est 0 à la création via certains chemins. Les clusters de production ont besoin de snapshots automatiques. Moins de 7 jours ne laisse pas de marge pour « on a découvert la corruption deux jours plus tard ».

aws elasticache modify-replication-group \
  --replication-group-id saas-prod \
  --snapshot-retention-limit 14 \
  --snapshot-window 03:00-04:00 \
  --apply-immediately

Le changement s’applique à la prochaine fenêtre de snapshot. Les snapshots existants sont conservés selon la nouvelle limite à partir de là.

Étape 2 : prendre un snapshot manuel avant tout changement risqué. « Risqué » inclut : changements de groupe de paramètres, mises à niveau de version du moteur, opérations de mise à l’échelle, changements de schéma dans les objets en cache, toute activation de drapeau de fonctionnalité qui affecte ce qui est écrit en cache.

aws elasticache create-snapshot \
  --replication-group-id saas-prod \
  --snapshot-name saas-prod-pre-feature-flag-2026-05-26

La création du snapshot tourne de manière asynchrone. Attendez que SnapshotStatus soit available avant de procéder au changement. Les snapshots manuels survivent à la suppression du cluster, ils servent donc aussi d’archive « avant qu’on supprime ce cluster ».

Étape 3 : documenter le plan de restauration. Chaque snapshot est inutile sans un chemin connu pour l’utiliser. Le plan doit inclure : quel snapshot restaurer (l’automatique du jour, ou le manuel pré-changement), le patron de nom du nouveau cluster, le groupe de paramètres et le groupe de sous-réseaux à appliquer, et comment la configuration applicative est repointée (swap CNAME Route 53, mise à jour de variable d’environnement avec déploiement, etc.). Testez le plan en préproduction avant de vous y fier en production.

Étape 4 : décider d’avance si corruption restaure ou reconstruit. Pour chaque cluster, décidez : si le cache est corrompu, est-ce qu’on restaure depuis le snapshot, ou est-ce qu’on reconstruit depuis vide? La décision dépend de ce que contient le cache.

Sessions : généralement reconstruire (les utilisateurs se réauthentifient; inconvénient mineur).
Réponses calculées avec une source de vérité dans la base de données : généralement reconstruire (la tempête de cache miss est brève; les données sont prouvablement propres).
Compteurs de limite de taux : généralement reconstruire (le pire cas est une brève fenêtre de taux autorisés plus élevés).
État autoritatif qui n’existe nulle part ailleurs (rare dans Redis mais arrive) : restaurer depuis le snapshot, en comprenant que les données entre le snapshot et la corruption sont perdues.

Le patron pré-décidé fait gagner du temps durant l’incident réel. L’ingénieur de garde qui a déjà pensé « on reconstruit ça depuis vide » ne perd pas 40 minutes à restaurer un snapshot qu’il allait jeter de toute façon.

Étape 5 : nettoyer les anciennes restaurations de test. Les tests de restauration laissent des clusters en marche. Ils ne sont pas gratuits. Construisez le test dans le runbook avec une étape de nettoyage à la fin — la restauration est vérifiée en listant 100 clés, en interrogeant quelques valeurs, et en confirmant DBSIZE. La vérification prend des minutes. Le nettoyage prend un appel API.

aws elasticache delete-replication-group \
  --replication-group-id saas-prod-restore-test

Le cadre à retenir : les snapshots sont une assurance, pas un bouton undo magique. La restauration prend du temps, crée un nouveau cluster, exige un repointage de configuration, et ramène parfois le même problème que vous essayiez de fuir. La version disciplinée de « on a des backups » est : snapshots automatiques configurés avec une rétention saine, snapshots manuels avant tout changement risqué, un chemin de restauration documenté et testé, et une réponse pré-décidée à « restaurer ou reconstruire » pour chaque rôle de cluster.

Stack Harbor conçoit les topologies Redis dans le cadre du travail sur le palier cluster en Gestion AWS et de la couche Clusters HA. Si le plan de backup de votre cluster est « on verra si ça arrive », commencez par une consultation d’infrastructure.