Jump to content
Sethenès

Remplacer les disques d'un Synology sans Raid et sans Spare

Recommended Posts

Les étapes à faire sur le 710, ou sur le DS918+ après l'avoir installé.

 

1) activer les packets bêta

2) installer les diskutils

3) ouvrir le port telnet dans Terminal & SNMP

 

Ensuite se connecter au départ d'un PC/Mac via un shell

 

4) telnet 192.168.1.xxx

 

A l'invite du mot de passe, taper enter. Pourquoi parce que par défaut le user est root et root est désactivé depuis la version 6.0.

 

Ensuite le telnet redemande

userid : admin

password : le mot de passe du syno

 

Ou alors lancer telnet -l admin 192.168.1.xxx

et comme mot de passe, celui du Syno du syno

 

5) utiliser les commandes pour vérifier les disques présents :

sudo fdisk -l

 

Ce qui donne par exemple sur le SYno actuel (2 premiers disques) :

Disk /dev/sda: 2.7 TiB, 3000592982016 bytes, 5860533168 sectors

Units: sectors of 1 * 512 = 512 bytes

Sector size (logical/physical): 512 bytes / 4096 bytes

I/O size (minimum/optimal): 4096 bytes / 4096 bytes

Disklabel type: gpt

Disk identifier: 1061D67E-6165-40C6-BC94-06AEC8E3CBA6

 

Device Start End Sectors Size Type

/dev/sda1 256 4980735 4980480 2.4G Linux RAID

/dev/sda2 4980736 9175039 4194304 2G Linux RAID

/dev/sda3 9437184 5860528064 5851090881 2.7T Linux RAID

 

 

Disk /dev/sdb: 2.7 TiB, 3000592982016 bytes, 5860533168 sectors

Units: sectors of 1 * 512 = 512 bytes

Sector size (logical/physical): 512 bytes / 4096 bytes

I/O size (minimum/optimal): 4096 bytes / 4096 bytes

Disklabel type: gpt

Disk identifier: BE2EC556-6229-4884-AFFD-4390B3F348A1

 

Device Start End Sectors Size Type

/dev/sdb1 256 4980735 4980480 2.4G Linux RAID

/dev/sdb2 4980736 9175039 4194304 2G Linux RAID

/dev/sdb3 9437184 5860528064 5851090881 2.7T Linux RAID

 

On voit bien les 2 mini-partitions cachées que Syno installe (les /dev/sda1 et /dev/sda2 sur le premier disque et /dev/sdb1 et /dev/sdb2 sur le deuxième disque). Dans mon cas, les "seuls" disques visibles depuis le Syno sont le /dev/sda3 et le /dev/sdb3.

 

J'essayerai de faire un lump quand j'aurais installé un disque neuf, mais imaginons que ce soit /dev/sdc

 

Lancer la "fameuse commande" : sudo ./screen /bin/sh -c '/usr/local/diskutils/sbin/badblocks -wv -b 4096 -c 4096 /dev/sdc > /root/badblocks_sdc.log 2>&1' &

 

Cette commande utilise :

- l'outil screen (qui permet de ne pas arrêter un processus quand on se déconnecte, c'est pour lui qu'on a besoin des diskutils)

 

- outil screen qui démarre un shell /bin/sh

- dans lequel la commande /usr/local/diskutils/sbin/badblocks -wv -b 4096 -c 4096

