Backup et Cockpit

Second article de la mini série de la mise en place d’un serveur de développement. Partie 1 : Connexion SSH et sécurisation via UFW et Reaction

Dans la première partie on a vu ensemble comment faire ses premiers pas en SSH et à sécuriser une partie de son installation via UFW et Reaction.

A présent, on va s'occuper des backups et du monitoring via Cockpit.

Pourquoi faire des backups si ton installation est sûre ? C'est très simple, ton installation n'est pas sûre. Il y aura toujours un truc qui peut mal se passer, un sudo en trop, une mise à jour qui plante, un utilisateur malveillant qui réussit à s'introduire etc ...

Pour avoir négligé une fois la sauvegarde d’un serveur, je peux t’assurer qu’il n’y a pas pire moment où on se rend compte qu’on a tout perdu. On a toujours l’espoir de récupérer sa data par n’importe quel moyen et puis on finit par se résigner qu’on a tout perdu. C'est une douce sensation d'amertume qui reste autour de toi pendant un temps (et encore moi c'était juste du perso ... quand il y a une forte valeur ajoutée derrière ... c'est encore pire et préjudiciable pour ton client).

Je ne souhaite ça à personne et depuis c’est une des premières choses que je fais à l’installation d’un serveur.

On va donc parler de Borg ! (Non rien à voir avec le méchant du 5ème élément) mais plutôt une solution de backup sympa et plutôt simple à mettre en œuvre.

Pourquoi utiliser Borg ? Parce que c’est facile à comprendre et c’est une solution compatible sur beaucoup de systèmes UNIX donc universelle.

Je me base pour ce tuto sur celui de LinuxTricks car à chaque fois que j’ai besoin de borg, c’est chez lui que je vais ! N’hésites pas à y faire un tour pour approfondir le sujet.

On commence par l’installer avec apt install borgbackup

Pour les backups, on va se créer un répertoire à la racine de notre disque : mkdir /borg

A l’intérieur personnellement je mets un dossier par dossier que je veux sauvegarder :

cd /borg && mkdir etc var home root

Pour le serveur de dev, on fait l’impasse sur le chiffrement du backup mais évidemment que pour un serveur de prod, il faudra chiffrer les backups (RGPD et sécurité renforcé)

borg init -e none /borg/home && borg init -e none /borg/etc && borg init -e none /borg/var && borg init -e none /borg/root

Cette commande permet de créer un repository local (un peu comme sur Git).

Si tu as à ta disposition un serveur supplémentaire pour y stocker les backups tu peux aussi paramétrer un repo distant afin d’y envoyer les backups dessus directement mais pour la démo ce sera que uniquement du local. Pense à faire des copies en rsync par exemple vers ta machine pour sauver ton backup (oui car si ton serveur est down et que tes backups sont dessus … c’est comme laisser un extincteur en plein milieu d’un brasier, ça sert pas à grand chose.).

Pour le moment on a pas grand chose mais on peut quand même sauver certains trucs, comme des fichiers de conf par exemple. Pour ça on utilise la commande suivante :

borg create -C modedecompression,niveaudecompression /borg/repository::nomdubackup /dossierQueTuVeuxSauvergarder

borg create -C zstd,22 /borg/home::20250413 /home

-C zstd,10 c’est la compression avec le mode zstd de niveau 22.

Attention cependant, la compression ça utilise énormément le CPU. Moi j’ai un bon CPU sur mon proxmox donc je peux monter à 22. Cependant si c’est un petit serveur, situe toi plutôt entre 3 et 6.

Plus la compression est grande, moins les backups prennent de place sur ton disque.

Tu peux aussi ajouter dans la commande l’attribut –exclude ‘nomDeTonDossier’ pour éviter de backuper ce dossier dans l’ensemble de la sauvegarde.

borg create -C zstd,22 --exclude 'motd' /borg/home::2025-04-13

Si tu ré-exécutes la même commande, alors tu auras une erreur car Borg t'indiquera que le backup avec ce nom existe déjà.

