DBAtlas · Atlas d'exploitation des bases de données

Sauvegarde et restauration Redis (RDB, AOF, replica et cluster)

RedisNiveau: IntermédiaireDurée: 30–60 min

Met en place la sauvegarde d'un Redis ou Valkey installé (instance unique, master/replica avec Sentinel, ou Redis Cluster) et décrit la restauration à partir d'une sauvegarde. Étape par étape : sauvegardes RDB (règle save, BGSAVE, LASTSAVE, copie de dump.rdb) et AOF (BGREWRITEAOF, appendonlydir multi-fichiers en 7.x), sauvegarde depuis un replica, sauvegarde de tous les masters d'un Cluster, restauration de test sur une instance temporaire, restauration sur place sans tomber dans le piège de la priorité de l'AOF, et sauvegarde planifiée avec rétention et copie distante via systemd timer / cron ; on obtient au final une sauvegarde qui s'exécute régulièrement et dont la restauration a été testée. La réplication (Sentinel, Cluster) ne remplace pas une sauvegarde : une donnée supprimée par erreur se propage à tous les replicas. L'installation et l'exploitation courante sont traitées dans des guides Redis distincts.

Topologie: Instance unique, replica ou serveur Redis Cluster (Redis 7.2 / 8.x, Valkey)

Avant de commencer

  • … tourne et requirepass est défini dans le fichier de configuration … (le mot de passe est lu dans ce fichier). L'installation doit avoir utilisé les chemins du guide DBAtlas …Redis Cluster…Redis Sentinel… ; s'ils diffèrent, adaptez les chemins.
  • … se trouve sur un disque distinct du disque de données ou sur un partage réseau ; espace libre d'au moins la taille des données en mémoire (used_memory) multipliée par la durée de rétention. Le répertoire de données doit aussi disposer d'assez d'espace libre pour que BGSAVE écrive le nouveau RDB.
  • BGSAVE/BGREWRITEAOF fonctionnent par fork : selon l'intensité des écritures, de la mémoire supplémentaire est nécessaire (copy-on-write). vm.overcommit_memory = 1 doit être défini ; sinon le fork échoue avec "Can't save in background: fork: Cannot allocate memory".
  • Les commandes utilisées pour la sauvegarde (CONFIG, BGSAVE, LASTSAVE, BGREWRITEAOF…, CLUSTER, SYNC…) ne sont pas désactivées par rename-command, et l'utilisateur propriétaire du mot de passe (default) peut les exécuter.
  • Vous disposez des droits root ou sudo. Si une restauration sur place est prévue, une fenêtre de maintenance a été obtenue et l'équipe applicative informée.

Phases du guide

  • Paramètres de persistance actuels — Examiner la persistance et le rôle · Définir la règle save RDB · Activer l'AOF à chaud · Préparer le répertoire de sauvegarde
  • Sauvegarde RDB — Vérifier que le replica est à jour · Prendre un RDB récent avec BGSAVE · Copier dump.rdb dans le répertoire de sauvegarde et le vérifier · Lister les masters du Cluster · Prendre un RDB de chaque master (--rdb)
  • Sauvegarde AOF — Compacter l'AOF (BGREWRITEAOF) · Sauvegarder appendonlydir · Vérifier les fichiers AOF
  • Restauration de test (instance temporaire) — Ouvrir le RDB sur une instance temporaire · Comparer avec la source et arrêter l'instance temporaire · Ouvrir la sauvegarde AOF sur une instance temporaire
  • Restauration sur place — Arrêter le service et mettre de côté les fichiers actuels · Mettre en place la sauvegarde RDB · Désactiver temporairement l'AOF · Mettre en place la sauvegarde AOF · Démarrer le service et vérifier les données · Réactiver l'AOF à chaud …
  • Sauvegarde planifiée et rétention — Écrire le script de sauvegarde · Rendre le script exécutable · Préparer l'accès SSH au serveur distant · Créer le service et le timer systemd · Déclencher manuellement la sauvegarde planifiée et la vérifier · Écrire la tâche cron …
  • Supervision — Surveiller la persistance et l'âge des sauvegardes · Exercice de restauration régulier
Ouvrir le plan pas à pas adapté à votre environnement →