- est lancée sur le disque /dev/sdc (disque parce si c'était une partition, il y aura un n°) et c'est la qui ne faut pas se tromper

- et dont les outputs sont redirigés dans un fichier crée dans /root et qui s'appelle /root/badblocks_sdc.log

- et non seulement les messages standards mais aussi les erreurs, c'est ça le 2>&1

- et le dernier &, c'est pour lancer la tâche en background et récupérer la main pour lancer la commande sur le 2ème disque :

sudo ./screen /bin/sh -c '/usr/local/diskutils/sbin/badblocks -wv -b 4096 -c 4096 /dev/sdd > /root/badblocks_sdd.log 2>&1' &

 

où les 2 sdc ont été remplacé par sdd. Le premier pour tester sur le disque n°4 (dans mon cas) et le second pour avoir un fichier séparé.

 

Par la suite on peut suive l'évolution en tapant :

 

sudo cat /root/badblocks_sdd.log

 

Et l'output après quelques jours doit donner :

 

Checking for bad blocks in read-write mode

From block 0 to 732566645

Testing with pattern 0xaa: done

Reading and comparing: done

Testing with pattern 0x55: done

Reading and comparing: done

Testing with pattern 0xff: done

Reading and comparing: done

Testing with pattern 0x00: done

Reading and comparing: done

Pass completed, 0 bad blocks found. (0/0/0 errors)

Share this post


Link to post
Share on other sites

Effectivement, surtout ne pas casser le raid du 710 avant d'avoir déplacé les données.

 

Mais dans ce cas, tu installes vite fait un Syno avec les 4 disques et tu fais ce que je suggère. Tu testes les 3 disques (probablement) :

 

/dev/sdb

/dev/sdc

/dev/sdd

 

Ensuite, tu échanges le 1er disque et le deuxième et tu réinstalles le Syno.

 

Et tu relances la commande sur /dev/sdb seul puisque c'est l'ancien premier disque que tu n'as pas pu tester.

 

Si tu veux un raid, logiquement, tu réinstalles une 3ème fois le Syno, cette fois directement sur un Raid de 4 disques testés.

 

Ce que je vais faire, c'est plus simple. Je vais tester 2 disques sur mon ancien Syno. Ensuite, je vais tester les 2 autres, toujours sur l'ancien Syno.

 

Et ensuite, je mets les 4 disques dans le nouveau et j'installe directement en raid.

 

Pour LYC par exemple, il aurait pu tester 2 disques, puis 2 disques. Ensuite créer un raid, copier les données. sortir les 3 disques. Ajouter les 2 déjà testés plus le 5ème et le tester pendant avant d'étendre le raid.

Share this post


Link to post
Share on other sites

Merci pour ce temps.

 

J'arrive jusqu'à 4 sans pb.

nota : je précise que toutes ces info. ont été notées / comprises et vérifiées voire mises en œuvre …

 

Je comprends que c'est une précaution de centralisation.

 

@ 5 : pb de droits > peux pas lancer certaines commandes …

 

---

 

A noter que pour cette commande : sudo ./screen /bin/sh -c '/usr/local/diskutils/sbin/badblocks -wv -b 4096 -c 4096 /dev/sdd > /root/badblocks_sdd.log 2>&1' &

 

- il faut bien vérifier que la taille des blocs physiques est bien de 4096 et non 512 (sinon faut changer la commande).

via la commande fdisk -l

 

- que si l'équipement dispose de bcp de RAM, le param. -c devrait faire gagner/économiser du temps

-c 98304 si on dispose d'1Go de RAM

 

ici moi j'ai mis 145000 :D

 

--

 

Sinon, pour le 918+ apparemment la version DSM n'est pas compatible avec disk utils …

Je ne vois rien alors que sur le 710 ca fonctionne bien :D (mais pb de droits évoqués ci dessus sic).

Share this post


Link to post
Share on other sites

Peux-tu me donner un exemple de commande qui ne se lance pas ?

 

Attention, il faut quasiment toutes les lancer avec sudo. Car le compte admin ne fait plus partie du groupe 0 depuis DSM 6.0. (ou 6.1, je ne sais plus).

 

Donc si le 710 est en 5.x/6.0; certaines commandes vont fonctionner et plus sur le DS918+ qui est d'office en 6.1

 

Mais j'ai toujours pu lancer tout ce que je voulais après cette interdiction puisque j'ai du modifier les commandes et ajouter les sudo entre l'installation il y a 4,5 des disques de 3 TB sur le Syno et le remplacement de deux de celui-ci par des disques de 5 TB il y 1 an (07/12/2016). Ces deux disques (en fait un de 5 et un de 6TB) ont été testé sur le DS412+.

Share this post


Link to post
Share on other sites

sur le DS710+ (DSM 5 latest) :  "sudo ./screen …" ne se lance pas, pb de droit.

 

je vais vérifier si c'est pas le chemin …

 

--

 

DS918+ y'a pas badblocks et peux meme pas lister les disques.

 

La commande arrive à créer un chemin (répertoire) avec un fichier de sortie …

 

--

 

Tout est fait avec sudo et le compte admin par défaut …

 

avec l'admin créé de mémoire je me logue même pas …

 

--

 

j'ai essayé par le script via planificateur de tâches

et via telnet

Share this post


Link to post
Share on other sites

DSM5. Alors, il faut probablement se logger comme root et lancer la commande sans le sudo.
Regarde ce qu j'ai écrit dans mon log d'install du DS412+ :

- ./screen /bin/sh -c '/usr/local/diskutils/sbin/badblocks -wv -b 4096 -c 4096 /dev/XXX > /tmp/diskutils/badblocks_XXX.log 2>&1'
- erreur : /usr/local/diskutils/sbin/badblocks: Permission denied while trying to determine device size
- solution : logon as root ipo admin

 

Donc la solution, c'est de faire un telnet -l root et pas un telnet -l admin

Et de ne pas utiliser le sudo, mais directement la commande ./screen

Share this post


Link to post
Share on other sites

DSM5. Alors, il faut probablement se logger comme root et lancer la commande sans le sudo.

Regarde ce qu j'ai écrit dans mon log d'install du DS412+ :

 

- ./screen /bin/sh -c '/usr/local/diskutils/sbin/badblocks -wv -b 4096 -c 4096 /dev/XXX > /tmp/diskutils/badblocks_XXX.log 2>&1'

- erreur : /usr/local/diskutils/sbin/badblocks: Permission denied while trying to determine device size

- solution : logon as root ipo admin

 

Donc la solution, c'est de faire un telnet -l root et pas un telnet -l admin

Et de ne pas utiliser le sudo, mais directement la commande ./screen

oui c'est bien ce que j'ai compris …

 

j'attends la fin des verif. smart étendues et j'essaie merci !

Share this post


Link to post
Share on other sites

Encore un élément.

 

Tu remarqueras qu'une fois, j'avais redirigé les output dans le répertoire  /tmp/diskutils/ et une autre fois dans /root.

 

Tu peux un peu choisir l'endroit que tu veux, vérifie qu'il existe avant. Ce n'est finalement qu'un home drive. 

 

/root, c'est le home drive de root, /tmp bah tu as l'assurance que rien de très important ne va s'y passer. Donc j'ai probablement crée un répertoire diskutils à l'époque.

Share this post


Link to post
Share on other sites

Bon, voilà, j'ai lancé sur les 2 disques. Alors quelques précisions :

 

1) J'avais un message d'erreur sur ./screen

 

