Sauvegarde et restauration Redis : procédures et exemples pratiques, sûrs et compatibles selon les versions

Intro

Ce guide explique comment sauvegarder et restaurer Redis en toute sécurité avec des procédures concrètes, adaptées aux versions. Vous allez inventorier votre environnement, choisir l’action la plus petite et sûre, prendre des sauvegardes cohérentes RDB et/ou AOF, les vérifier, puis pratiquer des restaurations sur une instance isolée avant toute action en production. Les exemples couvrent les serveurs autonomes, les réplicas, Redis Cluster, Docker/Kubernetes et les services managés.

Terminologie utilisée à la première mention :

RDB (Redis Database) : format d’instantané binaire de Redis, adapté aux sauvegardes complètes périodiques.
AOF (Append Only File) : journal d’écriture séquentiel, utile pour un point de reprise plus fin.

Principes appliqués tout au long :

Observer d’abord, changer ensuite.
Limiter le rayon d’impact : utiliser une réplique ou un nœud de restauration jetable.
Protéger les secrets : utiliser des espaces réservés, lier à localhost lors des tests.
Vérifier chaque étape et définir à l’avance le parcours de reprise.

Inventaire de la version et de l’environnement

Identifiez précisément ce que vous sauvegardez avant d’exécuter la moindre commande. Commencez par des observations en lecture seule.

Prérequis (les espaces réservés sont des exemples) :

Accès : redis-cli -h <host> -p <port> -a <password> (ou --user <acl_user> --pass <password> si ACL). ACL (Access Control List) : mécanisme de contrôle d’accès par listes d’autorisations.
Accès au shell de l’OS pour copier des fichiers ou prendre des instantanés de volumes
Espace disque suffisant pour une copie complète de RDB/AOF plus la compression

Déterminer la version et la topologie

redis-cli -h <host> -p <port> -a <password> INFO server | head -n 20
redis-cli -h <host> -p <port> -a <password> ROLE

Attendu :

redis_version : notez la version exacte (p. ex., 6.2.14, 7.0.x).
ROLE : master, slave (réplique), ou master avec des lignes de cluster sur les nœuds Cluster.

Identifier le mode de persistance et l’emplacement des fichiers

redis-cli -h <host> -p <port> -a <password> INFO persistence
redis-cli -h <host> -p <port> -a <password> CONFIG GET dbfilename
redis-cli -h <host> -p <port> -a <password> CONFIG GET appendonly
redis-cli -h <host> -p <port> -a <password> CONFIG GET appendfilename
redis-cli -h <host> -p <port> -a <password> CONFIG GET dir

À enregistrer :

RDB : dbfilename (p. ex., dump.rdb)
AOF : appendonly yes|no, appendfilename (p. ex., appendonly.aof)
Répertoire de données : dir

Capacité et vérifications de sécurité (niveau OS)

Assurez-vous que l’espace libre ≥ 2× le plus gros fichier de persistance dans <dir>
Confirmez les permissions pour lire dans <dir> et écrire vers la destination de sauvegarde
En Cloud/managé, identifiez leur fonctionnalité d’instantané et la rétention

Note sur le rayon d’impact : pour les instances à fort volume d’écriture, prenez les sauvegardes depuis une réplique pour éviter les pointes de latence sur le primaire.

Chemin de configuration sûr (sauvegardes)

Cette section propose les procédures de sauvegarde les plus petites et justifiées pour RDB et AOF avec vérification. Utilisez le chemin qui correspond à votre configuration.

Option A : sauvegarde par instantané RDB (recommandé par défaut)

Quand : RDB est activé ou acceptable pour des instantanés complets périodiques.

Changement minimal : déclenchez une sauvegarde en arrière-plan ou réutilisez le dernier instantané terminé, puis copiez le fichier RDB résultant.

Observer l’état actuel

redis-cli -h <host> -p <port> -a <password> INFO persistence | egrep 'rdb_bgsave_in_progress|rdb_last_save_time'
redis-cli -h <host> -p <port> -a <password> LASTSAVE

Déclencher un instantané non bloquant (de préférence sur une réplique)

redis-cli -h <host> -p <port> -a <password> BGSAVE

Attendu : Background saving started.

Attendre la fin et vérifier

watch -n 1 "redis-cli -h <host> -p <port> -a <password> INFO persistence | grep rdb_bgsave_in_progress"

Signal de fin : rdb_bgsave_in_progress:0 et un rdb_last_save_time plus récent.

Copier et vérifier le fichier

# Sur le serveur où Redis stocke les données
cd <dir>
cp dump.rdb /backups/redis/dump-$(date +%Y%m%dT%H%M%S).rdb
sha256sum /backups/redis/dump-*.rdb | tee -a /backups/redis/manifest.sha256
redis-check-rdb /backups/redis/dump-<timestamp>.rdb

