Sauvegarder ses serveurs Coolify chez soi, sur Proxmox

Photo by Christina @ wocintechchat.com M / Unsplash

Vos applications tournent sur un ou plusieurs VPS gérés avec Coolify, et certaines servent de vrais clients. Que se passe-t-il si un serveur tombe, si une base est corrompue ou si un fichier est supprimé par erreur ? Dans cet article, je vous montre comment mettre en place une sauvegarde automatique, chaque nuit, vers une machine que vous contrôlez chez vous : une VM sur Proxmox.

La méthode fonctionne quel que soit votre hébergeur (OVH, Hetzner, Scaleway…). Elle ne demande aucune interruption de service et n'oblige à ouvrir aucun port sur votre box internet.

Pourquoi un simple rsync ne suffit pas

Le premier réflexe est souvent de copier tout le serveur avec rsync. Pour les bases de données, c'est un piège.

Imaginez que vous photocopiez un cahier page par page pendant que quelqu'un continue d'écrire dedans. La page 1 est photocopiée à 3h00, la page 50 à 3h10. Entre-temps, la personne a modifié les pages 1 et 50. Votre photocopie mélange deux états différents du cahier : elle est incohérente.

C'est exactement ce qui arrive quand on copie avec rsync les fichiers d'une base de données (Postgres, MySQL…) pendant qu'elle tourne. Les fichiers sont copiés les uns après les autres, pendant que la base continue d'écrire dedans. Le résultat peut être inutilisable, et vous ne le découvrirez qu'au moment où vous en aurez besoin.

La solution consiste à demander à la base elle-même de produire un dump. C'est un fichier d'export que la base génère de façon cohérente, comme une photo prise d'un seul coup, sans s'arrêter de fonctionner. On sauvegarde ensuite ce fichier, qui lui ne bouge plus.

Pour les autres fichiers (images envoyées par vos utilisateurs, configuration de Coolify…), ce problème n'existe pas : un rsync classique suffit.

Le principe général

Le système fonctionne en trois temps, chaque nuit :

Vers 2h00, sur chaque serveur : Coolify fait un dump de chaque base de données et le range dans un dossier.
Vers 3h30, depuis votre Proxmox : votre machine locale se connecte aux serveurs et récupère tout (les dumps, les fichiers de Coolify et les volumes Docker).
Sur votre Proxmox : un outil conserve l'historique, par exemple les 7 derniers jours, les 4 dernières semaines et les 6 derniers mois. En cas de problème, vous pouvez revenir à n'importe laquelle de ces dates.

C'est votre machine locale qui va chercher les données, et non les serveurs qui les envoient. Vous n'avez donc rien à ouvrir sur votre box internet. Et si un serveur est piraté, l'attaquant ne peut pas atteindre vos sauvegardes.

Étape 1 : activer les dumps dans Coolify

Cette étape est à faire sur chacune de vos instances Coolify.

Dans l'interface, ouvrez chaque base de données (Projets → votre projet → la base). Allez dans l'onglet Backups, puis ajoutez une sauvegarde planifiée. Réglez la fréquence sur une fois par jour, par exemple à 2h00 (en syntaxe cron : 0 2 * * *). Pour le nombre de sauvegardes à garder sur le serveur, 3 suffisent, puisque l'historique long sera conservé sur votre Proxmox.

Faites de même pour la base interne de Coolify, dans les paramètres de l'instance (section Backup). C'est elle qui contient toute votre configuration : projets, domaines, variables d'environnement.

Une fois la sauvegarde activée, lancez-en une manuellement et vérifiez en SSH que des fichiers apparaissent :

ls -lR /data/coolify/backups/

Étape 2 : préparer la machine de sauvegarde sur Proxmox

Créez une VM (ou un conteneur LXC) Debian sur votre Proxmox. C'est elle qui stockera les sauvegardes, donc donnez-lui assez de disque.

Pour estimer la place nécessaire, regardez la taille des données sur chaque serveur :

du -sh /data/coolify /var/lib/docker/volumes

Prévoyez environ 2 fois le total de vos serveurs. L'outil utilisé à l'étape 4 ne stocke qu'une seule fois les fichiers inchangés : 30 jours d'historique ne prennent donc pas 30 fois la place.

Installez ensuite les outils nécessaires sur cette VM :

apt update && apt install rsync rsnapshot

Étape 3 : autoriser la VM à se connecter aux serveurs

Sur la VM de sauvegarde, créez une clé SSH. Appuyez sur Entrée à chaque question, sans mot de passe, car le script tournera seul la nuit :

ssh-keygen -t ed25519

Copiez-la ensuite sur chacun de vos serveurs (remplacez par vos vraies adresses IP) :

ssh-copy-id root@IP_SERVEUR_1
ssh-copy-id root@IP_SERVEUR_2

Testez : la commande suivante doit vous connecter sans demander de mot de passe.

ssh root@IP_SERVEUR_1

