Bilan technique AD64 - 2026

Bilan technique du service AD64 1. Architecture générale Le service des Archives départementales des Pyrénées-Atlantiques (AD64) repose sur trois fonctions techniques distinctes : - Saturne3 / VM 507 « AD64 » : hébergement de la plateforme applicative Pleade 4.5 ; - eole3 : stockage des données AD64, mise à disposition NFS pour la VM, accès SFTP, réception des synchronisations provenant du serveur du client et snapshots ZFS ; - beotos3 / PBS4 : sauvegarde des données et des systèmes. Les données volumineuses ne sont donc pas stockées dans la VM applicative : celle-ci dispose d'un disque système dédié et accède aux données AD64 hébergées sur eole3 par NFS. 2. Plateforme applicative – VM 507 AD64 La plateforme est hébergée sur la VM 507 – AD64, sur l'hyperviseur Proxmox Saturne3. Ressources de la VM Ressource Configuration CPU 8 vCPU – 2 sockets × 4 cœurs Mémoire 64 Gio maximum Ballooning minimum 16 Gio Disque système 100 Go Contrôleur VirtIO SCSI Stockage Proxmox local-zfs Réseau applicatif 10.0.0.41/24 Réseau données 192.168.123.41/24

Le disque virtuel de 100 Go est hébergé sur un pool ZFS constitué de 4 SSD NVMe Samsung d'environ 960 Go, organisés en RAIDZ1. Le pool est actuellement ONLINE et ne présente aucune erreur ZFS connue. Le système de fichiers de la VM occupe environ 36 Go sur 99 Go, soit environ 37 %. Environnement logiciel Composant Version Application Pleade 4.5 Système Ubuntu 26.04 LTS – Resolute Raccoon Noyau Linux 7.0.0-30-generic Apache HTTP Server 2.4.66 Java OpenJDK 17.0.20 – 64 bits Apache Tomcat 9.0.98 MariaDB 11.8.6

Trois instances Tomcat Pleade 4.5 sont installées : Instance Fonction internet site Internet preprod préproduction slecture salle de lecture

Les trois utilisent Tomcat 9.0.98 et OpenJDK 17.0.20. Lors du contrôle, les trois JVM fonctionnaient normalement et la VM ne présentait aucune pression significative sur la mémoire ou le CPU. Accès aux données Les données sont montées depuis eole3 en NFSv4.2 : 192.168.123.202:/var/data/ad64-data/data

       →

/var/data/ad64-data/data La liaison utilise le réseau interne 192.168.123.0/24. Observation système Un épisode de soft lockup Linux a été enregistré le 6 septembre 2026, affectant simultanément plusieurs vCPU, notamment des threads Java/GC et kcompactd. Aucune nouvelle occurrence n'a été observée lors des contrôles ultérieurs et la charge actuelle de la VM est faible. Cet événement est donc à surveiller, sans signe actuel de dysfonctionnement du service. 3. Stockage des données – eole3 eole3 assure le stockage principal des données AD64. Le dataset ZFS est : data/clients/ad64-data monté sous : /var/data/ad64-data Capacité Capacité État Volume total ~35 To Utilisé ~28 To Disponible ~7,5 To Occupation ~79 %

Le volume reste donc opérationnel avec une réserve d'environ 7,5 To, mais son évolution doit être surveillée compte tenu de son taux d'occupation. La partie utilisée par Pleade est située sous : /var/data/ad64-data/data et est accessible à la VM 507 par NFS. 4. Synchronisation des données du client vers eole3 Les données provenant du serveur des AD64 sont synchronisées quotidiennement vers eole3. La connexion ne pouvant être initiée depuis AJLSM vers le serveur du client, le transfert fonctionne obligatoirement en PUSH depuis le serveur AD64 : Serveur AD64

    │
    │ SSH + rsync
    ▼

eole3 51.178.110.230 Le transfert est programmé quotidiennement à : 17 h 02 Il utilise une clé SSH dédiée et rsync. Le périmètre actuel comprend notamment les images, fichiers attachés, EAD, CDC, CSV, FLV, fichiers, documents Excel, lecteurs, NC, PDF et réservations, pour les environnements concernés. Le transfert ne comporte volontairement pas de --delete : la synchronisation entrante ne supprime donc pas automatiquement sur eole3 les données absentes de la source. État : opérationnel. 5. Accès SFTP aux données eole3 héberge également le service SFTPGo utilisé pour l'accès sécurisé aux données : sftpgo.ajlsm.com:2022 Le service est activé et fonctionnel. Le compte ad64 est actif et dispose de deux espaces virtuels principaux : /pleade /projets correspondant aux espaces physiques : /var/data/ad64-data/data/pleade /var/data/ad64-data/data/projets Les droits sont définis finement selon les sous-répertoires. Les espaces de production permettent notamment les opérations nécessaires de dépôt, téléchargement, remplacement, création de répertoires, renommage et suppression. Aucun quota SFTPGo spécifique n'est imposé au compte AD64. Point de vigilance Le contrôle a montré que SFTPGo écoute également sur le port 8080 sur toutes les interfaces et que des requêtes externes atteignent ce service. Cela ne constitue pas en soi la constatation d'une compromission, mais l'exposition du port 8080 devra être revue afin de vérifier qu'elle correspond bien à la politique d'accès souhaitée. 6. Snapshots ZFS Les données AD64 font l'objet de snapshots ZFS automatiques gérés par Sanoid 2.2.0. AD64 utilise le profil : template_tres_gros_volume avec la politique suivante : hourly = 2 daily = 1 monthly = 0 autosnap = yes autoprune = yes Sont donc conservés : - les 2 derniers snapshots horaires ; - le dernier snapshot quotidien. Les snapshots sont créés et purgés automatiquement. Ils permettent notamment de revenir rapidement sur un état antérieur du volume en cas de suppression ou modification accidentelle récente. Une évolution possible, non mise en œuvre actuellement, consisterait à effectuer la sauvegarde vers beotos3 depuis un snapshot ZFS figé plutôt que depuis les données actives. Cela garantirait une image temporellement cohérente lors des périodes de publication intensive. 7. Sauvegarde des données AD64 sur beotos3 Les données hébergées sur eole3 sont sauvegardées vers beotos3. Contrairement à la synchronisation provenant du client, cette opération est initiée depuis le serveur de sauvegarde : eole3 192.168.123.202

     │
     │ rsync PULL
     ▼

