Cómo respaldar un contenedor Docker de Redis (2026)
¿Quieres un respaldo de Redis que de verdad se restaure? Vuélcalo con `redis-cli SAVE # then capture the resulting dump.rdb` desde dentro del contenedor en lugar de copiar /data. un SAVE/BGSAVE bifurca una instantánea RDB a un instante preciso en disco: respaldas el dump.rdb terminado (más el AOF si está activado), no el estado volátil en memoria. Dockstash entrega luego el volcado a restic para instantáneas cifradas, deduplicadas y fuera del servidor.
Qué detecta Dockstash
| Claves de entorno detectadas | REDIS_PASSWORD, REDIS_ARGS |
|---|---|
| Puerto por defecto | 6379 |
| Rutas de datos vivas (nunca copiadas en caliente) | /data, /data/dump.rdb, /data/appendonly.aof |
| Imágenes de ejemplo | redis:7-alpine, redis:7, redis:6, redis |
Respalda Redis con Dockstash, paso a paso
Crea tu cuenta de Dockstash y abre el panel
Regístrate gratis en app.dockstash.com/register. El asistente de configuración único te pide tu VPS de almacenamiento (la máquina que guardará los respaldos cifrados) y genera una contraseña de cifrado — guárdala de inmediato en un gestor de contraseñas: se muestra exactamente una vez.
Añade el proyecto Docker que ejecuta Redis
En la pantalla Projects, Dockstash detecta automáticamente cada carpeta de proyecto Compose del servidor (por defecto bajo /var/www). Elige el proyecto que contiene tu servicio Redis. Aún no se respalda nada — solo le indicas a Dockstash dónde vive el proyecto.
Comprueba que Redis fue detectado
Abre el proyecto y mira la pestaña Plan. Dockstash lee docker-compose.yml, reconoce la imagen redis y añade una capa de base de datos con la estrategia correcta de guardar-y-capturar — más el nombre del contenedor resuelto y las claves encontradas (REDIS_PASSWORD, REDIS_ARGS). Puedes activar o desactivar archivos, bases y configuraciones de proxy antes de guardar.
Opcional: comprueba la instantánea a mano
Si quieres una prueba antes de automatizar, dispara el mismo guardado que Dockstash: ejecuta redis-cli BGSAVE en el contenedor. Redis responde « Background saving started », bifurca y escribe un dump.rdb a instante preciso en /data. Ese archivo RDB terminado — nunca el estado vivo en memoria — es lo que se respalda.
docker exec <redis-container> redis-cli BGSAVEConfirma tu destino de almacenamiento
Los respaldos se guardan como instantáneas restic cifradas en tu propio VPS de almacenamiento, vía SSH. Si completaste el asistente, ya está configurado; puedes cambiar host, usuario, puerto o la clave SSH en cualquier momento en Settings → Storage.
Define una programación de respaldo
En la pestaña Schedule elige diario, semanal o una expresión cron personalizada (validada al escribir). Para un Redis usado como almacén principal (colas, sesiones), diario es un suelo razonable y cada hora es habitual. Añade un prune semanal con tu política de retención.
Ejecuta el primer respaldo ahora
Haz clic en Backup Now en la tarjeta del proyecto. Dockstash dispara un guardado en segundo plano, espera el dump.rdb terminado y lo respalda — junto con appendonly.aof cuando la persistencia AOF está activa — directamente en restic. Sigue la salida en vivo en el panel de logs.
Confirma que la instantánea existe
Al terminar la ejecución, la tarjeta del proyecto muestra la nueva hora del último respaldo, el número de instantáneas y el tamaño del repositorio. Abre la pantalla Snapshots: el punto de restauración aparece en la línea de tiempo — tu prueba de que el respaldo llegó fuera del servidor.
El comando de volcado
redis-cli SAVE # then capture the resulting dump.rdbEl comando de restauración
place dump.rdb in the data dir and start redis-serverun SAVE/BGSAVE bifurca una instantánea RDB a un instante preciso en disco: respaldas el dump.rdb terminado (más el AOF si está activado), no el estado volátil en memoria.
Restaura un respaldo de Redis y prueba que funciona
Un respaldo de Redis solo es real una vez restaurado. Las restauraciones de Dockstash nunca sobrescriben tu instancia viva por defecto — primero restauras a una ubicación nueva, verificas los datos y promocionas deliberadamente.
Elige un punto de restauración
Abre Snapshots, selecciona el proyecto y recorre la línea de tiempo. Cada fila contiene un dump.rdb completo a instante preciso (más el AOF si está activado) y los archivos del proyecto de la misma ejecución.
Restaura a una nueva ubicación
Haz clic en Restore y mantén el modo por defecto « Restore to new location ». Escribe el nombre del proyecto para confirmar — una acción deliberada con confirmación tecleada. El volcado y los archivos aterrizan en la ruta de destino que elijas, sin tocar el proyecto vivo.
Verifica los datos restaurados
Coloca el dump.rdb restaurado en el directorio de datos de un contenedor Redis de prueba y arráncalo — Redis carga el RDB al inicio. Ejecuta redis-cli PING: debes recibir PONG; luego sondea las claves de tu aplicación con DBSIZE y algunos GET.
docker exec <redis-container> redis-cli PINGPromociona cuando estés conforme
Cuando los datos restaurados estén validados, apunta tu aplicación a ellos (o repite la restauración en modo « Overwrite existing » — un opt-in explícito). Mejor aún: deja que el simulacro de restauración semanal produzca esta prueba automáticamente, para que una restauración nunca sea tu primer ensayo.
Trampas a evitar
- Copiar un dump.rdb en plena reescritura da un archivo truncado; dispara SAVE (o BGSAVE) primero y respalda el RDB terminado.
- Si la persistencia AOF está activa, respalda también los archivos appendonly.aof — el RDB solo puede ir por detrás de las últimas escrituras.
- La restauración de Redis exige un servidor parado o reiniciado para cargar el RDB; no se puede intercambiar dump.rdb en caliente en una instancia en marcha.
Problemas comunes al respaldar Redis
- Síntoma
- El dump.rdb restaurado no carga: « Short read or OOM loading DB » o error de archivo truncado.
- Causa
- El RDB se copió mientras Redis aún lo reescribía — una captura a mitad de reescritura produce un archivo parcial.
- Solución
- Dispara siempre SAVE o BGSAVE y espera a que termine antes de capturar dump.rdb. Dockstash hace exactamente eso: dispara el guardado, espera el final y respalda el archivo terminado.
- Síntoma
- Una restauración funciona pero faltan las escrituras más recientes.
- Causa
- La persistencia AOF está activa y appendonly.aof contenía escrituras más nuevas que la instantánea RDB — el RDB solo va con retraso.
- Solución
- Respalda ambos archivos. Dockstash captura /data/dump.rdb y appendonly.aof juntos en la misma ejecución.
- Síntoma
- Colocaste el dump.rdb restaurado en /data pero el Redis en marcha sigue sirviendo datos viejos.
- Causa
- Redis solo lee el RDB al arrancar — no se puede intercambiar en caliente. Y con appendonly activo, Redis carga el AOF al inicio e ignora el RDB por completo.
- Solución
- Para el contenedor, coloca el dump.rdb restaurado (y el AOF si restauraste uno) en el directorio de datos y arráncalo de nuevo. Si solo restauraste un RDB en un montaje con AOF, pon temporalmente appendonly no para el primer arranque y reactívalo después.
- Síntoma
- BGSAVE falla con « Can't save in background: fork: Cannot allocate memory ».
- Causa
- El fork necesario para el guardado en segundo plano fue denegado por las heurísticas de overcommit de memoria del kernel, en un host con un conjunto de datos Redis grande.
- Solución
- Configura vm.overcommit_memory=1 en el host Docker (sysctl) — el ajuste que el propio Redis recomienda al arrancar. El fork usa copy-on-write: no necesita una segunda copia completa del conjunto de datos.
Hazlo en un clic con Dockstash
Dockstash ejecuta exactamente el volcado de arriba, lo entrega a restic fuera del servidor y prueba la restauración con un simulacro automáticamente — sin script que mantener.
Última actualización: July 2026
Preguntas frecuentes
¿Vale la pena respaldar Redis siquiera?
Depende del uso. Como caché puro, un Redis perdido se repuebla solo. Como almacén principal (colas, sesiones, sorted sets), sí — respalda el RDB, y el AOF si está activado.
SAVE o BGSAVE — ¿cuál usa Dockstash?
BGSAVE bifurca y hace la instantánea en segundo plano sin bloquear; SAVE bloquea hasta terminar. Dockstash prefiere el guardado en segundo plano y respalda después el dump.rdb terminado.
¿Qué pasa con el AOF (append-only file)?
Si appendonly está activo, el AOF contiene las escrituras más recientes que el RDB quizá aún no refleja. Dockstash captura /data/dump.rdb y appendonly.aof para no perder datos recientes.
¿Puedo copiar dump.rdb mientras Redis corre?
Solo tras un SAVE/BGSAVE completado. Copiar durante una reescritura puede atrapar un archivo parcial. Dockstash dispara el guardado y espera a que termine antes de capturar.
¿Con qué frecuencia debo respaldar Redis?
Ajusta la programación a lo que Redis contiene. Para colas y sesiones, cada hora es habitual; para datos más lentos, diario basta. En el plan Free los respaldos son manuales (Backup Now); Pro permite hasta cada hora, Business cualquier expresión cron.
¿Dónde viven realmente los respaldos?
En tu propio VPS de almacenamiento, como instantáneas restic cifradas enviadas por SSH. Dockstash nunca guarda tus datos en una nube de terceros — lo apuntas a una máquina que controlas, y el repositorio está cifrado con una contraseña que solo tú tienes.
¿Cómo sé que un respaldo de Redis realmente se restaura?
Programa un simulacro de restauración. Dockstash restaura la última instantánea en un espacio aislado, compara cada archivo byte a byte con la fuente y verifica el volcado capturado — luego estampa una insignia de éxito/fallo en el proyecto. Un simulacro semanal es prueba siempre fresca.