Déposer ses sauvegardes sur INOBACKUP

Déposer ses sauvegardes sur INOBACKUPCe dossier contient tout ce qui s'installe côté application cliente pour se brancher sur CONTROL. Un sous-dossier par module :

Dossier	Module	Ce qu'on y branche
`inocampagne/`	INOCAMPAGNE	Formulaire d'inscription embarquable et API d'abonnement — guides HTML, Next.js, WordPress
`inodesk/`	INODESK	Widget de contact, formulaires, portail de suivi — guides Next.js, WordPress (+ plugin), Laravel, HTML
`inoshop/`	INOSHOP	Les six métas à poser sur la commande au checkout, pour que Meta reconnaisse l'acheteur
`inotrack/`	INOTRACK	Traqueur d'audience et de conversion — guides Next.js, Laravel, plugin WordPress
`inowatch/`	INOWATCH	Heartbeats : une tâche prouve qu'elle a tourné — guides cron/cPanel, Docker, Laravel, API
`inobackup.sh`, `laravel-control-backup/`	INOBACKUP	Dépôt des sauvegardes (documenté ci-dessous)

Les trois scripts embarquables (inotrack.js, inodesk.js, inocampagne.js) partagent le même transport (clé publique dans l'URL, corps text/plain, aucun préflight) et le même format d'erreur. Un intégrateur qui en a branché un connaît déjà les autres.Ce qu'il faut installer côté application cliente pour déposer ses sauvegardes de base de données sur CONTROL.

Fichier	Pour qui
`inobackup.sh`	N'importe quel serveur Linux : VPS, hébergement cPanel, machine dédiée
`laravel-control-backup/`	Applications Laravel (commande `control:backup`)

Le principe est toujours le même : dump → gzip → sha256 → POST authentifié. CONTROL écrit la sauvegarde d'abord sur son propre disque, puis la réplique sur un stockage objet hors-site, applique la rétention GFS et alerte par email si une sauvegarde attendue n'arrive pas.En plus de la base, les deux intégrations savent archiver des chemins de fichiers (uploads, .env, dossiers de configuration…) : voir la section 6.1. Préparer CONTROL (à faire une seule fois par application)

Connectez-vous à CONTROL avec un compte administrateur.

INOBACKUP › Applications › Nouvelle application :

Nom : le nom lisible de l'application (ex. « Boutique en ligne ») ;
Planification : fréquence, heure et fuseau (Africa/Lome par défaut) — c'est ce créneau qui déclenche l'alerte « sauvegarde manquante » s'il n'est pas honoré ;
Grâce : tolérance en minutes après l'heure prévue (60 par défaut) ;
Rétention : nombre de sauvegardes quotidiennes / hebdomadaires / mensuelles à garder ;
Emails d'alerte : destinataires (vide = adresse d'administration globale).

INOBACKUP › Clés API › Nouvelle clé : choisissez l'application, nommez la clé (ex. « Cron VPS production »). La clé CTRLBK_… n'est affichée qu'une seule fois : copiez-la immédiatement. Elle n'est stockée que sous forme d'empreinte : perdue, elle se révoque et se recrée, elle ne se retrouve pas.

Notez l'URL de dépôt : https://plateforme.inovertix.com/api/inobackup.2. Tester la configuration avec /pingAvant d'automatiser quoi que ce soit, vérifiez que la clé fonctionne :

bash

curl -sS https://plateforme.inovertix.com/api/inobackup/ping \
  -H "Authorization: Bearer CTRLBK_votre_cle"

Réponse attendue (HTTP 200) :

json

{
  "application": {
    "name": "Boutique en ligne",
    "slug": "boutique-en-ligne",
    "frequency": "daily",
    "timezone": "Africa/Lome",
    "last_backup_at": null
  },
  "server_time": "2026-08-11T09:12:44+00:00",
  "max_size_mb": 2048
}

Code	Signification
`401`	Clé absente, invalide ou révoquée
`403`	L'application est désactivée dans CONTROL
`429`	Plus de 30 requêtes sur l'heure écoulée pour cette clé

L'appel met à jour « Dernière utilisation » dans CONTROL : l'encart Intégration de la fiche application affiche alors « Intégration active ».3. Installation sur un VPS Dokploya) Cron sur l'hôte (recommandé quand le client MySQL est installé)

bash

# 1. Le script
sudo curl -o /usr/local/bin/inobackup.sh \
  https://raw.githubusercontent.com/INOVERTIX/CONTROL/main/integrations/inobackup.sh
sudo chmod 700 /usr/local/bin/inobackup.sh

# 2. La configuration (mode 600 : la clé est un secret)
sudo tee /etc/inobackup.env > /dev/null <<'EOF'
DB_HOST=127.0.0.1
DB_PORT=3306
DB_USER=monapp
DB_PASS=motdepasse
# Une ou plusieurs bases, séparées par des espaces. Chacune est déposée séparément
# et garde SA PROPRE rotation côté CONTROL (voir « Plusieurs bases » ci-dessous).
DB_NAMES=monapp_prod
INOBACKUP_URL=https://plateforme.inovertix.com/api/inobackup
INOBACKUP_KEY=CTRLBK_votre_cle
EOF
sudo chmod 600 /etc/inobackup.env

