Installer Redis 8 sur Linux et configurer RDB + AOF pas à pas

📌 Article principal de la série : Redis 8 : caching, queues, pub/sub et streams pour applications production

Une installation Redis propre, durable et observable est le socle de toute architecture qui s’appuie sur ce moteur. Ce tutoriel guide pas à pas l’installation de Redis 8.6 sur un serveur Linux (Ubuntu 24.04 LTS et Debian 12 sont les références ; les commandes sont identiques sur Linux Mint et Pop!_OS), la configuration des deux mécanismes de persistance — RDB et AOF — et le durcissement de base avant exposition au réseau. À la fin, vous disposerez d’un Redis 8 fonctionnel, persistant, authentifié et prêt à recevoir du trafic applicatif.

Prérequis

• Un serveur Linux Ubuntu 24.04 LTS, Debian 12 ou équivalent
• Un utilisateur avec accès sudo
• Connexion réseau pour télécharger les paquets ou compiler depuis les sources
• Au moins 512 Mo de RAM disponibles (recommandé : 2 Go pour un usage de cache modéré)
• Temps estimé : 40 minutes

Étape 1 — Choisir la méthode d’installation

Trois voies existent pour installer Redis sur un serveur Linux moderne : le paquet officiel Redis publié par Redis Inc., le paquet de la distribution (Ubuntu ou Debian), ou la compilation depuis les sources. Le paquet officiel Redis est la voie recommandée car il fournit Redis 8.6 dès aujourd’hui — alors que la version embarquée dans Ubuntu 24.04 reste sur Redis 7.x — et il inclut le module Redis Search et Redis JSON par défaut. Le dépôt est signé et maintenu par Redis Inc., donc fiable et à jour.

# Installer les prérequis et la clé GPG du dépôt Redis
sudo apt update
sudo apt install -y lsb-release curl gpg

curl -fsSL https://packages.redis.io/gpg | sudo gpg --dearmor -o /usr/share/keyrings/redis-archive-keyring.gpg

echo "deb [signed-by=/usr/share/keyrings/redis-archive-keyring.gpg] https://packages.redis.io/deb $(lsb_release -cs) main" \
  | sudo tee /etc/apt/sources.list.d/redis.list

sudo apt update
sudo apt install -y redis

Le script ajoute la clé GPG officielle dans le keyring système avec la syntaxe moderne signed-by (recommandée depuis Ubuntu 22.04), enregistre le dépôt avec le codename de la distribution (noble pour Ubuntu 24.04, jammy pour 22.04, bookworm pour Debian 12), met à jour l’index et installe le paquet. Vérifiez la version installée avec redis-server --version ; vous devez voir Redis server v=8.6 ou supérieur en mai 2026.

Étape 2 — Démarrer le service et tester

Le paquet Debian crée automatiquement un service systemd nommé redis-server, l’active au démarrage et le lance. Vérifiez ces trois points avant de continuer, car un service mal démarré silencieusement est l’erreur la plus fréquente sur les installations fraîches.

# Vérifier le statut systemd
sudo systemctl status redis-server

# Tester la connectivité en local avec redis-cli
redis-cli ping

# Lister les paramètres réseau actifs
redis-cli CONFIG GET bind
redis-cli CONFIG GET port

La commande ping doit retourner PONG. Si vous obtenez Could not connect to Redis at 127.0.0.1:6379, le service n’est pas démarré — exécutez sudo systemctl start redis-server et consultez les logs avec journalctl -u redis-server -n 50 pour identifier l’erreur de configuration. Par défaut, Redis n’écoute que sur 127.0.0.1 (loopback), ce qui est correct pour un déploiement avec serveur web et Redis sur la même machine.

Étape 3 — Comprendre le fichier de configuration

Le fichier de configuration principal est /etc/redis/redis.conf (Ubuntu/Debian). Il regroupe environ 2 000 lignes commentées qui couvrent l’intégralité des options : réseau, sécurité, persistance, mémoire, réplication, modules. Avant toute modification, faites une copie de sauvegarde — c’est la première règle de l’administration système.

sudo cp /etc/redis/redis.conf /etc/redis/redis.conf.original
sudo nano /etc/redis/redis.conf

