Connecteurs ILYGO Centralized Backup

Un connecteur (ou bridge) est un conteneur ultra-léger déployé dans votre infrastructure, à côté de la source à sauvegarder. Il chiffre les données localement (zero-knowledge) puis les pousse vers ILYGO Centralized Backup en HTTPS sortant uniquement — aucun port entrant n'est ouvert chez vous.

Tous les connecteurs partagent le même binaire Go ilygo-bridge (une sous-commande par type) et le même protocole : heartbeat 30 s, long-poll des commandes, exécution locale, push de ciphertext.

Les 7 connecteurs

Concepts communs à tous les connecteurs

Variables d'environnement communes

Les variables spécifiques à la source (DSN, credentials DB, chemin…) sont documentées dans chaque fiche.

Cycle de vie

1. Provisioning : depuis la console (menu Installer un bridge), le wizard génère vos clés dans le navigateur (ILYGO_PASSPHRASE + ILYGO_RESTORE_SECRET) — elles ne sont jamais transmises à ILYGO — et produit un snippet docker-compose prêt à coller, clés déjà insérées. La ILYGO_API_KEY (auth) est fournie par le serveur. La compression (zstd) est automatique.
2. Démarrage : le conteneur démarre, envoie un heartbeat → il apparaît dans la console (Bridges).
3. Backup : déclenché manuellement (bouton « Backup maintenant ») ou par un planning cron centralisé (menu Plannings). Le bridge dump → compresse → chiffre → pousse.
4. Restore : workflow guidé (menu Restaurations) avec approbations M-of-N et un Restore Authorization Token (RAT).

Le modèle réseau (à appliquer pour tous)

networks:
  # La source vit sur un réseau interne — aucun accès Internet.
  app-net:
    internal: true

services:
  <votre-source>:          # postgres / mysql / minio / ...
    networks: [app-net]

  ilygo-bridge:
    image: ilygo/bridge-<type>:<tag>
    networks:
      app-net:              # pour parler à la source en interne
      default:              # pour sortir en HTTPS vers ILYGO
    # AUCUN bloc `ports:` — le bridge n'écoute rien.

La source reste invisible depuis Internet ; seul le bridge sort, en HTTPS, vers ILYGO_ENDPOINT.

Restauration : RAT (Restore Authorization Token)

Toute restauration exige un token signé localement par le bridge (avec ILYGO_RESTORE_SECRET). Même un serveur ILYGO compromis ne peut pas forger ce token. Procédure :

# Sur l'hôte du bridge :
docker exec <conteneur-bridge> ilygo-bridge restore-token <backup_id>
# → colle le token dans la console, étape "Autorisation" du workflow de restauration

Le token est lié au backup, à usage unique, valide 5 minutes.

Modes de restauration

Scope : sauvegarder tout ou une partie

Pour les sources structurées (bases), vous pouvez choisir ce que vous sauvegardez :

• Inspecter la source (bouton dans la page Bridge, commande inspect) liste les schémas (PostgreSQL), bases (MySQL/MongoDB) ou préfixes (S3/MinIO) disponibles — affichés dans la console.
• Backup complet : tout.
• Backup ciblé : un ou plusieurs schémas/bases. Le backup ne contient que le scope choisi (plus petit, plus rapide). Le scope est enregistré dans contents et visible dans le catalogue.
• À la restauration, vous pouvez restaurer un sous-ensemble des schémas du backup, et — pour PostgreSQL — renommer le schéma restauré (restaurer public dans public_copie, par ex.), vers un schéma existant ou nouveau.

Télécharger & déchiffrer un backup

Depuis la page d'un backup, « Télécharger (chiffré) » récupère un bundle .tar contenant le ciphertext + le manifest. Pour accéder au clair, déchiffrez localement avec votre passphrase :

export ILYGO_PASSPHRASE='votre-passphrase'
docker run --rm \
  -v "$PWD/ilygo-backup-XXXX.tar:/in/bundle.tar:ro" -v "$PWD:/out" \
  -e ILYGO_PASSPHRASE \
  --entrypoint /usr/local/bin/ilygo-bridge ilygo/bridge-postgres:16 \
  decrypt /in/bundle.tar /out/recovered.dump

# PostgreSQL : restaurer tout ou un schéma précis depuis le dump déchiffré
pg_restore --list recovered.dump
pg_restore --schema=sales --no-owner -d postgresql://user:pass@host/db recovered.dump

ILYGO n'intervient jamais dans le déchiffrement — la passphrase ne quitte pas votre poste. La console affiche ces instructions (bouton « Comment déchiffrer ? »).

Compression & tailles

Le bridge compresse (zstd par défaut) avant chiffrement. ILYGO connaît la taille logique (avant compression) et la taille stockée (ciphertext). Le ratio s'affiche dans la console.

Sécurité commune

• Images non-root, minimales (distroless quand c'est possible).
• Aucun volume persistant requis : l'état (commandes, manifests) vit côté serveur.
• Recommandé en prod : read_only: true + tmpfs: /tmp + cap_drop: [ALL] sur le conteneur bridge.
• Chiffrement : Argon2id (KDF) + AES-256-GCM par chunk + manifest chiffré. Identique pour tous les connecteurs.

Build des images

cd bridge
docker build -f docker/Dockerfile.postgres --build-arg PG_VERSION=16 -t ilygo/bridge-postgres:16 .
docker build -f docker/Dockerfile.mysql    -t ilygo/bridge-mysql:8 .
docker build -f docker/Dockerfile.mongodb  -t ilygo/bridge-mongodb:7 .
docker build -f docker/Dockerfile.redis    -t ilygo/bridge-redis:7 .
docker build -f docker/Dockerfile.minio    -t ilygo/bridge-minio:1 .
docker build -f docker/Dockerfile.files    -t ilygo/bridge-files:1 .

# Multi-arch (amd64 + arm64)
docker buildx build --platform linux/amd64,linux/arm64 \
  -f docker/Dockerfile.postgres -t ilygo/bridge-postgres:16 --push .

Le connecteur Volume Docker réutilise l'image ilygo/bridge-files:1 (un volume est un répertoire monté).