Serveur dédié PDB-SRV

Serveur physique dédié du SINP AURA, destiné à porter la base PostgreSQL de GeoNature.

• Voir aussi : Infos services de l'hébergement SINP AURA
• Relevé du 2026-09-02.

• Nom : pdb-srv
• Port SSH : contacter le CBNA → adminsys [at] cbn-alpin.fr
• Hébergeur / Localisation : OVH / Gravelines (GRA04)
• Type hébergement : Serveur dédié (Bare Metal)
• Modèle : ADVANCE-2
• Processeur : AMD EPYC 4344P, 8 cœurs et 16 threads
• Mémoire vive : 64 Go DDR5 avec ECC sur puce
• Stockage : 4 NVMe de 960 Go en RAID logiciel, 1,8 To utile
• Bande passante publique : 3 Gbps
• OS / Distribution : Debian 13 (Trixie)
• IP Public : 51.91.50.49
• IP Privée : 10.0.1.40
• IPv6 Public : aucune
• Réseau privé : sinp-aura-vpn (vRack)
• Prix : XXX € HT/mois
• Historique :
  • 2026-09-02 - Montage des archives Borg ajouté à la stack de sauvegarde.
  • 2026-08-27 - Sauvegarde Borgmatic complète, dépôt local et dépôt distant sur bkp-srv.
  • 2026-08-19 - Création du cluster PostgreSQL 18.
  • 2026-07-30 - Installation de Debian 13 avec le RAID logiciel.

• Carte mère : MSI S3661
• BIOS : American Megatrends ES366AOC.10V
• BMC : ASPEED, IPMI présent
• Carte réseau : Intel E810-XXV, deux ports SFP28, pilote ice
  • Port public : enp10s0f0np0, lien 25 Gbps
  • Port privé : enp10s0f1np1, lien 25 Gbps, raccordé au vRack
• Deux emplacements mémoire libres sur quatre, 128 Go possibles

Relevé SMART du 2026-08-10, les quatre PASSED, 0 % d'usure et aucune erreur média.

Les températures courantes sont dans Grafana, elles ne sont pas reprises ici.

Les quatre disques sont formatés en secteurs logiques de 512 octets. Un disque de remplacement doit être formaté de la même façon avant d'être intégré à une grappe.

Le RAID est logiciel, géré par mdadm. Il n'y a pas de carte RAID. Chaque grappe est faite d'une partition par disque et s'étend donc sur les quatre disques.

Le RAID 10 a été retenu contre le RAID 6. À quatre disques les deux donnent la même capacité utile et le RAID 10 conserve le TRIM que le noyau désactive sur les grappes à parité, reconstruit plus vite et donne de meilleures performances.

Chaque grappe utilise la partition de même rang sur les quatre disques, p1 pour md1, p2 pour md2 et p3 pour md3. Il n'y a pas de /var séparé.

Ordre des membres de md3, tel que le donne mdadm –detail /dev/md3.

sudo su -
cat /proc/mdstat
mdadm --detail /dev/md3
grep . /sys/block/md*/md/mismatch_cnt
lsblk -o NAME,SIZE,TYPE,MOUNTPOINT,MODEL

Les trois mismatch_cnt doivent valoir 0. Le contrôle mensuel des grappes est automatique, voir la section des contrôles périodiques.

• Langue et clavier en français, fuseau Europe/Paris
• Mises à jour automatiques par unattended-upgrades. Un noyau mis à jour n'est chargé qu'au redémarrage suivant donc vérifier la version en cours avec uname -r avant de conclure qu'une mise à jour est appliquée.
• Mémoire compressée ZRAM à 25 % de la RAM, soit 16 Go, priorité 100
• Fichier d'échange /swapfile01 de 64 Go, priorité 10
• Pages mémoire transparentes forcées à never pour PostgreSQL
• Postfix en envoi seul vers le relais OVH, Fail2ban et RKHunter actifs

Connexion par clé uniquement, mot de passe refusé.

Firewalld avec trois zones. Seul SSH est ouvert depuis l'extérieur, sur un port personnalisé.

Le port 5432 de PostgreSQL n'est ouvert dans aucune zone.

Quatre configurations volontaires qui s'écartent du comportement attendu par défaut.

• Docker CE 29.7.2, Docker Compose 5.4.0
• Les stacks sont dans /home/admin/docker/

• Serveur et client 18.6, PostGIS 3.6.4, depuis le dépôt PGDG avec une priorité APT de 200
• Cluster 18/main en UTF-8, locale fr_FR.UTF-8
• Sommes de contrôle des données activées (data_checksums)
• Écoute uniquement sur la boucle locale

Borgmatic sauvegarde le système tous les jours à 6 h sur deux dépôts, un local et un distant sur bkp-srv. La sauvegarde des bases PostgreSQL n'est pas encore activée.