La raison est simple. En Unix, le path est beaucoup plus contraignant. Donc soit, je mettais le path absolu de la commande. Soit, je faisais un cd dans le directory où se trouve la commande screen. Mais même dans le répertoire, lancer la commande screen ne suffit pas. Car par sécurité, il ne la trouve pas. Donc il faut préciser où elle est par rapport au répertoire courant. Donc il faut spécifier ./screen et ce même si on est dans le bon répertoire.

 

Pour trouver ce répertoire :

 

find / -name screen -print

 
Après beaucoup de permission denied, on voit apparaitre la ligne :
 
/volume1/@appstore/diskutils/bin/screen
 
Donc, il suffit de faire un cd /volume1/@appstore/diskutils/bin
 
Et ensuite de lancer la commande ... mais sur le DSM 5, c'est peut être dans un autre répertoire, attention.
 
Enfin le & terminal n'est pas nécessaire à cause de screen car l'écran devient blanc et il faut ouvrir un second shell et tout refaire pour lancer sur le second disque. Donc une commande type est par exemple :
 
sudo ./screen /bin/sh -c '/usr/local/diskutils/sbin/badblocks -wv -b 4096 -c 4096 /dev/sdc > /root/badblocks_sdc.log 2>&1' 
 
Enfin, dans un 3ème terminal, on peut suivre l'évolution du processus comme suit :
 
243417Capturedcran20171105165741.png
 
Il faut bien voir qu'il teste effectivement puisqu'il y a la ligne :
 
Testing with pattern 0xaa: 
 
Ce qui signifie qu'il met des 10101010 partout.

Share this post


Link to post
Share on other sites

badblocks existe bien sur le DS918+ (sans installation préalable).

 

sudo fdisk -l s'exécute et donne bien les disques recherchés :

Disk /dev/sda: 7.3 TiB, 8001563222016 bytes, 15628053168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 

Device       Start         End     Sectors  Size Type
/dev/sda1     2048     4982527     4980480  2.4G Linux RAID
/dev/sda2  4982528     9176831     4194304    2G Linux RAID
/dev/sda3  9437184 15627848351 15618411168  7.3T Linux RAID


Disk /dev/sdb: 7.3 TiB, 8001563222016 bytes, 15628053168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 

Device       Start         End     Sectors  Size Type
/dev/sdb1     2048     4982527     4980480  2.4G Linux RAID
/dev/sdb2  4982528     9176831     4194304    2G Linux RAID
/dev/sdb3  9437184 15627848351 15618411168  7.3T Linux RAID

nota : à savoir/noter que sur le DS918+, la taille secteur physique est de 4096, et 512 pour le 710+

c'est un critère important pour la commande badblocks !

 

puis la commande suivante est lancée :