Si la connexion en root est refusée (c'est parfois le cas par défaut chez certains hébergeurs, où l'on se connecte avec l'utilisateur debian ou ubuntu), autorisez-la par clé uniquement. Sur le serveur, dans /etc/ssh/sshd_config, indiquez PermitRootLogin prohibit-password, puis redémarrez SSH avec systemctl restart ssh. Le compte root est nécessaire ici, car les volumes Docker ne sont lisibles que par lui.

Étape 4 : configurer rsnapshot

rsnapshot est un outil qui s'appuie sur rsync, mais conserve un historique. Chaque jour, vous obtenez un dossier qui ressemble à une copie complète. En réalité, les fichiers inchangés ne sont stockés qu'une seule fois sur le disque, grâce aux liens physiques.

Ouvrez son fichier de configuration :

nano /etc/rsnapshot.conf

Attention, piège classique : dans ce fichier, les éléments de chaque ligne doivent être séparés par des tabulations, pas par des espaces. Sinon, rsnapshot refuse de fonctionner.

Modifiez ou ajoutez ces lignes (les espaces ci-dessous représentent des tabulations) :

snapshot_root	/backup/
cmd_ssh	/usr/bin/ssh

retain	daily	7
retain	weekly	4
retain	monthly	6

backup	root@IP_SERVEUR_1:/data/coolify/	serveur-1/
backup	root@IP_SERVEUR_1:/var/lib/docker/volumes/	serveur-1/
backup	root@IP_SERVEUR_2:/data/coolify/	serveur-2/
backup	root@IP_SERVEUR_2:/var/lib/docker/volumes/	serveur-2/

Les lignes retain signifient : garder 7 sauvegardes quotidiennes, 4 hebdomadaires et 6 mensuelles. Les lignes backupindiquent quoi récupérer et dans quel sous-dossier le ranger.

Vérifiez la configuration, puis lancez une première sauvegarde à la main. La première sera longue, car elle copie tout :

rsnapshot configtest
rsnapshot daily

À la fin, vous devez retrouver vos fichiers dans /backup/daily.0/serveur-1/ et /backup/daily.0/serveur-2/.

Étape 5 : automatiser chaque nuit

Créez le fichier /etc/cron.d/rsnapshot avec ce contenu :

0 3 1 * *    root  /usr/bin/rsnapshot monthly
15 3 * * 0   root  /usr/bin/rsnapshot weekly
30 3 * * *   root  /usr/bin/rsnapshot daily

Concrètement : tous les jours à 3h30, une sauvegarde quotidienne ; le dimanche à 3h15, la rotation hebdomadaire ; le 1er du mois à 3h00, la rotation mensuelle. L'horaire de 3h30 laisse le temps aux dumps Coolify de 2h00 de se terminer.

Votre VM Proxmox doit évidemment être allumée à cette heure-là.

Étape 6 : vérifier que vous savez restaurer

Une sauvegarde n'a de valeur que si vous savez la restaurer. Faites un essai une fois par mois.

Pour une base de données, récupérez le dump dans /backup/daily.0/serveur-1/data/coolify/backups/…. Réimportez-le ensuite dans une base de test, par exemple sur une VM Proxmox jetable. Pour un dump Postgres, cela se fait avec pg_restore ; pour MySQL, avec la commande mysql. Vérifiez que vos tables et vos données sont bien là.

Pour un fichier supprimé par erreur (une image envoyée par un client, par exemple), il suffit d'aller le chercher dans le dossier du jour voulu (daily.0 = hier, daily.1 = avant-hier, etc.) et de le renvoyer sur le serveur avec rsync ou scp.

Et pourquoi pas une image complète du serveur ?

Cloner tout le VPS dans une VM chez soi est tentant, mais apporte peu. Le système et Coolify se réinstallent en quelques minutes ; seules vos données sont irremplaçables, et cette méthode les récupère déjà. Une image complète copiée à chaud aurait en plus le même problème de cohérence que le rsync des bases. Si vous voulez une image de la machine entière, l'option de snapshot ou de sauvegarde automatique de votre hébergeur est le bon outil : elle se restaure directement là où le serveur doit tourner.

Deux rappels importants

La clé APP_KEY. Pour chaque instance Coolify, récupérez la valeur de APP_KEY dans /data/coolify/source/.env et rangez-la dans un gestionnaire de mots de passe. Coolify s'en sert pour chiffrer vos clés SSH et vos secrets : sans elle, une sauvegarde de Coolify est inexploitable. Elle figure aussi dans vos sauvegardes, mais si votre VM Proxmox tombe en panne au mauvais moment, vous serez content de l'avoir ailleurs.

Les données de vos clients. Ces sauvegardes contiennent des données personnelles et sont stockées chez vous : protégez la VM. Chiffrez son disque si possible, limitez les accès et appliquez les mises à jour. C'est aussi une obligation au sens du RGPD.

Conclusion

En une heure de mise en place, vous obtenez des sauvegardes quotidiennes, cohérentes et versionnées de vos serveurs Coolify, sans interruption de service ni port ouvert chez vous. Combinée aux snapshots de votre hébergeur, cette approche couvre aussi bien l'erreur de manipulation que la panne d'un datacenter entier. Le plus important reste de tester régulièrement une restauration : c'est le seul moyen de savoir que tout fonctionne.