Comment sauvegarder un conteneur Docker Valkey (2026)
Sauvegarder Valkey en sécurité tient en une règle : dumper, ne pas copier. `valkey-cli SAVE # then capture the resulting dump.rdb` produit un dump cohérent et restaurable depuis le conteneur en cours d'exécution, que restic chiffre ensuite hors site. un SAVE/BGSAVE forke un instantané RDB à un instant précis sur le disque : vous sauvegardez donc le dump.rdb terminé (plus l'AOF si activé) plutôt que l'état volatil en mémoire. Tout ce qui copie /data à chaud risque une sauvegarde irrécupérable.
Ce que Dockstash détecte
| Clés d'environnement détectées | VALKEY_PASSWORD, VALKEY_ARGS, REDIS_PASSWORD |
|---|---|
| Port par défaut | 6379 |
| Chemins de données vivants (jamais copiés à chaud) | /data, /data/dump.rdb, /data/appendonly.aof |
| Exemples d'images | valkey/valkey:8, valkey/valkey:7, valkey/valkey |
Sauvegarder Valkey avec Dockstash, étape par étape
Créez votre compte Dockstash et ouvrez le tableau de bord
Inscrivez-vous gratuitement sur app.dockstash.com/register. L'assistant de configuration unique vous demande votre VPS de stockage (la machine qui hébergera les sauvegardes chiffrées) et génère un mot de passe de chiffrement — enregistrez-le immédiatement dans un gestionnaire de mots de passe, il n'est affiché qu'une seule fois.
Ajoutez le projet Docker qui exécute Valkey
Sur l'écran Projects, Dockstash détecte automatiquement chaque dossier de projet Compose du serveur (par défaut sous /var/www). Choisissez le projet qui contient votre service Valkey. Rien n'est encore sauvegardé — vous indiquez simplement à Dockstash où vit le projet.
Vérifiez que Valkey a bien été détecté
Ouvrez le projet et regardez l'onglet Plan. Dockstash lit docker-compose.yml, reconnaît l'image valkey/valkey et ajoute une couche base de données avec la bonne stratégie de sauvegarde-puis-capture — plus le nom du conteneur résolu et les clés d'environnement trouvées (VALKEY_PASSWORD, VALKEY_ARGS et l'ancienne REDIS_PASSWORD). Vous pouvez activer ou désactiver fichiers, bases de données et configs de proxy avant d'enregistrer.
Optionnel : testez l'instantané à la main
Si vous voulez une preuve avant d'automatiser, déclenchez la même sauvegarde que Dockstash : lancez valkey-cli BGSAVE dans le conteneur. Valkey répond « Background saving started », forke et écrit un dump.rdb à instant précis dans /data — la même persistance RDB héritée de Redis. C'est ce fichier terminé qui est sauvegardé, jamais l'état vivant en mémoire.
docker exec <valkey-container> valkey-cli BGSAVEConfirmez votre destination de stockage
Les sauvegardes sont stockées sous forme d'instantanés restic chiffrés sur votre propre VPS de stockage, via SSH. Si vous avez terminé l'assistant de configuration, c'est déjà en place ; vous pouvez changer l'hôte, l'utilisateur, le port ou la clé SSH à tout moment dans Settings → Storage.
Définissez une planification de sauvegarde
Dans l'onglet Schedule du projet, choisissez quotidien, hebdomadaire ou une expression cron personnalisée (validée en direct). Pour un Valkey utilisé comme stockage principal (files d'attente, sessions), le quotidien est un plancher raisonnable et l'horaire est courant. Ajoutez une planification de prune hebdomadaire avec votre politique de rétention.
Lancez la première sauvegarde maintenant
Cliquez sur Backup Now sur la carte du projet. Dockstash déclenche une sauvegarde en arrière-plan, attend le dump.rdb terminé, puis le sauvegarde — avec appendonly.aof quand la persistance AOF est activée — directement dans restic. Vous pouvez suivre la sortie restic en direct dans le panneau de logs.
Confirmez que l'instantané existe
À la fin de l'exécution, la carte du projet affiche la nouvelle date de dernière sauvegarde, le nombre d'instantanés et la taille du dépôt. Ouvrez l'écran Snapshots : le point de restauration apparaît dans la chronologie — c'est votre preuve que la sauvegarde est bien arrivée hors site.
La commande de dump
valkey-cli SAVE # then capture the resulting dump.rdbLa commande de restauration
place dump.rdb in the data dir and start valkey-serverun SAVE/BGSAVE forke un instantané RDB à un instant précis sur le disque : vous sauvegardez donc le dump.rdb terminé (plus l'AOF si activé) plutôt que l'état volatil en mémoire.
Restaurer une sauvegarde Valkey et prouver qu'elle fonctionne
Une sauvegarde Valkey ne devient réelle qu'une fois restaurée. Les restaurations Dockstash n'écrasent jamais votre instance vivante par défaut — vous restaurez d'abord vers un emplacement neuf, vous vérifiez les données, puis vous promouvez délibérément.
Choisissez un point de restauration
Ouvrez Snapshots, sélectionnez le projet et parcourez la chronologie des points de restauration. Chaque ligne contient un dump.rdb complet à instant précis (plus l'AOF si activé) et les fichiers du projet capturés lors de la même exécution.
Restaurez vers un nouvel emplacement
Cliquez sur Restore et gardez le mode par défaut « Restore to new location ». Tapez le nom du projet pour confirmer — une action délibérée à confirmation saisie. Le RDB et les fichiers atterrissent dans le chemin cible de votre choix, sans toucher à l'instance vivante.
Vérifiez les données restaurées
Placez le dump.rdb restauré dans le répertoire de données d'un conteneur Valkey de test et démarrez-le — Valkey charge le RDB au démarrage. Lancez valkey-cli PING : vous devez recevoir PONG, puis sondez les clés dont dépend votre application avec DBSIZE et quelques GET.
docker exec <valkey-container> valkey-cli PINGPromouvez une fois satisfait
Quand les données restaurées sont validées, pointez votre application dessus (ou répétez la restauration en mode « Overwrite existing » — un opt-in explicite — et redémarrez le conteneur vivant pour qu'il charge le RDB restauré). Mieux : laissez l'exercice de restauration hebdomadaire produire cette preuve automatiquement.
Pièges à éviter
- Comme avec Redis, ne capturez jamais un dump.rdb en cours de réécriture — déclenchez SAVE/BGSAVE d'abord et sauvegardez le fichier terminé.
- valkey-cli est le binaire client ; sur certaines images de compatibilité, redis-cli est un lien symbolique — Dockstash détecte celui qui est présent.
- Activez et capturez l'AOF quand il vous faut les écritures les plus fraîches ; le RDB seul peut être en retard.
Problèmes courants de sauvegarde Valkey
- Symptôme
- Le dump.rdb restauré ne se charge pas : erreur de fichier tronqué ou de lecture courte.
- Cause
- Le RDB a été copié pendant que Valkey le réécrivait — le même risque de mi-réécriture que Redis, puisque Valkey conserve un modèle de persistance RDB identique.
- Correctif
- Déclenchez toujours SAVE ou BGSAVE et attendez la fin avant de capturer dump.rdb. Dockstash fait exactement cela : il déclenche la sauvegarde, attend la fin, puis sauvegarde le fichier terminé.
- Symptôme
- Un test manuel avec redis-cli fonctionne mais valkey-cli répond « not found » (ou inversement).
- Cause
- Le binaire client varie selon l'image : les images officielles valkey/valkey fournissent valkey-cli, tandis que certaines images de compatibilité créent un lien redis-cli.
- Correctif
- Utilisez le binaire fourni par l'image — protocole et commandes sont identiques. Dockstash détecte automatiquement le client présent dans le conteneur, la sauvegarde fonctionne dans les deux cas.
- Symptôme
- Vous avez placé le dump.rdb restauré dans /data mais le Valkey en marche sert toujours les anciennes données.
- Cause
- Comme Redis, Valkey ne lit le RDB qu'au démarrage — impossible de l'échanger à chaud. Et si appendonly est activé, l'AOF prime au démarrage et le RDB est ignoré.
- Correctif
- Arrêtez le conteneur, placez le dump.rdb restauré (et l'AOF le cas échéant) dans le répertoire de données, puis redémarrez. Si vous n'avez restauré qu'un RDB dans une configuration AOF, mettez temporairement appendonly no pour le premier démarrage, puis réactivez.
- Symptôme
- La restauration réussit mais les écritures les plus récentes manquent.
- Cause
- La persistance AOF est activée et appendonly.aof contenait des écritures plus récentes que l'instantané RDB — le RDB seul est en retard.
- Correctif
- Sauvegardez les deux fichiers. Dockstash capture /data/dump.rdb et appendonly.aof ensemble dans la même exécution.
Faites-le en un clic avec Dockstash
Dockstash exécute exactement le dump ci-dessus, le confie à restic hors site et teste la restauration par un drill automatiquement — aucun script à maintenir.
Dernière mise à jour : July 2026
Questions fréquentes
En quoi sauvegarder Valkey diffère-t-il de Redis ?
En rien de significatif. Valkey est un fork de Redis et conserve le même modèle de persistance RDB et AOF. La seule différence pratique est le nom du binaire client (valkey-cli), que Dockstash détecte automatiquement.
Puis-je restaurer un RDB Redis dans Valkey ?
Oui pour les versions actuelles — le format RDB est partagé depuis le point de fork. À mesure que les projets divergent, gardez les restaurations dans le même moteur par prudence.
Dockstash détecte-t-il Valkey automatiquement ?
Oui. Les images valkey/valkey et le binaire valkey-cli sont reconnus, et les clés VALKEY_PASSWORD comme l'ancienne REDIS_PASSWORD sont détectées.
Dois-je capturer l'AOF aussi ?
Si appendonly est activé et que vous ne pouvez pas perdre les dernières secondes d'écritures, oui. Dockstash sauvegarde le RDB et les fichiers AOF.
À quelle fréquence sauvegarder Valkey ?
Adaptez la planification au contenu. Pour files d'attente et sessions, l'horaire est courant ; pour des données plus lentes, le quotidien suffit. Sur l'offre Free, les sauvegardes sont manuelles (Backup Now) ; Pro autorise jusqu'à l'horaire, Business n'importe quelle expression cron.
Où vivent réellement les sauvegardes ?
Sur votre propre VPS de stockage, sous forme d'instantanés restic chiffrés poussés via SSH. Dockstash ne garde jamais vos données sur un cloud tiers — vous le pointez vers une machine que vous contrôlez, et le dépôt est chiffré avec un mot de passe que vous seul détenez.
Comment savoir qu'une sauvegarde Valkey se restaure vraiment ?
Planifiez un exercice de restauration. Dockstash restaure le dernier instantané dans un espace de travail isolé, compare chaque fichier par empreinte d'octets avec la source et vérifie le dump capturé — puis appose un badge réussite/échec sur le projet. Un exercice hebdomadaire vous garantit une preuve toujours fraîche.