Dépanner des sauvegardes en échec
Quand une sauvegarde échoue, Dockstash vous le dit fort et vous montre où : un e-mail d'alerte avec l'erreur, un badge de statut sur la carte du projet et la sortie restic complète dans le panneau de logs en direct. Ce guide parcourt les formes d'échec courantes — exécutions rouges, agents hors ligne, alarme de silence — et leurs correctifs.
Comment faire
Commencez par la carte du projet
L'écran Projects affiche un badge de statut, la date de dernière sauvegarde et la taille par projet. Une exécution en échec arrive aussi par e-mail d'alerte avec l'erreur et un lien direct — partez de l'un ou de l'autre. La vue de détail du projet expose directement le détail du dernier échec.
Lisez la sortie restic de l'exécution
Ouvrez le panneau de logs de l'exécution en échec. Les dernières lignes nomment presque toujours la cause : authentification échouée (clé SSH ou identifiants de base), plus d'espace disque (machine de stockage pleine), connexion refusée (VPS de stockage injoignable), ou une erreur de commande de dump dans le conteneur.
Les verrous restic périmés se corrigent seuls
Si une exécution a planté ou que le serveur a redémarré en pleine sauvegarde, le dépôt peut rester verrouillé. Aucune intervention : l'exécution suivante détecte le verrou orphelin et lance restic unlock automatiquement. Un verrou détenu par un job réellement en cours n'est jamais cassé.
Projets sur agent : vérifiez d'abord l'agent
Si un projet sur agent de flotte cesse de se sauvegarder, regardez l'écran Fleet. Un agent hors ligne signifie que les heartbeats se sont arrêtés : sur le VPS, confirmez que les deux conteneurs de l'agent tournent, que l'URL Dockstash est joignable, et que le token n'a pas été tourné sans mettre à jour le conteneur. Des 401 répétés dans les logs signifient qu'un vieux conteneur quelque part utilise encore un token révoqué.
docker compose -f docker-compose.agent.yml psComprenez les alertes « aucune sauvegarde n'a tourné »
Une alerte heartbeat signifie qu'aucune sauvegarde réussie n'est arrivée dans la fenêtre — rien n'a échoué, rien n'a tourné. Suspects habituels : planification désactivée, offre sans planifications, projet mis en pause après une rétrogradation, ou agent assigné hors ligne. Corrigez la cause : la prochaine exécution verte efface l'alarme.
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
Guides associés
Connecter un agent de flotte
Exécutez un petit agent sortant-uniquement sur n'importe quel VPS et sauvegardez ses conteneurs depuis un seul tableau de bord — enregistrement, installation, répertoires de projets et première assignation.
Configurer alertes & notifications
E-mails d'échec, heartbeat façon dead-man's switch qui attrape les arrêts silencieux, diffusion webhook vers Slack ou PagerDuty, et piste d'audit immuable.
MySQL
Sauvegarder MySQL sous Docker
MongoDB
Sauvegarder MongoDB sous Docker
Questions fréquentes
Une sauvegarde a échoué une fois puis réussi au réessai. Dois-je m'en soucier ?
Regardez la raison de l'échec. Les jobs réessaient avec un backoff exponentiel plafonné : les à-coups réseau transitoires se soignent seuls. Des réessais récurrents sur la même erreur — disque qui se remplit, SSH instable — méritent un vrai correctif avant de devenir un échec dur.
Pourquoi ma deuxième planification attend-elle au lieu de tourner ?
Un job par dépôt à la fois, toujours. Les opérations restic concurrentes corrompent les dépôts : les planifications qui se percutent sur le même dépôt sont sérialisées délibérément. Les dépôts différents tournent en parallèle.
Le sélecteur Add-Project de mon agent est vide. Pourquoi ?
Le sélecteur lit l'instantané que l'agent a poussé à son dernier heartbeat. Vide signifie : l'agent n'a pas encore rapporté, un répertoire de projets n'est pas réellement monté dans le conteneur de l'agent, ou le proxy de socket Docker est injoignable — la bannière du sélecteur vous dit lequel. Corrigez, puis cliquez sur Refresh now au lieu d'attendre le prochain cycle de découverte.
Comment prouver que le dépôt lui-même est sain ?
Lancez un job de check. restic check vérifie la structure du dépôt ; avec un pourcentage de lecture de données, il lit et vérifie aussi le contenu réel des packs. La réussite exige un code de sortie zéro — pas de faux vert.
Où voir pourquoi un drill a échoué ?
Le résultat du drill stocke un message de détail avec le nombre de différences, affiché sur l'onglet Restore drill et dans l'e-mail d'alerte. Des différences d'octets pointent des fichiers modifiés pendant la sauvegarde ; des différences de lignes pointent la cohérence du dump — dans les deux cas, considérez la sauvegarde comme non prouvée jusqu'à une nouvelle exécution réussie.