Bonjour,
Je suis sur un PI3 à jour avec trois disques durs en LVM.
Suite à la modification de la commande du lancement du DOcker, Storagenode redémarre sans cesse. A fore ce m’acharner dessus, le LVM est endommagé et je viens de prendre toutes les données contenues dans /storage…
C’est bien dommage après quasiment 4 mois de bons et loyaux services sans incident… Je pense que je suis obligé de repartir de zéro.
Je viens enfin de récupérer les données et de relancer le node.
En fait j’ai été suspendu cette après midi après avoir tenté de faire la mise à jour depuis la 1.5.2.
J’ignore maintenant si le node va reprendre son activité ou si je suis suspendu définitivement ?
Bonjour @UserRoot.
Bienvenu sur le forum !
La suspension n’est pas définitive. Elle survient lorsque le satellite détecte un disfonctionnement d’un noeud, mais qu’il n’a pas encore perdu de données (par exemple : noeud inaccessible, ou qui répond trop lentement…)
Si le fonctionnement de votre nœud est revenu à la normale, le suspension sera levée bientôt. Ceci est habituellement confirmé par un email.
Il faut juste être bien sûr que le nœud est bien en bonne santé et a toujours accès à toutes les données qu’il est censé stocker, car si des audits envoyés par les sattelites échouent, cela peut disqualifier un nœud très rapidement (24 à 48h).
Cela vaudrait peut-être le coup de surveiller les logs pour s’assurer qu’il n’y a pas d’erreurs liées aux audits. Ni d’autres erreurs d’ailleurs 
Bonjour et merci pour cette réponse réconfortante.
L’erreur vient d’un agrandissement significatif du LVM (+300%). Lors de la phase d’extension du système de fichiers : il semble que les fichiers sont restés longtemps en lecture seule. D’où la suspension car un satellite ne pouvait plus écrire de données. En voulant intervenir directement sur le node, je n’ai pas arrangé la situation.
A l’heure actuelle, tout fonctionne, le node se remplit, je ne suis plus suspendu par aucun satellite et je n’ai reçu aucun mail.
Merci.
Bonne journée.
Bonjour @UserRoot ,
Bienvenue sur le forum!
Si possible, essayez de vous éloigner de LVM - car sans utiliser la parité, c’est un RAID0 normal, si un disque tombe en panne, vous perdez toutes les données et tout l’hôte.
Dans le cas de plusieurs disques qui ne sont pas suffisants pour RAID6 / RAID10, il est préférable d’utiliser un storagenode et une identité distincts pour chaque disque.
Me voilà de retour pour les dernières nouvelles.
J’ai perdu définitivement mon node mais on apprend (je n’ai pas reçu encore le mail de bannissement…).
Le rajout d’un disque dur dans mon LVM a conduit à la perte de données du node (-de 1%). J’ignore d’où vient cette perte. Ce nouveau disque de récup a une taille de 3Tb en 4096bytes par secteur. Je pense avoir vu des conflits entre les 512 et 4096 bytes mais je n’ai plus rien à vous montrer.
Je suppose que je vais être banni. Je redémarre donc avec une nouvelle identité (je suppose que c’est ce qu’il faut faire).
On apprend tous les jours.
Bonne journée.
Le fait qu’il manque quelques données ne devrait pas empêcher le Node de démarrer à ma connaissance. Et si la quantité de données perdues est suffisamment faible, le Node n’est pas nécessairement condamné.
Il faudrait comprendre pourquoi le Node ne démarre plus, en regardant ce que les logs indiquent pour commencer, avec une commande comme docker logs --tail=50 <container_id> (permet de voir les 50 dernières lignes - ajuster “50” pour en afficher davantage).
En fonction de ce qui ressort de cette commande, peut-être pourrons-nous aller plus loin.
Tout ceci étant dit, si vous décidez de repartir de zéro avec de nouvelles entités, alors je vous recommande vivement de suivre la recommandation de @Alexey, en utilisant une identité par disque.
Voici la documentation sur la façon d’afficher les journaux: https://documentation.storj.io/resources/faq/check-logs
Si des données sont perdues, votre node sera disqualifié. Mais cela ne deviendra connu que lorsque le storagenode pourra être lancé.
Si le nœud est disqualifié sur tous les satellites, je recommande fortement de se débarrasser de LVM et d’utiliser les disques séparément.
Les volumes LVM répartis garantissent pratiquement que vous perdrez tôt ou tard toutes les données lorsqu’un seul disque d’un volume tombe en panne.
Je suis conscient du problème des LVM…
Maintenant pour récupérer le node c’est trop tard (j’ai tout fumé car il n’avait redémarré depuis hier 13:00°. Quant aux logs, j’avais vu vos précédents posts et utilisé la commande. Une base (voir plusieurs) était corrompue et comme le storagenode était sans arrêt en phase de redémarrage…
J’ai fini en mode bourrin.
Les bases de données sont généralement faciles à récupérer,
dans les cas extrêmes, vous pouvez commencer sans eux:
@Alexey unless I’m mistaking I believe @UserRoot did “trash” their data to start anew.
(Translation: @Alexey à moins que je ne me trompe, @UserRoot a jeté toutes ses données pour recommencer de zéro)
@UserRoot : Bien que cela doit être frustrant de perdre un Node de 4 mois, ce n’est pas encore une trop grande anciennetée, et je pense qu’il vaut mieux repartir proprement de zéro maintenant avec un Node par disque, plutôt que de rencontrer des problèmes avec LVM sur un Node très ancien qui n’aurait plus d’escrow et une réputation de fer 
Si cela n’est pas déjà fait, profitez-en pour parcourir quelques topics de bonnes pratiques pour limiter les risques, comme notamment la création d’un sous-dossier dédié à STORJ sur chaque disque pour éviter que les données des Nodes ne soient à la racine des supports de stockage, éviter les disques SMR si cela est possible, mettez en place du monitoring (via uptime robot ou équivalent au minimum par exemple, ou plus élaboré)… histoire de repartir sur de bonnes bases saines 