# 3. Essai à blanc
sudo /usr/local/bin/inobackup.sh

# 4. Cron quotidien à 02h00 (heure du serveur — alignez-la sur CONTROL)
echo '0 2 * * * root /usr/local/bin/inobackup.sh >> /var/log/inobackup.log 2>&1' \
  | sudo tee /etc/cron.d/inobackup

b) Variante docker exec (base dans un conteneur)Sur Dokploy, la base tourne généralement dans un conteneur et mysqldump n'existe pas sur l'hôte. Renseignez simplement le nom du conteneur : le script utilise alors le client du conteneur.

bash

docker ps --format '{{.Names}}'        # repérer le nom exact du conteneur de base

# dans /etc/inobackup.env :
DOCKER_CONTAINER=monapp-db-1
DB_USER=monapp
DB_PASS=motdepasse
DB_NAMES=monapp_prod

DB_HOST/DB_PORT deviennent inutiles : la commande s'exécute à l'intérieur du conteneur. Le mot de passe est transmis via MYSQL_PWD (jamais visible dans ps).c) Plusieurs bases sous une même clé (mutualisé)Un même serveur héberge souvent plusieurs bases. Listez-les dans DB_NAMES : le script les traite l'une après l'autre et envoie chacune avec son propre db_name.

bash

DB_NAMES="client_crm client_blog client_shop"

Attention

db_name n'est pas décoratif : c'est la clé de série. Côté CONTROL, la rotation (quotidiennes / hebdomadaires / mensuelles conservées) et la supervision s'appliquent par base. Quinze bases envoyées sous un même db_name partagent une seule rotation : une seule survit par nuit, et ce n'est pas la même d'une nuit à l'autre. Un script qui boucle sur plusieurs bases doit faire varier ce champ.

Conséquences à connaître :

Volume : chaque base conserve son propre cycle. Quinze bases en 7 j / 4 sem. / 3 mois plafonnent à ~210 fichiers, contre 14 pour une base seule.

Supervision : une base qui cesse de déposer déclenche une alerte en la nommant, même si les quatorze autres sont bien arrivées.

Une base en échec n'interrompt pas les suivantes. Le script traite toute la liste, puis sort en erreur avec le récapitulatif — surveillez le code de sortie du cron, pas seulement la présence de nouveaux fichiers.

Archives de fichiers : elles forment leur propre série (BACKUP_FILES_LABEL, fichiers par défaut). Ne leur donnez pas le nom d'une base.

Si les bases vont et viennent, DB_DISCOVER=1 (avec DB_NAMES vide) les découvre via SHOW DATABASES en excluant les bases système. Pratique, mais la liste explicite reste préférable : elle rend visible l'oubli d'une base au lieu de le masquer.4. Installation sur un hébergement cPanelmysqldump est disponible sur la plupart des offres mutualisées, mais l'accès SSH ne l'est pas toujours. Deux étapes :

Déposer le script (Gestionnaire de fichiers) dans un dossier hors public_html, par exemple /home/utilisateur/scripts/inobackup.sh, puis lui donner les droits 700.

