Restaurer depuis une sauvegarde

Tu as une archive .tar.gz que tu as enregistrée plus tôt (ou qu’un coéquipier t’a envoyée, ou qui vient d’arriver depuis un autre serveur). Voici comment la remettre en service — soit sur place (en écrasant l’original s’il existe encore), soit comme clone sur un nouveau domaine.

Tu cherches plutôt comment créer des sauvegardes ? C’est traité dans un autre article : Sauvegardes — laquelle choisir et comment l’utiliser. Celui-ci part du principe que « j’ai déjà une archive sur mon ordinateur ».

Où lancer la restauration — trois points d’entrée

Même parcours, trois portes d’entrée. Choisis celle qui correspond à ton point de départ. (Deux de ces portes utilisent le Menu Actions de la barre supérieure — clique sur ce terme pour voir où il se trouve.)

Les trois portes ouvrent toutes la même fenêtre Restaurer depuis une sauvegarde. La seule différence, c’est le contexte dont dispose Server Manager au moment où tu l’ouvres :

• Depuis un panneau de service, la fenêtre sait quelle recette + quel service tu attendais — si l’archive envoyée n’a pas la même forme (par exemple si tu as ouvert le panneau WordPress mais envoyé une archive Postgres), elle affiche un avertissement pour te permettre de choisir un autre fichier avant de lancer quoi que ce soit.
• Depuis le menu Actions, aucune attente n’est définie — ce que l’archive indique être sera restauré tel quel.
• Depuis un transfert entrant, l’archive est déjà sur le serveur ; la fenêtre propose un bouton Restaurer cette archive en un clic.

Le pas à pas

Choisis le point d’entrée qui correspond à ta situation (voir le tableau ci-dessus). La fenêtre est la même dans les trois cas :

Fais glisser le fichier .tar.gz sur la zone de dépôt, ou clique n’importe où dans la zone pour ouvrir le sélecteur de fichiers. La fenêtre accepte les fichiers qui se terminent par .tar.gz ou .tgz.

Clique sur Envoyer. Une barre de progression remplace la zone de dépôt pendant que l’archive est transférée vers le serveur (envoi par morceaux — même les archives de plusieurs Go résistent aux connexions instables).

Qu’est-ce qui est envoyé ? Ton ordinateur envoie les octets du fichier .tar.gz au serveur via un flux de type SFTP — chiffré par la session SSH à laquelle tu es connecté. Le fichier arrive dans /tmp/helm-restore/<id>/<bundle>.tar.gz et y reste jusqu’à la fin de la restauration (puis il est nettoyé).

Quand l’envoi est terminé, la fenêtre se ferme et Faro te salue dans le chat avec le résumé du manifeste lu dans l’archive : le titre source, le domaine source, la recette et l’horodatage de la sauvegarde. Il te pose ensuite une courte question :

Veux-tu restaurer sur place (en écrasant le <name> existant s’il est encore présent) ou cloner vers un nouveau domaine (en gardant l’original intact et en créant une copie séparée) ?

C’est le seul choix à faire. À partir de là, ta réponse détermine la suite des étapes.

4a. Restaurer sur place

Choisis cette option quand :

• Le service d’origine n’existe plus (supprimé, ou tu es sur un serveur neuf) et tu veux le remettre au même domaine avec les mêmes noms.
• L’original est cassé / mal configuré et tu veux l’effacer puis le recréer depuis l’archive.

Ce que fait Faro :

1. Il lit docker-compose.yml et .env dans l’archive, puis les recrée dans le chemin d’installation d’origine.
2. Il restaure chaque volume Docker nommé (données de base de données, fichiers téléversés, etc.) à partir des volumes présents dans l’archive.
3. Pour les sites statiques, il recopie l’arborescence de fichiers sous /var/www/<domain>/.
4. Il réapplique le bloc Caddyfile pour que le domaine d’origine serve à nouveau le site.
5. Il démarre le service et lance une vérification de santé.

Chaque commande attend ton approbation avant d’être exécutée — le chat affiche les lignes docker compose up, tar xzf, caddy reload exactes que tu es sur le point de lancer.

4b. Cloner vers un nouveau domaine

Choisis cette option quand :

• Tu veux que l’original continue de fonctionner pendant qu’une copie est mise en ligne sur un autre domaine (préproduction, dev, démo, deuxième activité…).
• Tu restaures sur un serveur vers lequel pointe un domaine différent de celui de l’archive source.

Faro pose une question supplémentaire : quel est le nouveau domaine ? (par exemple staging.example.com).

Ce que fait Faro en plus des étapes de restauration sur place :

1. Il choisit un nouveau nom de projet compose (pour que les conteneurs du clone n’entrent pas en conflit avec ceux de l’original), par exemple mysite-com → staging-example-com.
2. Il réécrit l’entrée Caddyfile pour utiliser le nouveau domaine.
3. Il renouvelle les secrets dans .env (nouveau mot de passe de base de données, nouvelles clés d’application) — le clone ne partage pas les identifiants de l’original.
4. Pour WordPress, il exécute wp search-replace <old-domain> <new-domain> dans le conteneur cloné afin que les liens dans les articles et les métadonnées des médias pointent vers le nouveau domaine.
5. Pour les applications web, il met à jour les variables d’environnement *_URL / *_HOST qui pointent vers l’ancien domaine.
6. Il demande un nouveau certificat TLS pour le nouveau domaine (Let’s Encrypt via Caddy, automatique).

L’original continue de fonctionner sans être modifié.

Tu clones une base de données ? Les bases de données n’ont pas de domaine. Faro demande plutôt un suffixe court (comme staging ou qa) et l’utilise pour produire un nom de projet compose, un nom de conteneur et un port d’écoute uniques, afin que les deux bases puissent tourner côte à côte sans conflit.