Cette commande crée une copie horodatable du fichier original puis ouvre le fichier en édition avec nano. Les sections importantes pour ce tutoriel sont : # NETWORK (lignes 60-130, options bind, port, protected-mode), # SECURITY (lignes 1000-1100, options requirepass et ACL), # MEMORY MANAGEMENT (lignes 1200-1300, maxmemory et maxmemory-policy) et # SNAPSHOTTING + # APPEND ONLY MODE (persistance).

Étape 4 — Configurer la persistance RDB

RDB produit des snapshots binaires compacts à intervalles réguliers. La configuration par défaut active des snapshots conditionnels : sauvegarder si au moins une clé a changé en 3 600 secondes, ou si 100 clés ont changé en 300 secondes, ou si 10 000 clés ont changé en 60 secondes. Pour la plupart des cas d’usage cette politique est suffisante. Pour un usage en cache pur où les données peuvent être reconstruites depuis la source, vous pouvez désactiver RDB entièrement pour réduire la charge I/O.

# Dans /etc/redis/redis.conf, vérifiez les directives suivantes :
save 3600 1 300 100 60 10000
dbfilename dump.rdb
dir /var/lib/redis
rdbcompression yes
rdbchecksum yes

La directive save remplace les anciennes lignes séparées save 3600 1, save 300 100, save 60 10000 par une syntaxe condensée introduite en Redis 7. La compression LZF (rdbcompression yes) réduit la taille du fichier de 30 à 60 %, au prix d’un petit surcoût CPU lors du snapshot. Le checksum CRC64 (rdbchecksum yes) protège contre la corruption silencieuse du fichier. Le snapshot est écrit dans /var/lib/redis/dump.rdb par défaut.

Étape 5 — Activer la persistance AOF

AOF journalise chaque commande d’écriture dans un fichier texte qui peut être rejoué intégralement au redémarrage. C’est le mécanisme à privilégier dès que vos données ont une valeur métier — paniers de commande, sessions actives, files d’attente — car la fenêtre de perte de données est réduite à la seconde près au pire des cas.

# Activer AOF en plus de RDB
appendonly yes
appendfilename "appendonly.aof"
appendfsync everysec
no-appendfsync-on-rewrite no
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
aof-use-rdb-preamble yes

La directive appendfsync everysec est le compromis recommandé : Redis demande au noyau d’écrire le fichier sur disque toutes les secondes, ce qui limite la perte à une seconde de commandes en cas de crash brutal. La valeur always garantirait zéro perte mais à un coût de performance majeur (un appel système par écriture). La valeur no laisse le noyau décider, ce qui peut entraîner plusieurs secondes de perte. La réécriture automatique (auto-aof-rewrite-percentage 100) compacte le fichier en arrière-plan dès qu’il a doublé de taille depuis la dernière compaction. Avec aof-use-rdb-preamble yes (par défaut depuis Redis 5), le préambule du fichier AOF est en réalité un RDB binaire, ce qui accélère le rechargement au démarrage.

Après modification, rechargez la configuration et vérifiez :

sudo systemctl restart redis-server
redis-cli CONFIG GET appendonly
redis-cli CONFIG GET appendfsync
ls -lh /var/lib/redis/

La sortie doit montrer appendonly = yes, appendfsync = everysec, et la présence du fichier appendonly.aof dans /var/lib/redis/. Si AOF n’apparaît pas, vérifiez les permissions du répertoire avec sudo ls -la /var/lib/redis/ — il doit appartenir à l’utilisateur redis.

Étape 6 — Activer l’authentification

Par défaut, Redis 8 démarre en mode protégé (protected-mode yes) qui refuse les connexions externes sans authentification configurée. Néanmoins, dès que vous configurez bind 0.0.0.0 pour exposer Redis sur le réseau, l’authentification devient indispensable. Deux mécanismes coexistent : le mot de passe global requirepass (legacy mais toujours supporté) et le système ACL multi-utilisateurs (introduit en Redis 6, recommandé en production).

# Approche legacy : un mot de passe global
# Dans /etc/redis/redis.conf :
requirepass un-mot-de-passe-fort-et-long-de-30-caracteres-minimum

# Approche moderne : ACL avec un fichier dédié
aclfile /etc/redis/users.acl

