Sauvegardes — laquelle choisir et comment l’utiliser

Server Manager propose quatre espaces différents liés aux sauvegardes, chacun pensé pour un objectif précis. Ils se recoupent dans l’idée (« enregistrer mes données pour ne pas les perdre »), mais si tu choisis le mauvais outil, tu risques soit de te compliquer la vie, soit d’obtenir un fichier qui ne fait pas ce que tu voulais. Cet article associe chaque objectif au bon outil, puis détaille chaque procédure.

Guide rapide — lequel choisir ?

Récupérer un seul fichier (onglet Fichiers → 🗑 Sauvegardes)

À utiliser quand : tu as supprimé ou écrasé un fichier depuis l’onglet Fichiers et tu veux le récupérer.

Server Manager enregistre automatiquement chaque fichier que l’onglet Fichiers s’apprête à écraser ou supprimer. La version précédente est placée dans un dossier .helm-backup/ à côté de son emplacement d’origine. Les 3 dernières versions de chaque nom sont conservées ; les plus anciennes sont remplacées au fil du temps.

Important — c’est par répertoire. Si tu as supprimé /var/www/site/blog/post.md, la sauvegarde se trouve dans /var/www/site/blog/.helm-backup/, pas sous /var/www/site/. Pour la trouver, tu dois d’abord aller dans le répertoire où se trouvait le fichier.

Étapes :

1. Ouvre le panneau du service du site ou de l’app → onglet Fichiers.

2. Va dans le dossier où se trouvait le fichier — par exemple /var/www/mysite.example.com/blog/ si tu as supprimé un fichier dans blog/.

3. Clique sur 🗑 Sauvegardes dans la barre d’outils.

4. Repère l’entrée par nom + horodatage. Clique sur Restaurer pour la remettre en place, Télécharger pour enregistrer une copie sur ton ordinateur, ou Supprimer pour retirer définitivement la sauvegarde du serveur.

La restauration est elle-même réversible : l’état actuel du chemin cible est enregistré dans .helm-backup/ avant la restauration, ce qui te permet d’annuler la restauration de la même manière.

Ce que cela NE couvre PAS : les fichiers modifiés via SFTP/FileZilla, SSH, l’app en cours d’exécution elle-même, ou un redéploiement. Seules les actions effectuées depuis l’onglet Fichiers déclenchent la sauvegarde automatique. Pour un redéploiement où tu veux conserver un dossier, utilise .helm-keep.

Sauvegarder un site ou une app entière (onglet Sauvegarde)

À utiliser quand : tu veux une archive portable d’un site ou d’une app entière — configuration, secrets, fichiers, et (pour les éléments conteneurisés) volumes de données — que tu peux garder sur ton ordinateur par sécurité ou pour la transférer ailleurs.

L’onglet Sauvegarde propose trois actions, toutes basées sur le même format d’archive. Elles correspondent au cycle de vie d’une archive : créer → restaurer plus tard → ou transférer vers un autre serveur.

Ce que tu verras en haut de l’onglet. S’il reste des archives de ce service sur le serveur — généralement parce que tu as créé une sauvegarde sans la télécharger, ou qu’un téléversement a été abandonné pendant une restauration — elles s’affichent sous forme de liste en haut, avec taille, horodatage et bouton Supprimer pour chaque ligne. C’est ici que tu fais le ménage : les archives ne sont pas supprimées automatiquement, donc les anciennes finissent par occuper de l’espace disque sans bruit jusqu’à ce que tu les retires. Si des archives appartiennent à d’autres services, tu verras une petite indication avec leur nombre ; ouvre l’onglet Sauvegarde de chaque service pour les nettoyer.

Créer une sauvegarde