Attendu : RDB looks OK.

Option B : sauvegarde AOF (pour un point de reprise proche de l’instant T)

Quand : appendonly yes est activé et que vous avez besoin d’un point de reprise plus serré.

Changement minimal : compacter l’AOF, puis copier le fichier compacté.

Observer

redis-cli -h <host> -p <port> -a <password> INFO persistence | egrep 'aof_enabled|aof_rewrite_in_progress|aof_last_rewrite_time_sec'

Demander une réécriture en arrière-plan

redis-cli -h <host> -p <port> -a <password> BGREWRITEAOF

Attendre la fin, puis copier et vérifier

cd <dir>
cp appendonly.aof /backups/redis/appendonly-$(date +%Y%m%dT%H%M%S).aof
sha256sum /backups/redis/appendonly-*.aof | tee -a /backups/redis/manifest.sha256
redis-check-aof /backups/redis/appendonly-<timestamp>.aof

Conseil : de nombreuses équipes conservent à la fois des RDB périodiques et un AOF continu pour équilibrer les instantanés complets et un RPO plus court. RPO (Recovery Point Objective) : durée maximale de données que l’on accepte de perdre.

Option C : diffusion d’un RDB sans accès au système de fichiers

Quand : vous ne pouvez pas lire le système de fichiers du serveur (p. ex., Redis managé).

redis-cli -h <host> -p <port> -a <password> --rdb /backups/redis/streamed-$(date +%Y%m%dT%H%M%S).rdb
redis-check-rdb /backups/redis/streamed-<timestamp>.rdb

Remarque : cette méthode utilise le protocole de réplication pour diffuser un instantané complet ; elle peut être lourde pour la source. Privilégiez une exécution sur une réplique.

Notes Docker et Kubernetes

Docker autonome :
Les données sont généralement dans /data à l’intérieur du conteneur. Vérifiez avec CONFIG GET dir.
Copiez avec : docker cp <container_id>:/data/dump.rdb /backups/...
Exécutez de préférence BGSAVE/BGREWRITEAOF avant le docker cp.

Kubernetes :
Utilisez kubectl exec pour lancer les vérifications redis-cli.
Si vous utilisez un PersistentVolumeClaim (PVC, PersistentVolumeClaim), privilégiez un instantané de volume au niveau du stockage pour l’atomicité.
Sinon, lancez BGSAVE, attendez la fin, puis copiez depuis le chemin de données du pod.

Redis Cluster et Sentinel

Sentinel : sauvegardez chaque instance primaire comme un autonome. Les réplicas sont des sources idéales de sauvegarde.
Cluster : sauvegardez chaque nœud maître individuellement. Une restauration complète exige la restauration de l’ensemble des données des maîtres couvrant tous les hash slots. Ne copiez pas nodes.conf entre environnements ; laissez Redis le régénérer.

Vérification et diagnostics (exercices de restauration)

Entraînez-vous à restaurer sur un hôte ou un conteneur isolé avant un incident. Liez l’instance à localhost et utilisez un port non standard.

Exercice de restauration RDB

Créer un répertoire propre et copier un RDB choisi

mkdir -p /restore-test/redis
cp /backups/redis/dump-<timestamp>.rdb /restore-test/redis/dump.rdb

Démarrer un Redis jetable en utilisant ce répertoire

redis-server --port 6380 --bind 127.0.0.1 \
  --dir /restore-test/redis --dbfilename dump.rdb \
  --appendonly no

Vérifier le contenu

redis-cli -p 6380 INFO server | grep redis_version
redis-cli -p 6380 DBSIZE
redis-cli -p 6380 INFO keyspace
# Échantillonner des clés sans reproduire des schémas bloquants de production
redis-cli -p 6380 --scan | head -n 20
# Vérifier les TTL sur des clés échantillons (TTL, Time To Live : durée de vie d’une clé)
redis-cli -p 6380 TTL <sample_key>

Attendu : DBSIZE et INFO keyspace correspondent approximativement aux attentes de la source au moment de la sauvegarde.

Exercice de restauration AOF

Préparer le répertoire et copier l’AOF

mkdir -p /restore-test/redis
cp /backups/redis/appendonly-<timestamp>.aof /restore-test/redis/appendonly.aof

Démarrer Redis en mode AOF

redis-server --port 6381 --bind 127.0.0.1 \
  --dir /restore-test/redis --appendonly yes --appendfilename appendonly.aof

Vérifier comme ci-dessus avec DBSIZE, SCAN et des contrôles d’échantillons TTL.

Signaux de diagnostic à suivre

