Solucionar respaldos fallidos
Cuando un respaldo falla, Dockstash lo dice alto y te muestra dónde: un correo de alerta con el error, una insignia de estado en la tarjeta del proyecto y la salida completa de restic en el panel de logs en vivo. Esta guía recorre las formas de fallo comunes — ejecuciones en rojo, agentes fuera de línea, la alarma de silencio — y sus arreglos.
Cómo hacerlo
Empieza por la tarjeta del proyecto
La pantalla Projects muestra insignia de estado, hora del último respaldo y tamaño por proyecto. Una ejecución fallida también llega como correo de alerta con el error y un enlace directo — empieza por cualquiera de los dos. La vista de detalle expone directamente el detalle del último fallo.
Lee la salida restic de la ejecución
Abre el panel de logs de la ejecución fallida. Las últimas líneas casi siempre nombran la causa: authentication failed (clave SSH o credenciales de base), no space left on device (caja de almacenamiento llena), connection refused (VPS de almacenamiento inalcanzable) o un error del comando de volcado dentro del contenedor.
Los candados restic obsoletos se arreglan solos
Si una ejecución se estrelló o el servidor se reinició a mitad de respaldo, el repositorio puede quedar bloqueado. No intervengas: la siguiente ejecución detecta el candado huérfano y ejecuta restic unlock automáticamente. Un candado retenido por un job realmente en marcha nunca se rompe.
Proyectos en agente: revisa primero el agente
Si un proyecto de agente de flota deja de respaldar, mira la pantalla Fleet. Un agente fuera de línea significa que los heartbeats pararon: en el VPS confirma que ambos contenedores del agente corren, que la URL de Dockstash es alcanzable y que el token no se rotó sin actualizar el contenedor. 401 repetidos en los logs significan que un contenedor viejo en alguna parte aún late con un token revocado.
docker compose -f docker-compose.agent.yml psEntiende las alertas de « ningún respaldo corrió »
Una alerta de heartbeat significa que ningún respaldo exitoso llegó dentro de la ventana — nada falló, nada corrió. Sospechosos habituales: la programación se desactivó, el plan no permite programaciones, el proyecto quedó pausado tras una bajada de plan, o el agente asignado está fuera de línea. Corrige la causa y la siguiente ejecución verde limpia la alarma.
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
Guías relacionadas
Conectar un agente de flota
Ejecuta un pequeño agente solo-saliente en cualquier VPS y respalda sus contenedores desde un solo panel — registro, instalación, directorios de proyectos y primera asignación.
Configurar alertas y notificaciones
Correos de fallo, un heartbeat tipo dead-man's switch que atrapa las paradas silenciosas, difusión por webhook a Slack o PagerDuty y un registro de auditoría inmutable.
MySQL
Respaldar MySQL en Docker
MongoDB
Respaldar MongoDB en Docker
Preguntas frecuentes
Un respaldo falló una vez y triunfó al reintentar. ¿Debo preocuparme?
Mira la razón del fallo. Los jobs reintentan con backoff exponencial acotado: los tropiezos de red transitorios se curan solos. Reintentos recurrentes sobre el mismo error — disco llenándose, SSH inestable — merecen un arreglo real antes de volverse un fallo duro.
¿Por qué mi segunda programación espera en lugar de correr?
Un job por repositorio a la vez, siempre. Las operaciones restic concurrentes corrompen repositorios, así que las programaciones que chocan sobre el mismo repo se serializan a propósito. Repos distintos corren en paralelo.
El selector Add-Project de mi agente está vacío. ¿Por qué?
El selector lee la instantánea que el agente empujó en su último heartbeat. Vacío significa: el agente aún no ha reportado, un directorio de proyectos no está realmente montado en el contenedor del agente, o el proxy del socket Docker es inalcanzable — el aviso del selector te dice cuál es. Arréglalo y pulsa Refresh now en lugar de esperar al siguiente ciclo de descubrimiento.
¿Cómo pruebo que el propio repositorio está sano?
Ejecuta un job de check. restic check verifica la estructura del repositorio; con un porcentaje de lectura de datos también lee y verifica el contenido real de los packs. Pasar exige código de salida cero — no hay verdes falsos.
¿Dónde veo por qué falló un simulacro?
El resultado del simulacro guarda un mensaje de detalle con el número de discrepancias, visible en la pestaña Restore drill y en el correo de alerta. Discrepancias de bytes apuntan a archivos que cambiaron durante el respaldo; de filas, a la consistencia del volcado — en ambos casos trata el respaldo como no probado hasta que una nueva ejecución pase.