1. Ouvre le panneau du service → onglet Sauvegarde.
2. Pour WordPress, les apps web et les bases de données : coche Mettre le service en pause pendant la sauvegarde s’il s’agit d’un site très actif (commerce en cours, espace membres, migration en cours). Par défaut, il n’y a pas d’interruption — c’est rapide et adapté à la plupart des cas, mais tout ce qui est écrit pendant les ~30 s de capture peut être capturé partiellement (souvent un fichier orphelin : présent dans la sauvegarde, absent de la base de données). Avec la pause, le service s’arrête brièvement (~30–60 s d’indisponibilité) pour obtenir une capture parfaitement cohérente. Les sites statiques n’affichent pas cette option — il n’y a pas de processus géré à mettre en pause (Caddy sert directement les fichiers).
3. Clique sur Créer une sauvegarde. Le chat prend le relais — Faro prépare la commande tar, tu approuves, puis l’archive est créée sur le serveur.
4. Quand elle est prête, un bouton Télécharger apparaît dans le chat. Clique dessus ; le fichier est transféré en streaming via SFTP vers ton ordinateur.

Ce que contient l’archive : le docker-compose.yml (ou le manifeste de service équivalent), tous les secrets dans .env, tous les volumes nommés (données de base de données, fichiers téléversés, etc.) et un petit manifest.json décrivant le service. Les archives de sites statiques incluent l’arborescence de fichiers sous /var/www/<domain>/. Le format est auto-descriptif : lors d’une restauration ultérieure, le manifeste est lu pour tout reconstruire au bon endroit.

Restaurer depuis une archive

À utiliser quand : tu as une archive téléchargée auparavant (ou envoyée par un coéquipier) et tu veux remettre le service en place — soit sur ce serveur, soit sous forme de clone avec un nouveau domaine.

1. Ouvre le panneau du service → onglet Sauvegarde.
2. Clique sur Restaurer depuis une archive. Une fenêtre de téléversement s’ouvre (glisser-déposer ou clic pour choisir).
3. Sélectionne l’archive .tar.gz. Clique sur Téléverser.
4. Après le téléversement, la restauration proprement dite se déroule dans le chat. Faro lit le manifeste de l’archive et restaure sur place ou — si la structure de recette de l’archive ne correspond pas au service actuel, ou si tu indiques un autre domaine — demande s’il faut plutôt la cloner vers un nouveau domaine. Tu relis et approuves chaque commande avant toute exécution.

Pour le clonage : l’archive contient le domaine d’origine dans son manifeste. Faro demande le nouveau domaine et réécrit le Caddyfile + les références équivalentes à wp-config.php pour que le clone réponde à la nouvelle adresse. Le serveur d’origine continue de fonctionner sans être modifié.

Déplacer vers un autre serveur

À utiliser quand : tu as un service sur l’un de tes serveurs enregistrés et tu veux le déplacer (ou le copier) vers un autre — sans télécharger manuellement l’archive sur ton ordinateur puis la téléverser de l’autre côté.

Ce bouton n’apparaît que si tu as au moins deux serveurs enregistrés dans Server Manager — le sélecteur de cible doit avoir un serveur vers lequel pointer.

Prérequis : crée d’abord une sauvegarde sur la source (étape Créer une sauvegarde ci-dessus).

1. Sur le service du serveur source, ouvre le panneau du service → onglet Sauvegarde.
2. Clique sur Déplacer vers un autre serveur. Un assistant en trois étapes s’ouvre : - Étape 1 : choisir la cible. Choisis un serveur cible dans ta liste de serveurs enregistrés et saisis la phrase secrète de chiffrement de la cible. - Étape 2 : choisir la sauvegarde. Choisis l’archive à transférer (la liste affiche toutes les archives présentes sur la source). Clique sur Démarrer le transfert. - Étape 3 : transfert. L’archive transite de la source vers la cible via Server Manager — aucune copie sur ton ordinateur, aucun S3 public entre les deux.
3. Lorsque l’archive arrive sur la cible, Server Manager te bascule vers le serveur cible et te propose de restaurer l’archive qui vient d’arriver (en un clic).

Sauvegarder uniquement la base de données (onglet Dumps SQL)

À utiliser quand : tu veux uniquement le contenu de la base de données, pas toute la pile. Cas fréquents : transmettre les données à un développeur pour des tests, importer dans un autre moteur (enfin, essayer), ou créer rapidement un filet de sécurité avant une migration destructive.