La clé SSH utilisée vers le serveur de sauvegarde est enfermée dans le seul dépôt de pdb-srv par une commande forcée. Elle n'ouvre aucun shell et ne donne pas accès aux dépôts des autres machines.

Les commandes ci-dessous utilisent les noms de dépôt local et bkp-srv, il n'y a donc pas besoin de connaître l'adresse du serveur de sauvegarde pour les exécuter.

cd /home/admin/docker/borgmatic
docker exec borgmatic sh -c '. /etc/environment; borgmatic repo-info'
docker exec borgmatic sh -c '. /etc/environment; borgmatic repo-list --repository local'
docker exec borgmatic sh -c '. /etc/environment; borgmatic repo-list --repository bkp-srv'
docker exec borgmatic sh -c '. /etc/environment; borgmatic list --repository local --archive latest'

repo-list donne les archives d'un dépôt, list donne le contenu d'une archive. Dans les exemples qui suivent, latest désigne la dernière archive et peut être remplacé par un nom d'archive donné par repo-list.

C'est la méthode la plus simple. Elle ne demande ni FUSE ni capacité particulière au conteneur. Elle se fait dans un conteneur jetable donc on écrit dans un dossier partagé avec l'hôte.

sudo su -
cd /home/admin/docker/borgmatic
rm -rf /tmp/restore
mkdir -p /tmp/restore
docker compose run --rm --no-deps -v /tmp/restore:/tmp/restore borgmatic borgmatic --verbosity 1 extract --repository local --archive latest --path mnt/source/etc/hostname --destination /tmp/restore
ls -l /tmp/restore/mnt/source/etc/

Le chemin s'écrit sans le slash du début. Les fichiers ressortent sous /tmp/restore/mnt/source/… puisque la racine du serveur est montée sur /mnt/source dans le conteneur.

Pour le dépôt distant, remplacer –repository local par –repository bkp-srv.

Le bloc s'exécute depuis un shell root pour une seule raison, le conteneur écrit en tant que root donc les fichiers produits lui appartiennent et le nettoyage du dossier temporaire échoue sans ces droits.

Utile quand on ne sait pas exactement quel fichier chercher. Le montage utilise FUSE et demande donc le conteneur de restauration.

sudo su -
cd /home/admin/docker/borgmatic
rm -rf /tmp/restore
mkdir -p /tmp/restore
docker compose -f docker-compose.yml -f docker-compose.restore.yml run --rm --no-deps -v /tmp/restore:/tmp/restore borgmatic

Puis, dans le shell du conteneur :

mkdir -p /tmp/repo
borgmatic mount --repository bkp-srv --archive latest --mount-point /tmp/repo
ls /tmp/repo/mnt/source/etc
mkdir -p /tmp/restore/mnt/source/etc
cp -a /tmp/repo/mnt/source/etc/hostname /tmp/restore/mnt/source/etc/
borgmatic umount --mount-point /tmp/repo
exit

Le fichier est copié dans la même arborescence que celle produite par l'extraction, pour que la remise en place ci-dessous fonctionne après l'une ou l'autre méthode.

Toujours dans le shell root ouvert plus haut. Rien ne doit être remplacé sans contrôle. Un fichier de configuration restauré peut être plus ancien que la configuration en cours et le service concerné peut avoir besoin d'être rechargé ensuite.

diff /tmp/restore/mnt/source/etc/hostname /etc/hostname
ls -l /tmp/restore/mnt/source/etc/hostname /etc/hostname
cp -a /etc/hostname /etc/hostname.back
cp -a /tmp/restore/mnt/source/etc/hostname /etc/hostname
ls -l /etc/hostname
rm -rf /tmp/restore

Vérifier dans l'ordre le contenu du fichier extrait, ses droits et son propriétaire, puis l'incidence sur le service qui l'utilise. Recharger ou redémarrer ce service si nécessaire.

• Telegraf envoie vers l'InfluxDB de la stack AURA, avec un jeton propre à pdb-srv en écriture seule
• Les tableaux de bord sont sur monitor.biodiversite-aura.net
• La disponibilité générale, l'état du RAID et l'état SMART des disques sont contrôlés par healthcheck.biodiversite-aura.net. Une tâche cron appelle les trois contrôles, il n'y a pas d'agent installé sur la machine.

Comparatif Fio entre le RAID 10 de pdb-srv et les deux stockages du serveur db-srv.

Latence au 99e percentile.

Mesuré le 2026-08-24 avec Fio, 16 tâches et 16 fichiers de 1 Go par cible, profondeur 32 en séquentiel et en écriture aléatoire, 16 en lecture aléatoire. Le Block Storage plafonne au même chiffre en lecture et en écriture séquentielles, c'est la limite du volume.