Quand les étapes sont terminées, Faro affiche l’URL finale (clone) ou le domaine désormais restauré (sur place). Ouvre-le dans ton navigateur ; s’il ne se charge pas tout de suite, laisse 30 à 60 secondes à Let’s Encrypt pour émettre le certificat, puis réessaie.

L’archive d’origine est supprimée automatiquement de /tmp/helm-restore/ une fois la restauration terminée avec succès.

Incompatibilité de recette

Si tu as ouvert la fenêtre de restauration depuis un panneau de service (par exemple le panneau WordPress pour mysite.com) et envoyé une archive d’une autre recette (par exemple une archive Postgres), la fenêtre ne lance pas simplement la suite — elle t’avertit :

Tu as deux choix :

• Choisir un autre fichier — c’est presque toujours ce que tu veux (tu as pris la mauvaise archive).
• Utiliser quand même cette archive — c’est l’archive qui pilote la restauration, donc cela configurera un nouveau service correspondant à la recette de l’archive, et ne modifiera PAS celui dont tu as ouvert le panneau. Choisis cette option uniquement si tu comprends ce comportement et que c’est bien ce que tu veux.

La vérification d’incompatibilité ne se déclenche que lorsque la fenêtre a été ouverte depuis un panneau de service avec une recette attendue. Le chemin Actions → Restaurer l’ignore complètement (aucune attente à vérifier).

Restauration automatique après un déplacement de serveur à serveur

Si tu as utilisé onglet Sauvegarde → Déplacer vers un autre serveur sur un autre serveur et qu’une archive a été transférée ici, la fenêtre de restauration s’ouvre automatiquement avec cette archive mise en avant en haut :

Clique sur Restaurer cette archive et le reste du parcours est identique à une nouvelle restauration à partir de là (Faro demande restauration sur place ou clonage, tu approuves les commandes, etc.). L’archive est déjà sur le serveur, il n’y a donc pas d’étape d’envoi.

Tu peux aussi cliquer sur Utiliser une autre archive… pour fermer le préchargement et ouvrir le sélecteur de fichiers habituel — pratique si tu as transféré la mauvaise archive et que tu veux recommencer.

Questions fréquentes

Où se trouve l’original pendant un clonage ? Il reste intact. Le clone utilise d’autres noms de conteneurs, d’autres volumes, d’autres ports (pour les bases de données) et d’autres secrets. Tu peux supprimer le clone plus tard sans affecter l’original.

Puis-je restaurer une archive sur une autre distribution Linux ? Oui. L’archive contient simplement Docker compose + des volumes nommés + (pour les sites statiques) une arborescence de fichiers. Server Manager gère l’installation de Docker propre à la distribution sur la cible s’il est absent. L’exception concerne les archives d’applications web natives (hors conteneur) — elles dépendent du gestionnaire de paquets et de systemd de la distribution source, et l’article de restauration t’indiquera si l’installation ne peut pas être traduite.

L’archive est énorme — l’envoi va-t-il expirer ? Non. L’envoi est découpé en morceaux (~4 Mo par morceau) et le serveur les rassemble. Les archives de plusieurs Go fonctionnent ; si ta connexion coupe en plein envoi, la fenêtre te permet d’annuler et de recommencer plutôt que de repartir de zéro à chaque morceau.

Que se passe-t-il si j’annule en pleine restauration ? Si tu annules pendant l’envoi, le fichier partiel est supprimé et tu reviens à la zone de dépôt. Si tu annules pendant les étapes dans le chat (entre deux approbations), ce que Faro a déjà fait reste en place — certains conteneurs peuvent exister, certains volumes aussi. Tu peux relancer la restauration depuis la même archive, ou demander d’abord à Faro de nettoyer l’état partiel ; si quelque chose te paraît étrange, demande dans le chat et Faro diagnostiquera.

Puis-je restaurer la même archive plusieurs fois dans différents clones ? Oui. Rouvre la fenêtre, envoie la même archive, choisis cloner à chaque fois avec un nouveau domaine différent. L’archive reste valable indéfiniment (ce n’est qu’un tarball).

Où les restaurations échouées laissent-elles des fichiers ? Dans /tmp/helm-restore/<id>/ sur le serveur cible. Le Actions de l’écran d’accueil affiche les dossiers helm-restore orphelins dans la vue de nettoyage s’il en reste. Tu peux les supprimer sans risque.

Ce qui n’est PAS couvert ici

• Les fichiers **.helm-backup/** (annulation fichier par fichier dans l’onglet Fichiers) → voir la section « Récupérer un seul fichier » de l’article Sauvegardes.
• Les dumps de base de données bruts **.sql.gz** (chargeables dans n’importe quel Postgres/MySQL) → voir la section « Sauvegarder uniquement la base de données » de l’article Sauvegardes.
• La restauration entre recettes différentes (par exemple une archive WordPress en site statique) — les archives sont propres à une recette. Choisis une archive qui correspond à ce que tu veux remettre en ligne.

Référence

Ce dont la restauration a besoin sur le serveur cible :

• Le serveur Linux joignable en SSH auquel tu es connecté dans Server Manager.
• De l’espace disque pour extraire l’archive (environ 2× la taille de l’archive, brièvement, pendant l’extraction).
• Docker installé (Server Manager l’installe automatiquement s’il manque sur une cible neuve).

Chemins disque pendant la restauration :

• Archive envoyée (temporaire) → /tmp/helm-restore/<id>/<name>.tar.gz
• Source extraite → /tmp/helm-restore/<id>/extracted/
• Installation finale — le même chemin que celui utilisé par l’original (par exemple /opt/wordpress-mysite-com/, /var/www/mysite.example.com/, …)

L’arbre de décision en bref :