Cet onglet n’existe que pour les services de base de données (Postgres, MySQL, MariaDB).

1. Ouvre le panneau du service de la base de données → onglet Dumps SQL.
2. Clique sur Créer un dump. Faro exécute pg_dump / mysqldump (selon le moteur) et enregistre la sortie en .sql.gz dans /var/backups/<engine>/.
3. Le nouveau dump apparaît dans la liste. Télécharger l’envoie vers ton ordinateur ; Supprimer le retire du serveur.

Dumps SQL vs onglet Sauvegarde — même service, artefacts différents :

• Le .sql.gz des Dumps SQL est du SQL brut — psql my-app < dump.sql le restaure dans n’importe quel Postgres de la bonne version majeure, y compris un Postgres qui tourne sur ton ordinateur portable.
• L’archive de l’onglet Sauvegarde est un .tar.gz complet — la base de données, le fichier compose, les secrets, les volumes nommés. La restauration recrée toute la pile de conteneurs.

Si tu as seulement besoin d’inspecter ou de transplanter des données : Dumps SQL. Si tu veux cloner tout le service de base de données ailleurs : onglet Sauvegarde.

Autres éléments souvent confondus avec des sauvegardes

**Marqueurs .helm-keep* — ils conservent un dossier lors d’un redéploiement* (ce n’est pas une sauvegarde, cela n’aide pas en cas de suppression accidentelle). À utiliser quand tu as un dossier d’exécution comme uploads/ que tu ne veux pas effacer lorsque tu pousses du nouveau code. C’est expliqué dans Plusieurs sites sur le même serveur.

Déplacer un serveur entier. Il n’existe pas de bouton unique « déplacer tout » — Server Manager déplace un service à la fois. Pour migrer un serveur contenant plusieurs sites/apps, répète la procédure Créer une sauvegarde → Déplacer vers un autre serveur → Restaurer sur la cible pour chaque service (l’action Déplacer vers un autre serveur se trouve dans l’onglet Sauvegarde de chaque service).

Référence

Où se trouvent les sauvegardes sur le disque :

• Sauvegardes de l’onglet Fichiers → <original-dir>/.helm-backup/<name>.<timestamp> (un dossier par répertoire)
• Archives de l’onglet Sauvegarde → /tmp/helm-backups/<id>/<bundle>.tar.gz sur le serveur source (jusqu’à ce que tu les télécharges ou les supprimes)
• Téléversements de restauration → /tmp/helm-restore/<id>/<bundle>.tar.gz (jusqu’à la fin de la restauration ou jusqu’à leur suppression)
• Dumps SQL → /var/backups/<engine>/<dbname>-<timestamp>.sql.gz

Rétention :

• Onglet Fichiers : les 3 dernières versions par nom d’origine ; la plus ancienne est remplacée.
• Onglet Sauvegarde + Dumps SQL : aucune suppression automatique — les archives restent sur le serveur jusqu’à ce que tu les supprimes depuis le panneau.

Surveiller l’espace disque. Chaque carte de service sur l’écran d’accueil affiche une pastille · N GB à côté de son nom dès qu’elle contient des données. Pour une analyse plus détaillée, la carte du serveur propose Détails du serveur →, qui ouvre Server Info avec un onglet Stockage listant l’utilisation disque par service (du plus gros au plus petit, avec des liens pour ouvrir le panneau en un clic), les dumps SQL de tous les moteurs, ainsi qu’une vue de nettoyage groupé de toutes les archives préparées sur le serveur. L’écran d’accueil affiche aussi une carte d’alerte orange/rouge lorsque le disque dépasse 80 % / 90 %.

Secrets dans les archives : les fichiers .env à l’intérieur d’une archive de l’onglet Sauvegarde contiennent des secrets en clair (mots de passe de base de données, clés d’API, etc.). Traite les archives téléchargées comme les fichiers .env d’origine : ne les envoie pas par e-mail, ne les commit pas, ne les laisse pas sur des disques partagés. Les archives sont supprimées du serveur source après téléchargement (le fichier transféré vers toi était une copie).