Wiki

Si on désire maîtriser l'informatique d'une TPE (ou même domestique indépendante), il faut se protéger de diverses défaillances, la plus critique étant celle du lien internet. En effet à moins de payer chez orange des prix conséquents, chez tout autre opérateur, une simple panne de DSLAM, ou pire un câble décroché, peut couper internet pendant plusieurs jours, ce qui n'est en général pas acceptable pour une TPE.

Autant le lien entrant (download) peut être recréé avec un simple smartphone, autant le lien sortant (upload) nécessite des solutions plus radicales. Celle abordée ici consiste en un “petit” serveur de secours situé dans un autre lieu, et chargé de prendre le relais en cas de défaillance du serveur principal quelle qu'en soit la raison, serveur lui-même ou lien internet.

Avant de définir serveur de secours, il faut décrire le serveur principal.

Celui-ci contient plusieurs foncions, serveur web, courriel, pabx… gérés dans autant de serveurs lxd.

lxd est un système de machines virtuelles qui permets de créer des serveurs spécialisés isolés les uns des autres. Par exemple, on veut mettre à jour un serveur www, par exemple, on sauve l'ancien serveur par une simple commande, et on commence la mise à jour. Pendant ce temps, le serveur mail continue à tourner. Et en cas de catastrophe une simple commande de quelques secondes permet de revenir à l'ancien serveur www et de réfléchir. Et le serveur mail n'a pas arrêté de fonctionner…

lxd est magique.

On a donc des machines virtuelles(vm) lxd, avec leur paramètres, associées à des données. Chaque vm (www, mail, sip,…) a donc une zone de paramètres, rangée dans /var/sauve/etc et une zone de data souvent dans /srv/. Le lien est fait par lxd, qui par exemple dans la machine www va “mapper” /var/www sur le répertoire /var/www de la vm www. Des liens judicieux complètent le dispositif de sorte que tous les paramètres de toutes les vms soient concentrés dans /var/sauve/etc.

Le plus économique, mais aussi le plus discret et silencieux - par exemple dans un domicile privé près d'une box - , est basé sur un raspberry pi 4 tel que celui proposé par freva, ici dans une version sans ventilateur mais avec 8G de RAM et un SSD de 1T et avec la version lite de Raspberry Pi OS, que freva fournit tout installé.

Pour ce type d'usage, sans utilisateur humain, avec seulement des connexions ssh en vue d'opérations de maintenance, on va utiliser lxd pour séparer les fonctions, mais travailler toujours en root, avec certificats (avec comme filet un mot de passe à rallonge pour l'utilisateur pi). Toute la suite est donc sous root.

D'autre part, on a décidé de ne pas utiliser DHCPCD, standard sur Raspberry OS, mais le bon vieux networking service.

systemctl stop dhcpcd
systemctl disable dhcpcd
apt remove dhcpcd5

Et on paramètre une adresse fixe sur le réseau local.

auto lo
iface lo inet loopback


auto eth0
iface eth0 inet static
        address 192.168.163.251
        netmask 255.255.255.0
        gateway 192.168.163.254
        network 192.168.163.0
        broadcast 192.168.163.255
        dns-nameservers 192.168.163.30 8.8.8.8
        dns-search couderc.eu

Après :

ifup eth0

(Il peut apparaitre une “too few arguments” inexpliquée, mais semble-t-il sans conséquence).

La nouvelle ainsi que l'ancienne adresse IP doivent répondre au ping…

Le serveur de secours est prêt. Il faut lui mettre la même adresse IP que le serveur principal, car sur le site distant il est plus simple d'avoir la même structure de réseau que sur le site principal. Puis on le transporte sur le site distant où on programme le router pour utiliser les mêmes adresses IPs locales que le site principal.

Une fois le serveur à destination, on peut y accéder de n’importe où par ssh. Et en particulier de son pc préféré.

On va copier les données sur le serveur de secours avec un script bas“ sur rsync :

#!/bin/sh
while true; do
	echo Start saving
	rsync $1  -az --del -e 'ssh -p 1433' /var/sauve/* sauve.couderc.eu:/var/sauve
	rsync $1  -az --del -e 'ssh -p 1433' /srv/mail/* sauve.couderc.eu:/srv/mail
	rsync $1  -az --del -e 'ssh -p 1433' /srv/git/* sauve.couderc.eu:/srv/git
	rsync $1  -az --del -e 'ssh -p 1433' /srv/gabc/* sauve.couderc.eu:/srv/gabc
	rsync $1  -az --del -e 'ssh -p 1433' /srv/www/* sauve.couderc.eu:/srv/www
	rsync $1  -az --del -e 'ssh -p 1433' /srv/photos/* sauve.couderc.eu:/srv/photos
	echo End Saving
	sleep 5m
done

Ce script relance la synchronisation toutes les 5 minutes, et est exécuté comme un service dans /etc/systemd/system/savsynchro.service

[Unit]
Description= Sauvegarde toutesles 5 mn sur sos.couderc.eu
After=network-online.target

[Service]
Type=simple
ExecStart=/usr/local/bin/savrsync.sh
Restart=on-failure
CPUSchedulingPolicy=idle

[Install]
WantedBy=multi-user.target

Note : le port 1433 est utilisé pour différencier le trafic de sauvegarde à très basse priorité sur ce port, du trafic ssh normal. Un système de contrôle de QoS est indispensable pour que ce script ne sature pas le débit montant de la ligne internet. Sinon,il faut le lancer à des heures tranquilles…

Si la sauvegarde a été décrite ici dans un ordre logique, on peut cependant faire une première sauvegarde pendant la phase de préparation avant de déplacer le serveur de sauvegarde…