On peut lister ses backup avec la commande borg list /repo

borg list /borg/home

A présent on a des sauvegardes “temporaires”, le mieux étant d’automatiser tout ça.

Pour ça, les systèmes linux ont le système crontab qui permet d'exécuter des tâches à intervalle régulier.

On va donc en créer une : nano /root/backup.sh

Dans ce fichier, je vais y mettre ce qui m’intéresse de sauvegarder avec Borg :

#! /bin/bash
dt=$(date '+%Y-%m-%d')

borg create -C zstd,22 /borg/var::$dt /var
borg create --progress -C zstd,22 /borg/etc::$dt /etc
borg create --progress -C zstd,22 /borg/home::$dt /home
borg create --progress -C zstd,22 /borg/home::$dt /root

Ce script permet d’automatiser la sauvegarde de mes trois dossiers que je trouve important de récupérer. Je vais à présent le rendre executable à l’aide de chmod : chmod +x /root/backup.sh puis l’enregistrer dans crontab : crontab -e ce qui va nous ouvrir le fichier de gestion des tâches cron. On rajoute cette ligne là :

0 3 * * * /root/backup.sh

Qu’est ce que ça signifie ?

A 3:00 tous les jours de la semaine.

On enregistre puis on a plus qu’à attendre la sauvegarde ! Tranquillou bilou !

Pour mieux comprendre les crons, je t’invite à passer sur ce lien (encore une fois de LinuxTricks) ainsi qu’à utiliser ce générateur de cron qui est sympathique quand on débute dans les tâches crons.

A présent qu’on a des sauvegardes de manière pérenne, ce serait sympa de pouvoir restaurer justement en cas de pépin.

On a donc deux méthodes pour ça, la méthode bien bourrine de “je prends le backup, je restaure tout” et l’autre plus fine qui consiste à naviguer dans le dépôt et à ne récupérer que ce que l’on veut.

• La Méthode barbare