L’approche ACL est largement préférable : elle permet de créer plusieurs utilisateurs avec des permissions distinctes (un utilisateur applicatif qui ne peut que lire/écrire ses clés, un utilisateur administrateur qui peut exécuter CONFIG, un utilisateur de monitoring qui ne peut que INFO). Pour la suite du tutoriel, on configure un utilisateur applicatif et on désactive l’utilisateur default.

sudo nano /etc/redis/users.acl

Insérez le contenu suivant :

user default off
user appuser on >motdepasse-applicatif-long ~* +@all -@dangerous
user monitoring on >motdepasse-monitoring +info +ping +client

Ce fichier déclare trois utilisateurs : default est désactivé (off) pour fermer la connexion anonyme ; appuser peut accéder à toutes les clés (~*) et toutes les commandes (+@all) sauf celles classées dangereuses (-@dangerous exclut FLUSHDB, FLUSHALL, DEBUG, CONFIG) ; monitoring ne peut qu’inspecter le serveur (+info +ping +client). Redémarrez Redis puis testez la connexion avec le bon utilisateur.

sudo systemctl restart redis-server
redis-cli --user appuser --askpass
# Saisir le mot de passe quand prompté, puis :
> SET test "ok"
> GET test
> CONFIG GET maxmemory
# Cette dernière commande doit échouer avec NOPERM

Si la commande CONFIG GET est refusée avec NOPERM this user has no permissions to run the 'config' command, votre ACL fonctionne correctement et le principe du moindre privilège est appliqué.

Étape 7 — Limiter la mémoire et définir la politique d’éviction

Sans limite, Redis peut consommer toute la RAM disponible jusqu’au OOM killer du noyau qui tuera le processus. Définir maxmemory et maxmemory-policy est obligatoire en production.

# Dans /etc/redis/redis.conf :
maxmemory 1gb
maxmemory-policy allkeys-lru
maxmemory-samples 5

La politique allkeys-lru évince automatiquement les clés les moins récemment utilisées quand la mémoire est pleine — c’est le bon choix pour un cache. Pour une base de données avec données critiques, choisissez noeviction qui refusera les nouvelles écritures plutôt que de supprimer des clés existantes, ou volatile-lru qui n’évincera que les clés ayant un TTL. La valeur maxmemory-samples 5 contrôle le nombre de clés échantillonnées pour décider de l’éviction LRU — Redis n’implémente pas un vrai LRU global (trop coûteux) mais une approximation par échantillonnage.

Étape 8 — Tester la persistance par redémarrage

La meilleure façon de valider votre configuration de persistance est de simuler un redémarrage et de vérifier que les données survivent. Voici le scénario complet :

# Insérer une donnée test
redis-cli --user appuser --askpass
> SET cle:1 "donnee-test"
> LPUSH file:emails "user1@example.com" "user2@example.com"
> HSET utilisateur:42 nom "Aïssa Diop" ville "Dakar" age 32
> EXIT

# Forcer un snapshot RDB et un flush AOF
redis-cli --user appuser --askpass BGSAVE
redis-cli --user appuser --askpass BGREWRITEAOF

# Vérifier la taille des fichiers de persistance
ls -lh /var/lib/redis/

# Redémarrer le service brutalement
sudo systemctl restart redis-server

# Vérifier que les données sont là
redis-cli --user appuser --askpass
> GET cle:1
> LRANGE file:emails 0 -1
> HGETALL utilisateur:42

Les trois données doivent réapparaître intactes. Si l’une manque, c’est qu’AOF n’avait pas encore flushé sur disque au moment du redémarrage. Vérifiez le timing de appendfsync et reproduisez en attendant deux secondes entre l’insertion et le redémarrage.

Étape 9 — Exposer Redis sur le réseau (avec précaution)

Si votre Redis doit être accessible depuis d’autres machines (workers Node.js sur des VPS séparés, applications Docker), il faut modifier le binding réseau. C’est le moment où la sécurité devient critique : un Redis exposé publiquement sans authentification est régulièrement scanné et exploité dans les 24 heures (le wiki HackTricks documente plusieurs payloads d’exploitation).

# Dans /etc/redis/redis.conf :
bind 0.0.0.0
protected-mode yes
port 6379

Couplez impérativement ce changement avec : (a) l’authentification ACL configurée à l’étape 6, (b) un pare-feu UFW qui n’autorise que les IPs des clients légitimes sur le port 6379, (c) idéalement TLS via tls-port 6380 pour chiffrer le transport. La configuration TLS dépasse le cadre de ce tutoriel mais la doc officielle Redis la couvre en détail.

