Tous les projets

Projet personnelDepuis août 2026

Backhaul

Un outil de sauvegarde automatique qui envoie des dossiers locaux vers Infomaniak kDrive, avec une politique de rétention configurable par dossier. Il tourne dans un conteneur Docker.

Code sur GitHub
Rôle
Conception et développement
Licence
Open source, ISC
Distribution
Image Docker sur GHCR

Contexte

Des sauvegardes locales, mais aucune copie hors site.

Sur mon serveur maison, les applications font déjà leurs propres sauvegardes : des fichiers zip déposés dans un dossier. Mais ces fichiers restent sur la même machine que les données qu’ils protègent.

Je voulais une application conteneurisée qui les envoie sur Infomaniak kDrive, réglée par un simple fichier de configuration, sans les accumuler indéfiniment. C’était aussi l’occasion de mener un projet de bout en bout : tests, image Docker, versions publiées.

Comment ça marche

  1. Planification
    Une expression cron lance la sauvegarde, et au besoin le démarrage du conteneur.
  2. Sélection
    Les fichiers de chaque dossier source, sauf les fichiers cachés et ceux modifiés trop récemment.
  3. Envoi
    Chaque fichier part vers son dossier kDrive, sauf s’il s’y trouve déjà avec le même hash.
  4. Rétention
    Chaque destination ne garde que ses fichiers les plus récents.
  5. Bilan
    Un résumé dans les logs, et un code de sortie qui dit si tout a réussi.

Un conteneur, deux volumes en lecture seule

Le conteneur ne reçoit que sa configuration et les dossiers à sauvegarder, montés en lecture seule : Backhaul ne modifie jamais les fichiers locaux.

Chaque dossier est traité à part. Une source absente, comme un volume non monté, est signalée dans les logs sans bloquer les autres.

# compose.yml
services:
  backhaul:
    image: ghcr.io/tremblets/backhaul:latest
    restart: unless-stopped
    stop_grace_period: 5m
    environment:
      TZ: Europe/Zurich
    volumes:
      - ./config.yml:/config/config.yml:ro
      - ./data:/data:ro

Choix

  • Jamais un fichier à moitié écrit

    Un fichier modifié trop récemment attend le passage suivant. Son âge se lit sur la plus récente de ses dates mtime et ctime, ce qui couvre aussi les copies qui conservent la date d’origine.

  • La date vient du nom du fichier

    La rétention trie les fichiers selon l’horodatage de leur nom, pas leur date d’envoi : un envoi en retard, après une panne, ne fausse pas l’ordre.

  • Un arrêt ne supprime rien

    À l’arrêt, les envois en cours se terminent, aucun nouveau ne commence et la rétention n’est pas appliquée. Le reste part au passage suivant.

  • Une configuration stricte

    Une clé inconnue, une destination en double ou un cron invalide empêchent le démarrage, en nommant le champ en cause.

Technologies

Node.js
Planificateur cron, envoi vers kDrive et CLI de sauvegarde manuelle.
Docker
Image publiée sur GHCR, lancée sur le serveur maison.
Vitest
Tests de la rétention, de l’envoi et de l’arrêt propre.
Zod
Validation stricte de config.yml au démarrage.