sudo badblocks -wv -b 4096 -c 145000 /dev/sda > /tmp/20171105-badblocks_sda.log 2>&1 &&

Dans le fichier log, on peut lire ceci :

/dev/sda is apparently in use by the system; it's not safe to run badblocks!

J'ai supprimé le volume (RAID 1, non utilisé), redémarré le NAS > rien de mieux.

 

Rien d'observable / de monter via mount …

Share this post


Link to post
Share on other sites

Tu ne pourras pas tester /dev/sda puisque ce serait formater le drive sur lequel le NAS tourne.

 

Mais essaye avec /dev/sdb, ça devrait fonctionner sauf que ... si tu n'utilises pas la commande screen, je crois que le shell va se déconnecter après un moment et interrompre le processus.

Share this post


Link to post
Share on other sites

Tu ne pourras pas tester /dev/sda puisque ce serait formater le drive sur lequel le NAS tourne.

 

Mais essaye avec /dev/sdb, ça devrait fonctionner sauf que ... si tu n'utilises pas la commande screen, je crois que le shell va se déconnecter après un moment et interrompre le processus.

 

non le NAS tourne avec le sdd, ca me gave cette histoire …

 

merci encore Sethenès pour ton temps !

 

… vais me coucher !

Share this post


Link to post
Share on other sites

j'ai effacé les partitions.

 

De quel "disk group" parles tu ? Cela a été effacé préalablement dans DSM.

 

Je ne vois pas cette info. via fdisk -l (notion appartenance groupe).

 

En root ca change rien …

Share this post


Link to post
Share on other sites

Dans mon cas, j'ai 2 disques déjà installés et 2 disques que je teste. On voit bien que disk 3 & disk 4 ont le status non initialized.

 

271152Capturedcran20171106001028.png

 

C'est ça que tu dois obtenir.

 

Ce que je suggère, c'est que tu vérifies si dans le disk group, ces disques ne sont pas utilisés.

 

Chez moi, avec 2 disques utilisés, sans raid, j'ai donc 2 disk group :

 

290039Capturedcran20171106001108.png

Qui ne contiennent chacun qu'un seul disque, comme on peut le voir ici :

726703Capturedcran20171106001119.png

Share this post


Link to post
Share on other sites

non rien la dedans, je n'ai d'ailleurs jamais créé de disk group …

 

merci ;)

Share this post


Link to post
Share on other sites

Normalement, il en faut au moins 1 pour que le Syno s'installe.

 

Les volumes ne se créent pas directement sur les disques mais dans un disk group.

 

Comme on peut le voir ici :

 

770930Capturedcran20171106002046.png

 

Si tu as autre chose, dis-moi ce qu'il y a à la place de disk group stp (je parle pour ton volume 1)

Share this post


Link to post
Share on other sites

Normalement, il en faut au moins 1 pour que le Syno s'installe.

 

Les volumes ne se créent pas directement sur les disques mais dans un disk group.

 

Comme on peut le voir ici :

 

770930Capturedcran20171106002046.png

 

Si tu as autre chose, dis-moi ce qu'il y a à la place de disk group stp (je parle pour ton volume 1)

de mémoire je n'ai jamais créé de groupe de disque … et il n'est pas nécessaire pour créer un volume RAID par exemple.

un volume peut donc se créer sans groupe de disque …

 

je ne connais même pas l'utilité de cette fonction …

 

Donc la réponse est que aucun disque ne fait partie d'un groupe …

 

il n'y a qu'un volume 1 présent avec un disque sdd de 1 To qui a servi pour l'installation DSM.

 

Les autres 8 To ont été branchés pour être vérifiés.

 

 

EDIT : j'ai trouvé …

 

un groupe de disques permet de créer 1 à plusieurs partitions (ou volumes).

 

Si pas de groupe, on ne peut créer qu'un seul volume avec plusieurs disques …

 

Cela apporte un peu plus de souplesse …

 

De mon côté, je n'ai jamais eu l'utilité,

le fait de créer des dossiers avec différents droits est largement suffisant.

 

Je ne sais pas ce que peut apporter la création de plusieurs volumes distincts ?

je veux bien savoir dans quel cadre on peut en avoir besoin.

 

Parce que si c'est une erreur de ma part, je vais rectifier.

 

---

 

Bref, je résume … les deux disques à vérifier ne sont ni associés à un volume, ni attaché à un groupe de disques.

 

et pourtant j'ai le message évoqué sur dessus.

 

Je vais passer cette fois ci sur le DS710+ pour vérifier si en root j'ai plus d'info.

 

