Matériel: Raspberry Pi à la maison avec VPN Version de YunoHost: 4.3.4.2 J’ai accès à mon serveur : En SSH | Par la webadmin | En direct avec un clavier/écran | … Êtes-vous dans un contexte particulier ou avez-vous effectué des modificiations particulières sur votre instance ? : non Si oui, expliquer:
changement de disque pour le serveur
Bonjour,
je désire changer le disque sur mon serveur, un raspberry avec la partition / montée sur un HDD externe alimenté et brancher via USB.
J’ai branché le nouveau nouveau disque (un SSD), préparé le disque fdisk -l /dev/sdX
formaté en ext4,
sudo mkfs.ext4 /dev/sdX1
monté sur /mnt/disk.
sudo mkdir /mnt/disk et mount /dev/sdX /mnt/disk
éditer les fstab UUID=xxxxxx-xxxxxx-xxxxxx-xxxxx /mnt/disk ext4 nodev,nosuid 0 1
et sudo mount -a
J’ai arrêter le service nginx sudo service nginx stop
et lancer une copie du disque HDD vers les SSD ensuite avec cette commande
sudo rsync -aXS /. /mnt/disk/.
C’est très long, je me demande si je n’aurai pas du arêtter d’autres services avant ? ou procéder autrement ?
Ou copier les disques bêtement avec un autre ordi sans lancer le serveur ??
bon, j’avoue, il y a quand même 40 Go à copier, normal que ce soit long, j’essaie une autre méthode en éteignant le serveur et faire une copie/clone du disque A vers B avec la commande dd
D’accord, bon je dois tout de même recommencer, hier j’ai lancé la commande dd et au bout de 13h ça n’avais pas encore fini… J’ai craquer et arrêtter…
Mais je crois avoir compris, il faudrait que je choisisse plutôt cette commande dd if=/dev/sdb2 of=/dev/sdc1 bs=4096 \conv=notrunc,noerror
par exemple, sinon la commande que j’ai tentée était juste toute seule est bien trop longue… dd if=/dev/sdb2 of=/dev/sdc1
J’ai aussi vu sue le net cette possibilité de commande dd si = /dev/sdb2 de =/dev/sdc1, mais là je ne suis certain de rien, je me suis fier à ce cheatcode https://linuxconfig.org/learning-linux-commands-dd
J’espère que ça n’écrase pas le MBR par contre du disque, en théorie non puisque je copie une partition et non le disque en entier…
PS: la partition /dev/sdb2 est la partition / du premier disque et /dev/sdc1 celle du nouveau disque…
Je me lance et cette fois je vais rester patient…
Je crois comprendre pour la suite (si j’arrive à éxecuter cette copie) que je dois ajouter l’étiquette rootfs au nouveau disque, peut-être reprendre tout l’espace de la partition, j’imagine avec un sudo resize2fs /dev/sdc1,
éditer le fichier /boot/cmdline.txt sur la carte SD du raspberry avec le bon UUID du nouveau disque, penser à éditer le fichier /etc/fstab sur la nouvelle copie pour aussi prendre en compte le bon UUID et avec beaucoup de chance je démarre sans soucis…
Bon, ça fait des heures que j’ai lancer la commande, mais j’ai l’impression que ça ne fonctionne pas… Sur le disque ancien, il y a des petits voyants, quand le disque travaille je doit voir quelque chose, là sa semble à l’arrêt… sur l’autre, le nouveau, je n’ai pas de voyants… J’ai de gros doutes ! Quand j’essaie avec la commande top de voir ce qui se passe, je ne vois rien qui ressemble à l’activité présumée…
alors, je ne sais pas bien ce qui s’est passé. J’ai essayé des Ctl C car j’y croyait plus, mais ça ne s’arrêtait pas (peut-être à cause du noerror…
Bref, à un moment ça s’est terminé avec ce message
Là j’ai regardé le disque avec Gparted, les données au début du disque semblent être là, mais au milieu de la partition (qui fait 1.8 To) c’était grisé (comme non alloué) et un panneau avec un avertissement, bref, pas terrible. J’essaie de redimmensionner en réduisant la partition avec Gparted à 278,89 Go pour qu’il corrige dans le but de l’agrandir après coup.
Du coup la commande de Gparted est `e2fsck -f -v -C 0 ‘/dev/sdc1’. Là il répare plein d’inodes à ce que je vois. Je crois les doigts pour que cela répare les inodes défectueux et que je puisse ensuite de nouveau agrandir la partition… tout en gardant les données au début…
Pas terrible pour un disque tout neuf… wait and see…
C’est quand même très lent, même pour de l’usb.
Sinon, au lieu de réparer, tant que tu as encore le disque source, tu pourrais retenter la copie avec un pc, en usb3 si possible. Ça prendrait quelques minutes pour 70G.
Oui, je crois comprendre ce qui ralentis, j’utilise pour ce disque un connecteur universel Advance qui normalement supporte le USB3 je pense ceci dit, mais je le suscpecte d’être léger ou mal alimenter (peut-être même l’alim de ce connecteur qui est défaillante)… En tout les cas, je n’ose pas interrompre la commande avec Gparted
…
Sinon, avec Gparted, tu copie la partition et ensuite tu la colle, s’est bien ça ?
Bon j’y ai presque cru mais des erreur d’inode à la fin il me semble… Je vais attendre demain je crois
Bon, après tout ces faux départs. Pour la dernière commande dd, j’ai du en effet interrompre avant la fin, la partition entière fait plutôt 994 G (un disque de 1 To avec une partition ram à la fin), J’essayai bien avec les 2 disques branchés en USB (pas 3, sur mon Thinkpad le USB3 ne fonctionne plus bien ).
J’ai ensuite essayé en branchant les 2 disques dans une tour d’ordi sur des ports SATA et avec Gparted. C’est aller assez vite, mais en essayant de redémarrer le raspberry pi, plusieurs services FAILED et à la fin, une histoire d’inodes que le raspberry n’est pas arrivé à corriger. Le Raspberry a essayé une ou 2 fois de checker la partition disque et concluait sur une erreur d’inode…
Ce matin tôt avant d’aller dormir un peu, j’ai nettoyé à nouveau et bien formaté la partition disque avec Gparted en lui donnant cette fois la même taille que celle que je dois copier. Avec le disque à copier HDD de 1 To brancher sur le port SATA d’une tour et le disque SSD de 2 To brancher en USB (pas USB3) j’ai lancé la commande qui va bien je cois tout de même dd if=/dev/sdb2 of=/dev/sdc1 bs=4096 conv=notrunc,noerror status=progress
Cette fois un détail d’importance le ‘status=progress’ qui permet de vois l’évolution des écritures, la commande est bien expliquée ici aussi dd / Wiki / Debian-facile
En gros il a déjà copié 766 Go en 3h30 à une vitesse de 40MB/s…
On va y arriver cette fois, j’y crois !
Je me pose des questions sur la santé du disque source. J’ai moi-même dû changer le disque de mon serveur parce que j’ai reçu des mails attestant que l’état smart du disque est dégradée avec des secteurs défectueux. J’avais copié les partitions du disque source vers le nouveau disque avec gparted puis j’ai dû réparer le démarrage avec un live cd Linux. Et c’était bon.
J’avoue, je galère,
le raspberry en démarrant arrive avec des erreurs [TIME] Timed out waiting for device /dev/disk/by-uuid/xxxxxxxxxxxxxxxxx. [DEPEND] Dependency failed for /dev/disk/by-uuid/xxxxxxxxxxxxxxxxx. [DEPEND] Dependency failed for Swap. [DEPEND Dependency failed for File System Check on /dev/disk/by-partuuid/738a4d667-01] [DEPEND Dependency failed for /boot [DEPEND] Deependency failed for Unattented Upgrades Shutdown. [DEPEND Dependency failed for File Systems. ............
Ensuite il se met en emergency mode et il fait un check du disque…
C’est bizarre je crois me rappeler avoir édité le fichier fstab avec l’UUID de la partition /et non le PARTUUID…
Je me suis relancer dans cette aventure… Cette fois en ayant une alimentation convenable aussi pour le disque externe SSD qui va accueillir le clonage de la partition root.
J’ai d’abord éteint plusieurs services (fpm, postgresql, mysql, nginx, dovecot, postfix).
Le disque n’est pas monté avec la partition où je clone en lancant un dd if=/dev/sdb2 of=/dev/sdc1 bs=4096 conv=notrunc,noerror status=progress
Ensuite, pour agrandir la partition, j’ai utilisé ce topic
umount /dev/sda1
fdisk /dev/sda
d # pour effacer la partition (delete)
1 # pour indiquer la partition sda1
n # pour recréer la partition
p # pour recréer une partition primaire
1 # parce que c'est la partition 1 que l'on veut créer
[Enter] # pour accepter le bloc proposé, à savoir le premier bloc disponible, le même que celui de la partition effacée.
[Enter] # pour accepter le bloc de fin, qui par défaut, est le dernier bloc disponible
w # pour enregistrer les changements dans la table de partitions
Puis deuxième étape
tune2fs -O ^has_journal /dev/sda1 # va supprimer le journal du système de fichier
fsck -f -y /dev/sda1 # afin d'assurer l'intégrité du système de fichier
resize2fs /dev/sda1 # qui sans option va par défaut agrandir le système
# de fichier à la taille de la partition
fsck -f -y /dev/sda1 # On revérifie l'intégrité des données
tune2fs -O has_journal /dev/sda1 # Et enfin on recrée le journal d'indexation
