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 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 instances utilisent Apache 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 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
     v
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 :

• images ;
• fichiers attachés ;
• EAD ;
• CDC ;
• CSV ;
• FLV ;
• fichiers ;
• documents Excel ;
• lecteurs ;
• NC ;
• PDF ;
• réservations ;
• environnements de production et de préproduction 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 permettrait de garantir 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
      v
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 actuellement :

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 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 activée ; prochain cycle complet à contrôler.

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 sauvegardes quotidiennes ;
• 3 dernières sauvegardes ;
• 3 sauvegardes hebdomadaires ;
• 2 sauvegardes mensuelles.

Mode : snapshot Proxmox.

Sauvegarde locale

Exécution quotidienne :

23 h 00

Destination :

local

Mode :

• snapshot ;
• compression ZSTD.

Rétention :

• 1 sauvegarde quotidienne.

Sauvegarde vers beotos3

Exécution :

02 h 00

Destination :

beotos3-import-saturne3

Mode :

• snapshot ;
• compression ZSTD.

Rétention :

• 3 sauvegardes hebdomadaires ;
• 1 sauvegarde 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 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 h 02
SFTPGo	Opérationnel	ACL et montages validés
Snapshots ZFS	Opérationnel	Sanoid automatique
Backup VM → PBS4	Configuré	Quotidien à 21 h 00
Backup VM local	Configuré	Quotidien à 23 h 00
Backup VM → beotos3	Configuré	Job quotidien à 02 h 00
Backup configuration eole3 → PBS4	Opérationnel	Quotidien à 02 h 30
Backup données eole3 → beotos3	À contrôler	Sauvegarde réelle activée – prochain cycle à valider

11. 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.

Les points suivants méritent néanmoins un suivi :

1. Occupation du stockage AD64 : le volume est occupé à environ 79 %. Les ~7,5 To encore disponibles offrent une marge significative, mais l'évolution doit être surveillée compte tenu du volume des publications.
2. Sauvegarde eole3 → beotos3 : le prochain cycle complet de sauvegarde doit être contrôlé.
3. SFTPGo / port 8080 : vérifier si son exposition externe est nécessaire et conforme à la politique de sécurité.
4. VM 507 : l'épisode isolé de soft lockup observé le 6 septembre 2026 doit rester sous surveillance. Aucun symptôme de saturation ou de récidive n'est actuellement constaté.