Renseigner la configuration directement en tête du script (l'entête CONFIGURATION) plutôt que via /etc/inobackup.env, auquel vous n'avez pas accès :

bash

DB_HOST="localhost"
DB_USER="utilisateur_monapp"
DB_PASS="motdepasse"
DB_NAMES="utilisateur_monapp"
INOBACKUP_URL="https://plateforme.inovertix.com/api/inobackup"
INOBACKUP_KEY="CTRLBK_votre_cle"
TMP_DIR="/home/utilisateur/tmp"

Créer la tâche cron dans cPanel › Tâches Cron :

texte

0 2 * * *   /bin/bash /home/utilisateur/scripts/inobackup.sh >> /home/utilisateur/logs/inobackup.log 2>&1

Renseignez une adresse dans « Adresse e-mail » pour recevoir la sortie en cas d'erreur.

Espace disque : le dump compressé est écrit dans TMP_DIR avant l'envoi puis supprimé. Prévoyez la place correspondante dans votre quota.

5. Installation via le package LaravelPour une application Laravel, préférez le package : il lit la connexion de l'application elle-même, journalise dans laravel.log et s'enregistre dans le scheduler existant.

bash

composer config repositories.control-backup path ../CONTROL/integrations/laravel-control-backup
composer require inovertix/control-backup:@dev
php artisan vendor:publish --tag=control-backup-config
# .env :
#   CONTROL_BACKUP_URL=https://plateforme.inovertix.com/api/inobackup
#   CONTROL_BACKUP_KEY=CTRLBK_votre_cle
php artisan control:backup

Puis, dans routes/console.php :

php

Schedule::command('control:backup')->dailyAt('02:00')->withoutOverlapping();

Détails complets : laravel-control-backup/README.md.6. Sauvegarder aussi des fichiersUne sauvegarde de base ne suffit presque jamais : les fichiers téléversés par les utilisateurs (uploads/, media/) et les fichiers de configuration (.env) ne sont pas dans la base et ne se régénèrent pas.Script bash

bash

# dans /etc/inobackup.env (ou en tête du script)
BACKUP_PATHS="/home/monapp/public_html/uploads /home/monapp/public_html/.env"

Le script produit alors deux dépôts par exécution : le dump SQL (nature base de données) puis une archive .tar.gz des chemins (nature fichiers). Les deux suivent la même politique de double stockage et de rétention.Package Laravel

env

CONTROL_BACKUP_PATHS=/var/www/monapp/storage/app/public,/var/www/monapp/.env

(séparés par des virgules ; la liste vide désactive l'archive de fichiers)Exclusions — le piège à connaîtrePar défaut : node_modules, .git, vendor, *.log.

Attention

Un motif s'applique à n'importe quel COMPOSANT du chemin, pas seulement au dernier. Ajouter cache exclut aussi bien /var/cache/x que /home/cache-client/public_html en entier. Or un tar sans aucune entrée reste un .tar.gz parfaitement valide d'une quarantaine d'octets : sans garde-fou, une sauvegarde vide partirait avec un code de succès.

Les deux intégrations refusent désormais d'envoyer une archive sans aucune entrée (code de sortie 6 pour le script bash) et affichent le nombre d'entrées à chaque exécution :

texte

[inobackup] archive de fichiers : monapp_20260811-020000_files.tar.gz — 4213 entrée(s), 87 431 210 octets

Surveillez ce nombre dans le journal du cron : une chute brutale signale une exclusion trop large ou un dossier disparu.

Un chemin listé mais inexistant est signalé sur stderr et ignoré ; la sauvegarde continue. Si aucun des chemins n'existe, l'archive est abandonnée en erreur.

À savoir sur la supervision : CONTROL considère aujourd'hui une application « à jour » dès qu'une sauvegarde — de n'importe quelle nature — est arrivée dans le créneau. Si vos fichiers cessent d'être envoyés alors que la base continue, l'application restera au vert. Filtrez la liste sur la nature « Fichiers » pour le vérifier.

7. Référence de l'API de dépôtPOST /api/inobackup/upload — multipart/form-data

Champ	Obligatoire	Description
`file`	oui	L'archive : `.sql`, `.sql.gz`, `.gz` ou `.zip`
`checksum`	non	SHA-256 du fichier ; recalculé côté serveur et comparé
`db_name`	non	Nom de la base sauvegardée (affiché dans CONTROL)
`kind`	non	`database` (défaut) ou `files` — nature de la sauvegarde
`note`	non	Note libre (ex. nom d'hôte, contexte)

Réponse 201 :

json

{
  "id": "01J...",
  "stored_filename": "b1f0…-….sql.gz",
  "size_bytes": 4831201,
  "checksum_sha256": "9f86d0…",
  "local_status": "stored",
  "s3_status": "pending"
}

s3_status: "pending" est normal : la copie vers le stockage hors-site est asynchrone (3 tentatives avec backoff, puis alerte email en cas d'échec définitif).

Code	Cas
`201`	Sauvegarde acceptée et stockée localement
`401`	Clé manquante, invalide ou révoquée
`403`	Application désactivée
`413`	Fichier au-delà de la limite (2 Go par défaut)
`422`	Extension refusée, contenu incohérent, archive gzip corrompue, checksum différent
`429`	Plus de 30 dépôts sur l'heure écoulée pour cette clé

GET /api/inobackup/pingVoir la section 2.8. Dépannage

Symptôme	Piste
`401 invalid_api_key`	Clé recopiée partiellement, ou révoquée dans CONTROL
`403 application_inactive`	Réactivez l'application dans INOBACKUP › Applications
`413 file_too_large`	La sauvegarde dépasse la limite acceptée (2 Go par défaut) — demandez à INOVERTIX de relever le plafond de votre application
`422 corrupt_archive`	Le dump a été tronqué (disque plein, timeout) — vérifiez `gzip -t` en local
`422 checksum_mismatch`	Transfert corrompu : relancez ; si cela persiste, testez sans le champ `checksum`
`429`	Un cron trop fréquent, ou plusieurs serveurs partageant la même clé : créez une clé par serveur
Alerte « sauvegarde manquante » alors que le cron tourne	L'heure du cron ne correspond pas à la planification déclarée dans CONTROL, ou le fuseau diffère
`s3_status` reste `pending`	La réplication hors-site n'a pas abouti — la sauvegarde est bien reçue et conservée, signalez-le à INOVERTIX