De toute façon je viens de récupérer une tour …

> centOS > badblocks avec 16 Go de ram … et les deux disques branchés en interne,

ça va turbiner si j'y arrive :D

Share this post


Link to post
Share on other sites

Voici ce que donne la commande fdisk pour une disque qui n'est pas attaché sous Syno :

 

408538Capturedcran20171106150340.png

 

Comme tu peux le voir (en comparant avec l'image que tu as postée sur cette page tout en haut), la différence, c'est qu'il n'y a pas les 3 partitions /dev/sdc1, /dev/sdc2 et /dev/sdc3. Car mon disque n'est pas partitionné.

 

Or les partitions /dev/sdc1 & /dev/sdc2 (et toutes les partitions 1 & 2 du Syno quel que soit le disque) sont les partitions système que crée le Syno. Il s'agit en fait d'un raid "mirroring", chaque disque abritant dans sa totalité une réplication du système. Les NetApp font pareil, ils créent un "vol0" avec le système qui est répliqué sur les 14 disques.

 

Si tu as le message d'erreur que tu as communiqué, c'est parce que ces partitions n'ont pas été sorties de la sphère de contrôle du Syno et qu'évidemment le système t'empêche de formater la partition où une copie de lui-même est stockée.

 

Donc il faut parvenir à arrêter cette réplication. Ce que j'ai vu, c'est que lorsque j'ai sorti (=supprimé le disque du disk group) mon HD de 5TB et celui de 6TB pour faire la place aux deux que je teste en ce moment, ils sont redevenus des disques que je pouvais soit utiliser pour un nouveau disk group (simple ou Raid, puisque j'avais deux disques), ou un spare. 

 

Evidemment, les partitions étaient encore présentes mais plus utilisées.

 

Je n'ai jamais été confronté à ta situation particulière. J'essaie de donner des pistes qui me semblent logiques.

Share this post


Link to post
Share on other sites

Si tu veux bien, ce soir, poste des captures d'écrans avec le contenu des tes volumes, disk group et HDD/SDD. Je parle non pas des résultats de la commande fdisk, mais bien des mêmes écrans que ceux que j'ai posté à 00:16. 

 

Sur base de ça, je pourrai y voir plus clair.

Share this post


Link to post
Share on other sites

@Sethenès : non ces partitions n'existent plus …

 

les partitions ont été effacées via la commande mount.

Disk /dev/sdd: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 

Device     Boot   Start        End    Sectors   Size Id Type
/dev/sdd1          2048    4982527    4980480   2.4G fd Linux raid autodetect
/dev/sdd2       4982528    9176831    4194304     2G fd Linux raid autodetect
/dev/sdd3       9437184 1953511007 1944073824   927G  f W95 Ext'd (LBA)
/dev/sdd5       9453280 1953318239 1943864960 926.9G fd Linux raid autodetect


Disk /dev/sda: 7.3 TiB, 8001563222016 bytes, 15628053168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 


Disk /dev/sdb: 7.3 TiB, 8001563222016 bytes, 15628053168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 

effectivement, si le message est présent, c'est bien que le Synology a un lock sur ces disques.

 

Mais les différentes vérifications opérées ne me permettent pas d'identifier l'origine.

 

fdisk

mount

dsm

 

rien dedans qui me dit que le disque est utilisé.

Share this post


Link to post
Share on other sites

Oki, alors je ne vois pas pourquoi tu as ce message d'erreur.

 

As-tu réessayé récemment ?

Voici une capture depuis une machine avec un CentOS Live Gnome …

DN90wynWkAMO67B.jpg

 

Maintenant la question que je me pose … est ce bien en train de tourner …

 

le fichier texte ne bouge pas … pas de log / avancée / évolution.

 

Est ce normal ?

 

EDIT : et oui je n'ai que 2 Go … la machine qui dispose de 16 Go ne démarre pas … sic transit gloria mundis !

Share this post


Link to post
Share on other sites

Oui, c'est parti la ;)

 

Et c'est logique, le fichier ne sera modifié qu'après l'écriture des 10101010 partout et le début de la phase de lecture (contrôle). Sur un 6TB, il faut compter 12h. Donc compte 16 h pour ton 8 TB.

 

Ensuite il faut autant pour lire.

Et puis autant pour écrire des 0101010

Et puis lire

Et puis écrire des 1111111

Et puis lire

Et puis, enfin écrire des 0000000

Et les vérifier.

 

Donc, compte à peu près 1 jour par TB.

 

Mais tu peux lancer la commande sur l'autre disque en parallèle ;)

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×