beotos3 /var/data/ad64-data La sauvegarde est programmée : chaque vendredi à 18 h 59. Elle utilise rsync via SSH avec une limitation de priorité CPU/IO afin de ne pas perturber les autres services. Le mode réel de sauvegarde est désormais : DRY_RUN=0 QUARANTINE_ENABLED=1 QUARANTINE_RETENTION_DAYS=7 Les suppressions nécessaires au maintien du miroir sont donc appliquées, mais les éléments concernés sont conservés temporairement dans une quarantaine pendant 7 jours avant leur purge. Les volumes importants de suppressions et créations observés lors du contrôle sont cohérents avec le fonctionnement de Pleade : les opérations de publication suppriment puis régénèrent de grands ensembles de fichiers. État : sauvegarde réelle réactivée ; prochaine exécution à contrôler après le premier cycle. 8. Sauvegardes de la VM 507 La VM AD64 est incluse dans trois dispositifs de sauvegarde Proxmox distincts. Sauvegarde PBS4 Exécution quotidienne : 21 h 00 Destination : PBS4 Rétention : - 7 quotidiennes ; - 3 dernières sauvegardes ; - 3 hebdomadaires ; - 2 mensuelles. Mode snapshot Proxmox. Sauvegarde locale Exécution quotidienne : 23 h 00 Destination : local Compression ZSTD, mode snapshot. Rétention : 1 sauvegarde quotidienne. Sauvegarde vers beotos3 Exécution : 02 h 00 Destination : beotos3-import-saturne3 Compression ZSTD, mode snapshot. Rétention : - 3 hebdomadaires ; - 1 mensuelle. Bien que cette sauvegarde soit annotée « Hebdomadaire » dans Proxmox, son calendrier est 02:00 sans restriction de jour : le job est donc lancé quotidiennement, la politique de rétention étant, elle, hebdomadaire et mensuelle. Les trois jobs sont activés et la VM 507 figure explicitement dans leur périmètre. Une notification par courrier électronique est configurée en cas d'échec. 9. Sauvegarde de la configuration d'eole3 Indépendamment des données AD64, eole3 fait lui-même l'objet d'une sauvegarde quotidienne de sa configuration vers PBS4. Elle est exécutée chaque jour à : 02 h 30 Elle comprend notamment : /etc /usr/local /root /var/lib/sftpgo /var/log Cette sauvegarde permet de restaurer la configuration du serveur et du service SFTPGo ; elle ne remplace pas la sauvegarde des 28 To de données AD64. Une sauvegarde spécifique de la configuration SFTPGo est également exécutée quotidiennement à 02 h 15. 10. État général du service Composant État Observation VM 507 AD64 🟢 Opérationnel Ressources largement suffisantes actuellement Pleade 4.5 – Internet 🟢 Opérationnel Tomcat 9 / Java 17 Pleade 4.5 – Préproduction 🟢 Opérationnel Tomcat 9 / Java 17 Pleade 4.5 – Salle de lecture 🟢 Opérationnel Tomcat 9 / Java 17 Stockage eole3 🟢 Opérationnel 28 To / 35 To, occupation à surveiller NFS eole3 → VM 507 🟢 Opérationnel NFSv4.2 Rsync client → eole3 🟢 Opérationnel PUSH quotidien 17:02 SFTPGo 🟢 Opérationnel ACL et montages validés Snapshots ZFS 🟢 Opérationnel Sanoid automatique Backups VM → PBS4 🟢 Configuré Quotidien 21:00 Backup VM local 🟢 Configuré Quotidien 23:00 Backup VM → beotos3 🟢 Configuré Job quotidien 02:00 Backup config eole3 → PBS4 🟢 Opérationnel Quotidien 02:30 Backup données eole3 → beotos3 🟠 À contrôler Réactivé en mode réel, prochain cycle à valider

Points de vigilance Le service est globalement opérationnel et dispose de plusieurs niveaux complémentaires de protection : snapshots ZFS, sauvegarde des données sur un serveur distinct, sauvegardes multiples de la VM et sauvegarde PBS des configurations. Trois points méritent néanmoins un suivi : 1. Stockage AD64 à 79 % : les ~7,5 To encore disponibles offrent une marge significative, mais l'évolution doit être suivie compte tenu du volume des publications. 2. Sauvegarde eole3 → beotos3 : le mode réel vient d'être réactivé après une période de simulation ; il convient de contrôler le prochain cycle complet et sa quarantaine. 3. SFTPGo / port 8080 : vérifier si son exposition externe est nécessaire et conforme à la politique de sécurité. L'épisode isolé de soft lockup observé sur la VM le 6 septembre doit également rester sous surveillance, mais aucun symptôme de saturation ou de récidive n'est actuellement constaté.