Comment superviser un NAS Synology

Un NAS occupe une position inconfortable dans un parc : il contient souvent les données les plus critiques de l'entreprise, et il est fréquemment le dernier équipement à être supervisé. Beaucoup de structures découvrent qu'un disque était en panne le jour où le second lâche.

Or c'est précisément le type d'équipement où la supervision est la plus rentable : une défaillance de disque en RAID ne provoque aucune interruption visible. Rien ne signale le problème à l'utilisateur, et le NAS continue de fonctionner — sans redondance, en attendant la panne suivante.

Ce qu'il faut surveiller, par ordre de priorité

1. La santé des disques (SMART)

C'est la métrique la plus importante, et celle qui justifie à elle seule la supervision d'un NAS.

Les disques ne tombent pas brutalement : ils accumulent des secteurs réalloués, des erreurs de lecture et des délais d'accès anormaux pendant des semaines. Les attributs SMART exposent ces signaux bien avant la défaillance.

Attributs à surveiller en priorité :

• secteurs réalloués (Reallocated_Sector_Ct) : toute valeur non nulle qui augmente est un signal de fin de vie
• secteurs en attente (Current_Pending_Sector) : secteurs illisibles en attente de réallocation
• erreurs non corrigibles (Offline_Uncorrectable)
• température : au-delà de 50 °C en continu, la durée de vie se réduit sensiblement

Un disque avec quelques secteurs réalloués stables depuis des mois peut vivre longtemps. Un disque dont le compteur augmente de semaine en semaine doit être remplacé avant qu'il ne lâche.

2. L'état du volume RAID

La question à laquelle il faut pouvoir répondre à tout moment : le volume est-il dégradé ?

Un RAID 1 ou 5 avec un disque en panne fonctionne normalement pour les utilisateurs. Il n'a simplement plus aucune tolérance de panne. Si le second disque lâche pendant la reconstruction — période où les disques restants sont fortement sollicités — les données sont perdues.

Surveillez l'état du volume et, le cas échéant, la progression de la reconstruction. C'est le signal qui doit déclencher une intervention immédiate, pas une notification qui attend le lundi.

3. L'espace disponible

Un NAS plein bloque les sauvegardes qui y sont dirigées, souvent silencieusement. La conséquence est double : le partage ne fonctionne plus, et le mécanisme de sauvegarde qui devait vous protéger a cessé de fonctionner.

Surveillez chaque volume séparément, avec les seuils habituels. Attention aux instantanés : sur un volume Btrfs avec instantanés activés, l'espace consommé peut croître sans qu'aucun fichier ne soit ajouté.

4. Les sauvegardes et la synchronisation

Si le NAS est la destination de vos sauvegardes, son bon fonctionnement conditionne toute votre stratégie de restauration. Si le NAS est la source à sauvegarder, vérifiez que sa propre réplication fonctionne.

Un NAS sauvegardé nulle part n'est pas une sauvegarde : c'est une copie unique sur un équipement qui peut brûler, être volé ou chiffré par un rançongiciel.

5. Les températures et ventilateurs

Un ventilateur arrêté provoque une montée en température qui réduit la durée de vie de tous les disques simultanément. C'est une panne matérielle qui, non détectée, transforme un incident sur un disque en défaillance groupée.

Comment collecter ces métriques

Trois approches, par ordre de simplicité.

SNMP, la méthode recommandée

DSM intègre un agent SNMP qui expose l'essentiel : état des disques, état des volumes RAID, températures, espace disponible, état des ventilateurs et de l'alimentation.

Activation dans DSM : Panneau de configuration → Terminal & SNMP → SNMP. Activez SNMPv3 plutôt que v1/v2c — ces derniers transmettent la chaîne de communauté en clair.

Synology publie ses MIB, et les identifiants d'objet correspondants sont documentés publiquement. Côté supervision, un modèle SNMP générique permet d'interroger ces valeurs sans installer quoi que ce soit sur le NAS.

L'agent Zabbix, quand c'est possible

DSM repose sur Linux, et l'installation d'un agent Zabbix est techniquement envisageable sur certains modèles via les paquets de la communauté ou Docker. Cette voie est cependant moins fiable en pratique : les mises à jour de DSM peuvent désactiver les paquets tiers, et le support officiel est inexistant.

Sur un NAS de production, SNMP reste préférable.

Les notifications DSM, en complément

DSM sait envoyer des courriels sur les événements importants : disque défaillant, volume dégradé, température anormale. C'est un filet de sécurité utile, mais insuffisant comme supervision unique — il ne fournit ni historique, ni tendance, ni vision d'ensemble avec le reste du parc.

Activez-les de toute façon : deux mécanismes indépendants valent mieux qu'un, surtout sur un équipement qui porte vos données.

Les incidents typiques

• Un disque en panne non remarqué, jusqu'à ce que le second lâche. Le plus fréquent, et le plus coûteux.
• Un volume plein qui bloque les sauvegardes dirigées vers le NAS, sans erreur visible côté serveur.
• Des instantanés qui s'accumulent et remplissent le volume sans ajout de données.
• Un ventilateur arrêté qui fait monter la température de tous les disques.
• Une reconstruction RAID interrompue par un redémarrage, laissant le volume dégradé.
• Une synchronisation vers un site distant arrêtée depuis des semaines, découverte au moment de la restauration.

Avec Logiserv

La supervision par SNMP d'équipements réseau et NAS n'est pas couverte par les templates fournis, qui portent sur les serveurs Windows, Linux et macOS équipés d'un agent.

Un NAS peut néanmoins être intégré à une supervision Zabbix via les modèles SNMP standards, ce qui relève d'une configuration spécifique à votre parc.

Pour aller plus loin

• Surveiller l'espace disque d'un serveur — seuils et prévision de saturation
• Quelles métriques surveiller sur un serveur — le plan de supervision général
• Pourquoi superviser un serveur Linux — la logique de détection avant panne
• Supervision serveur Windows et Linux : le guide — la démarche complète