Journaux : lignes de fin de sauvegarde/réécriture en arrière-plan, erreurs comme permission refusée ou OOM. OOM (Out Of Memory) : manque de mémoire.
INFO persistence : rdb_bgsave_in_progress, aof_rewrite_in_progress, dernières durées et erreurs.
Empreintes de fichiers : comparez entre copies de sauvegarde pour garantir l’intégrité.

Modes de défaillance et reprise

Échec de BGSAVE avec erreurs mémoire ou signaux
Signal 9 (OOM killer) ou Cannot allocate memory : utilisez une réplique pour les sauvegardes, libérez de la mémoire, ou réduisez maxmemory durant la fenêtre. Assurez de l’espace disque pour les fichiers temporaires.
Reprise : libérer de l’espace, arrêter les tâches d’arrière-plan lourdes, relancer BGSAVE sur une réplique.

Réécriture AOF qui n’aboutit jamais
Cause : charge d’écriture élevée, seuil auto-aof-rewrite-percentage trop bas déclenchant des réécritures fréquentes.
Reprise : suspendre temporairement les tentatives BGREWRITEAOF, réessayer en période creuse, ou sauvegarder l’AOF courant tel quel et vérifier avec redis-check-aof.

Fichiers corrompus ou copies partielles
Symptôme : erreurs redis-check-rdb/aof.
Reprise : recopier après avoir confirmé la fin de l’opération d’arrière-plan ; pour AOF, redis-check-aof --fix peut tronquer une fin invalide (accepter une perte potentielle des dernières commandes).

Incompatibilité de version lors de la restauration
Un RDB plus récent peut ne pas se charger sur un Redis beaucoup plus ancien.
Reprise : restaurer sur un Redis de version égale ou plus récente, ou mettre à niveau la cible.

Pièges de restauration en Cluster
Restaurer seulement certains maîtres conduit à un jeu de données incomplet.
Reprise : restaurer les instantanés/AOF de tous les maîtres depuis un même point cohérent. Recréer les clusters avec des nodes.conf neufs. Valider la couverture des slots après restauration.

Régressions de sécurité lors des tests de restauration
Symptôme : instance restaurée accessible sans authentification.
Reprise : lier à 127.0.0.1, définir requirepass ou des ACL sur l’instance de test, et éviter d’exposer des ports non production.

Liste de contrôle opérationnelle

Pré-vol (lecture seule) :

Noter : redis_version, topologie (ROLE), mode de persistance (RDB/AOF), dir, noms de fichiers.
Confirmer l’espace disque et les permissions à la source et à la destination de sauvegarde.
Choisir le nœud de sauvegarde (privilégier une réplique) et une fenêtre calme si nécessaire.

Étapes de sauvegarde RDB :

BGSAVE sur le nœud choisi.
Attendre rdb_bgsave_in_progress:0 et un LASTSAVE mis à jour.
Copier <dir>/<dbfilename> vers /<backup_root>/redis/dump-<timestamp>.rdb.
sha256sum et redis-check-rdb.
Enregistrer les métadonnées : horodatage, hôte source, version de Redis, taille du fichier, empreinte.

Étapes de sauvegarde AOF :

BGREWRITEAOF sur le nœud choisi.
Attendre aof_rewrite_in_progress:0.
Copier <dir>/<appendfilename> vers /<backup_root>/redis/appendonly-<timestamp>.aof.
sha256sum et redis-check-aof.

Exercice de restauration (hors production) :

Démarrer un Redis isolé sur le port 6380/6381 en chargeant le fichier copié.
Vérifier avec DBSIZE, INFO keyspace, SCAN échantillonné et contrôles de TTL.
Documenter comment promouvoir cette instance si nécessaire (arrêt des écritures sur la source, permutation des endpoints, ou utilisation de la réplication pour rattraper).

Rotation et rétention :

Conserver plusieurs générations (p. ex., 7 quotidiennes, 4 hebdomadaires, 3 mensuelles).
Chiffrer au repos et en transit ; restreindre l’accès aux dépôts de sauvegarde.
Tester périodiquement une restauration complète à partir de la sauvegarde la plus ancienne conservée.

Conseils d’automatisation :

Regrouper BGSAVE/BGREWRITEAOF, copie de fichier, empreinte et vérification dans un script unique avec des codes de sortie clairs.
Envoyer les journaux et fichiers de manifeste vers votre système de supervision.

Conclusion

Des sauvegardes Redis fiables reposent sur des observations adaptées aux versions, l’action de sauvegarde la plus sûre et des restaurations vérifiées. Commencez par inventorier votre version, votre topologie et votre mode de persistance. Prenez un instantané RDB et, si nécessaire, un AOF compacté depuis une réplique. Vérifiez les fichiers avec des empreintes et redis-check-*, puis exercez des restaurations sur un port isolé avant de toucher à la production. Avec une courte liste de contrôle répétable et des exercices réguliers, votre équipe disposera d’options de reprise claires en cas d’incident.