C’est cette commande : borg extract --progress **/**borg/tonrepo::tonnomdesauvegarde

borg extract --progress /borg/etc::2025-05-04

ça va tout simplement prendre ta sauvegarde et la mettre par dessus ton système actuel. C’est bourrin, mais efficace (sauf si tu veux garder des trucs de ton système actuel)

Tu peux aussi être un peu plus fin si tu connais précisément le fichier ou le dossier à remplacer :

borg extract /borg/home::20250413 Téléchargements

• La méthode fine : le point de montage

On va venir créer un dossier qui servira de porte des étoiles à notre backup et on pourra ainsi naviguer dedans et prendre uniquement ce qui nous intéresse.

• mkdir /mnt/backup

• borg mount /borg/tonrepo::tasauvegarde /mnt/backup

De cette façon, on vient de créer un point d’accès vers notre backup et on peut y naviguer avec notre terminal

Exemple avec le backup 2025-04-13 pour home :

borg mount /borg/home::2025-04-13 /mnt/backup

Si je fais à présent un ls /mnt/backup j’ai le dossier /home qui est apparu !

Je peux donc m’y balader, déplacer des fichiers etc … très pratique pour restaurer des fichiers !

Une fois mon exploration terminée, je peux démonter le point de montage avec la commande

borg umount /mnt/backup

On va pouvoir à présent gérer notre politique de rotation de sauvegarde (afin d’éviter d’avoir une centaine de backups qui ne servent pas quotidiennement).

Avec la commande suivante, on va dire à Borg de ne garder que les backups quotidiens des 7 derniers jours,  une archive par semaine sur 4 semaines puis une archive par mois. :

borg prune -v --list --keep-daily=7 --keep-weekly=4 --keep-monthly=-1 /borg/tonrepo

cette commande, on va venir l’intégrer dans notre backup.sh du début pour chaque repo (/home /var /etc /root), comme ça à chaque fin de backup, Borg va venir faire le tri avec prune.

Et voila, tu sais maintenant comment générer des sauvegardes, naviguer dedans, restaurer des fichiers et même gérer la rotation !

Et encore une fois, ici rien n’est sauvé réellement puisque tout est gardé sur le même serveur. Pense à exporter tes backups avec un repo distant (borg init -e ssh://user@ipServeurBackup/borg/tonrepodistant). Et si tes données sont sensibles, alors chiffre les avec la commande adéquate !

J’espère que maintenant la gestion des backups ne te fait plus peur. De toute façon, personnellement je ne connais jamais les commandes par cœur, je refais toujours un petit tour chez LinuxTricks pour obtenir les commandes !

Passons ensuite à une partie un peu plus fun qui est le monitoring de ton serveur. Les commandes en CLI c’est sympa mais le graphique c’est quand même un peu plus confortable !

On va donc commencer par installer un petit tool de monitoring qui s’appelle Cockpit.

On commence avec un apt install cockpit

Une fois installé, tu peux faire un systemctl status cockpit et vérifier qu’il est bien activé et enabled.

Si il n’est pas activé, alors un petit coup de systemctl start cockpit devrait résoudre le problème.

Vérifie que ton port est bien visible avec netstat -tulpn :

Cockpit est installé, le port est bien ouvert.

Dans la partie 1 on avait cependant fermé les ports via le pare-feu donc même si tu fais http://tonIPServeur:9090, il ne se passera rien car UFW bloque les connexions entrantes.

Dans un premier temps on laisse comme ça tant qu’on a pas activé le Reverse Proxy pour éviter de divulguer plein de ports au web (n’oublie pas, toujours minimiser sa surface d’attaque).

On va donc passer par du Port Forwarding. C’est lié au protocole SSH et ça permet sans ouvrir des ports à l’extérieur, d’avoir accès aux ports locaux directement depuis ton PC.

Voici l’astuce :

ssh -L portDeTonPC:localhost:portDistant user@tonServeur

Expliquons un peu la commande :

• ssh => protocole ssh

• -L => port forwarding

• portDeTonPC : choisis un port dispo sur ton PC

• localhost : c’est ton PC

• portDistant => c’est le port de cockpit que tu veux joindre : 9090

Donc pour l’exemple ce serait : ssh -L 10000:localhost:9090 tonUser@tonServeur

Ouvre un nouveau terminal sur ton PC et tape donc cette commande, tu verras c’est comme si tu étais connecté en ssh.

Ensuite tu ouvres un navigateur et tu tapes http://localhost:10000 et là … tadaaaaam ! Tu es connecté sur l’interface Cockpit, sur le port 9090 de ton serveur sans l’avoir ouvert. Tout ça grâce à SSH.

Connecte toi ensuite avec ton login/password (Surtout pas en root sacrebleu ! De toute façon il est désactivé sur Cockpit)

A présent tu peux manager ton serveur depuis cette interface (d’où l'intérêt de laisser ton port fermé à l’extérieur car c’est ultra sensible).

Tu peux dans l’onglet “journaux” accéder à tes logs, tes alertes. Gérer le stockage, voir tes services, et même un Terminal de disponible (bon ça remplace quand même pas zsh !).

Pour les VPS, le menu “voir métriques et l’historique” est super sympa pour voir les ressources disponibles et restantes.

Et le jour où tu as d’autres serveurs, tu peux les relier sur le software aussi en ssh et ça permet de manager tes serveurs à un seul endroit.

Cockpit c’est bien mais ce qu’il faut retenir surtout c’est la technique du port forwarding qui te permet de ne pas prendre de risque grâce à SSH et d’accéder à tous les ports de ta machine car finalement c’est comme si tu étais en local dessus (idéal pour le développement par exemple).

Tu sais maintenant faire du port forwarding, gérer ton serveur avec Cockpit et surtout gérer tes backups.

Si tu as suivi la partie 1 de la gestion d’un serveur, alors avec cette partie 2 tu peux être serein et commencer à t’amuser un peu sans crainte de tout perdre !

Prochaine partie on s’attaque au reverse proxy et à HTTPS !