Bonjour à la Communauté WD et à l’équipe de Support,
Je rapporte un conflit de ressources sur mon WD My Cloud EX2 Ultra (sous My Cloud OS 5 avec la dernière maj firmware) qui cause des échecs répétés de sauvegarde Time Machine ™. J’ai identifié la cause en utilisant la ligne de commande (CLI) et j’ai trouvé une solution de contournement fonctionnelle.
Description du Problème
Les sauvegardes Time Machine depuis mon système macOS 26.1 (Tahoe) échouent systématiquement après la phase de préparation, affichant le message d’erreur : “Le disque s’est déconnecté. Echec de la sauveagarde”
Cet échec n’a commencé à se produire qu’après que mon NAS se soit rempli d’une quantité significative de données (plusieurs téraoctets), ce qui suggère un problème de “scaling” de ressources.
Conclusions du Diagnostic CLI (Cause Racine)
Le dépannage standard (câbles, versions SMB, veille des disques) n’a rien donné. Une analyse approfondie via SSH a révélé un grave conflit de mémoire :
-
Saturation RAM : La mémoire vive du NAS (environ 1 Go de RAM) était complètement saturée.
-
Processus coupables (haute %VSZ / %MEM) :
-
Le
restsdk-server(processus d’indexation/API Cloud de WD) utilisait plus de 90 % de la RAM. -
Le
otaclient(client de mise à jour Over-The-Air) réservait également de larges blocs de mémoire.
-
-
Le Conflit : Cette réservation massive de RAM ne laissait aucune ressource disponible pour Samba (
smbd) afin de gérer la charge d’E/S soutenue requise par Time Machine. Cela entraînait un délai d’attente système (timeout) et la déconnexion forcée du volume TM.
Point Crucial (Échec des Contrôles IHM) : Nous avons confirmé que le problème n’est pas résolu par l’interface utilisateur web :
-
J’ai tenté de désactiver le service en basculant
Accès Mobile et Web > OFFsur tous les partages, puis en redémarrant le NAS. -
Malgré cela, le
restsdk-servera immédiatement été relancé après le redémarrage, consommant à nouveau plus de 90 % de la RAM du NAS. Cela confirme que le service d’indexation est considéré comme obligatoire et ne peut pas être désactivé par les options IHM fournies.
Résolution (Solution de Contournement)
La seule méthode efficace pour stabiliser le NAS pour les sauvegardes TM a été de mettre manuellement en pause les processus problématiques via SSH. Cela libère l’accès au CPU et au disque sans que le démon de surveillance ne détecte l’arrêt du processus.
-
Arrêt/Suspension des Processus : Avant de démarrer une sauvegarde, je dois geler manuellement les processus :
Bash
# Vérifier le PID actuel avec top, puis exécuter : kill -STOP [PID_restsdk-server] kill -STOP [PID_otaclient] -
Lancement de la Sauvegarde : La sauvegarde Time Machine se termine avec succès.
-
Reprise des Processus : Une fois la sauvegarde terminée, je dois reprendre les processus :
Bash
kill -CONT [PID_restsdk-server] kill -CONT [PID_otaclient]
Demande au Support WD
Étant donné que cette solution de contournement est requise pour une fonction NAS fondamentale (la sauvegarde TM) et qu’elle met en lumière une faille dans la gestion des ressources de My Cloud OS 5, j’ai deux questions :
-
Correction Permanente : Étant donné que les contrôles IHM (y compris
Accès Mobile et Web > OFF) sont inefficaces, existe-t-il une solution officielle, sans passer par la ligne de commande, pour désactiver ou limiter de manière permanente l’utilisation des ressources par les processusrestsdk-serveretotaclient? -
Mises à Jour Futures : L’équipe WD est-elle consciente de ce problème de saturation de la RAM sur la plateforme My Cloud OS 5, et y a-t-il des plans pour publier une mise à jour du micrologiciel qui limite correctement ces services lors d’opérations d’E/S à forte charge (comme Time Machine) ?
Merci de votre assistance.
Herold