sudo ufw allow from 10.0.0.0/8 to any port 6379 proto tcp
sudo ufw allow from 192.168.0.0/16 to any port 6379 proto tcp
sudo ufw enable

Cette politique limite l’accès au port 6379 aux réseaux privés (RFC 1918). Adaptez les plages CIDR à vos sous-réseaux réels. Pour un Redis hébergé chez un fournisseur cloud, utilisez plutôt les Security Groups (AWS), Firewall Rules (GCP) ou les listes d’IP autorisées du panneau d’administration. Ne jamais exposer Redis directement sur 0.0.0.0 sur internet public sans VPN ou tunnel SSH.

Étape 10 — Vérification finale et observabilité

Avant de considérer l’installation comme terminée, exécutez les vérifications suivantes qui sont les piliers d’une exploitation propre : disponibilité du service, persistance fonctionnelle, métriques de mémoire saines, et logs systemd sans erreur.

# 1. Service actif et redémarrage automatique configuré
sudo systemctl is-enabled redis-server
sudo systemctl is-active redis-server

# 2. Informations détaillées sur l'instance
redis-cli --user appuser --askpass INFO server | head -20
redis-cli --user appuser --askpass INFO memory | grep -E "used_memory_human|maxmemory_human|maxmemory_policy"
redis-cli --user appuser --askpass INFO persistence | grep -E "rdb_last_save|aof_enabled|aof_last_write_status"

# 3. Test de charge léger pour valider la performance
redis-benchmark --user appuser -a "motdepasse-applicatif" -t set,get -n 100000 -q

La sortie de redis-benchmark doit afficher au moins 50 000 ops/seconde sur SET et GET pour un serveur même modeste. Si vous obtenez moins de 10 000 ops/sec, vérifiez que vous n’avez pas activé appendfsync always par erreur, ce qui ferait chuter dramatiquement les performances d’écriture. Si tout est vert, votre Redis est opérationnel et prêt à recevoir du trafic applicatif.

Erreurs fréquentes

Tutoriels suivants

• Patterns de cache avec Redis 8 : cache-aside, write-through et TTL
• Queues asynchrones avec BullMQ 5.76 et Redis 8
• Redis Sentinel et Cluster : haute disponibilité production
• 🔝 Retour au pilier : Redis 8 : caching, queues, pub/sub et streams

FAQ

Faut-il préférer AOF à RDB ou utiliser les deux ?

La configuration recommandée en production combine les deux : AOF pour la durabilité fine (perte limitée à 1 seconde) et RDB pour la sauvegarde rapide à charger après un sinistre majeur. RDB seul convient si la perte de quelques minutes de données est acceptable (cache pur). AOF seul produit des fichiers volumineux et un rechargement plus lent.

Comment choisir maxmemory ?

Réservez 60 à 75 % de la RAM physique pour maxmemory. Redis a besoin de marge pour la fork() au moment des snapshots RDB (qui copie temporairement la mémoire), pour les buffers de réplication si Sentinel est actif, et pour le système d’exploitation. Sur une VM de 4 Go de RAM, maxmemory 2gb ou maxmemory 3gb est raisonnable.

Pourquoi Redis crashe au démarrage avec un message sur THP ?

Transparent Huge Pages, activé par défaut sur certaines distributions, provoque des latences imprévisibles avec Redis. Désactivez-le avec echo never | sudo tee /sys/kernel/mm/transparent_hugepage/enabled et rendez ce changement persistant via /etc/rc.local ou un service systemd dédié.

Comment migrer des données depuis un autre Redis ?

Trois options : (a) copier directement les fichiers dump.rdb et appendonly.aof dans /var/lib/redis/ du nouveau serveur après arrêt (méthode la plus simple) ; (b) utiliser redis-cli --rdb dump.rdb -h source-host pour télécharger un snapshot à chaud ; (c) configurer une réplication REPLICAOF pour synchroniser puis promouvoir le nouveau serveur.

Références

• Installer Redis sur Linux — Documentation officielle
• Persistance Redis : RDB et AOF — Documentation officielle
• ACL Redis 6+ — Documentation officielle
• Fichier redis.conf de référence (GitHub)