Discussion :

[joffrey575]

Bonjour à tous,

Je possède actuellement deux raspberry pi 3.

Les services fonctionnait bien pour le moment avec un disque.

J'ai eu quelques problèmes pour le montage des deux disques dur au démarrage.

Avez-vous déjà mis en place deux disque dur sur une raspberry pi 3 ? (1 disque en fonctionnement et un clone avec rsync sans raid)

Ma séquence de boot est la suivante :

-carte microSD : cmdline.txt -> root=/dev/sda1 -> le montage se fait bien

-disque dur origin : /etc/fstab ->

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
	proc             /proc           proc    defaults          0       0
	/dev/mmcblk0p1   /boot           vfat    defaults          0       0
	#/dev/mmcblk0p2  /               ext4    defaults,noatime  0       0

	/dev/disk/by-uuid/xxxxxxx-xxxxx-xxxxx-xxxxx / default 0 2
	/dev/disk/by-uuid/xxxxxxx-xxxxx-xxxxx-xxxxx /mnt/my_data default 0 2

	/dev/disk/by-uuid/xxxxxxx-xxxxx-xxxxx-xxxxx /mnt/rootfs_clone default 0 2
	/dev/disk/by-uuid/xxxxxxx-xxxxx-xxxxx-xxxxx /mnt/my_data_clone default 0 2

Est-ce que l'interface USB de la Pi est capable de gérer deux disques dur ?

Mes disques dur sont alimentés en externe.

Merci d'avance et bon début d'année

[NE555]

Les services fonctionnait bien pour le moment avec un disque.
J'ai eu quelques problèmes pour le montage des deux disques dur au démarrage.

Avez-vous déjà mis en place deux disque dur sur une raspberry pi 3 ? (1 disque en fonctionnement et un clone avec rsync sans raid)

Ma séquence de boot est la suivante :
-carte microSD : cmdline.txt -> root=/dev/sda1 -> le montage se fait bien
-disque dur origin : /etc/fstab [...]

Est-ce que l'interface USB de la Pi est capable de gérer deux disques dur ?
Mes disques dur sont alimentés en externe.

Bonjour,

Un RaspberryPi n'est pas limité en nombre de montages de disques dur. Il n'y a que 4 ports USB, mais un HUB USB est utilisable si les disques sont alimentés. Mais les disques USB peuvent ne pas être visibles au moment où le RaspberryPI accède au fichier "/etc/fstab".

Par exemples, des disques à faible consommation s'arrêtent spontanément s'ils ne sont pas utilisés pendant une certaine durée. L'accès au disque est de nouveau possible, mais un petit délai pourra exister avant d'accéder aux fichiers après le premier accès ayant "réveillé" le disque.

Il est normal que la SD-Card soit toujours visible, car sans elle il est impossible de booter. L'OS attendra donc suffisamment de temps pour accéder à la SD-Card dans des conditions normales. Mais il faudrait être certain qu'à ce moment le disque USB soit disponible.

Un bon test serait de remplacer les deux disques USB par deux clefs USB. Les clefs USB ne peuvent présenter les latences matérielles d'un disque dur. Si les clefs USB sont bien reconnues au démarrage, cela mettra en évidence la détection des disques durs au démarrage.

Enfin, il faut vérifier que le montage fait par vous peut être réalisé au boot : le chemin d'accès existe-t-il à ce moment par exemple ?

[joffrey575]

Merci pour ta réponse.

*C'est peut être un problème du fichier config.txt : max_usb_current = 1 -> configuration particulière des résistances de tirage sur le bus USB

*Autrement, peut être un souci de démarrage des disques dur et donc je voulais mettre des tampo pour laisser le temps aux disques de démarrer :

cmdline.txt -> ajouter
rootwait rootdelay = X s
boot_delay = X ms

Dans /etc/fstab, existe t-il une commande pour "temporiser" le montage des disques dur ?

Aussi, essayer avec une clé USB si le montage ne se fait pas correctement.

*Egalement concernant les permissions, le dossier qui accueil un disque dur externe doit avoir quoi comme permission ? C'est le root qui monte les disques dur donc si pi est dans le groupe sudoers alors le dossier peut être pi:pi

[joffrey575]

Avec le deuxième disque dur j'obtiens cette erreur :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
    Jan 08 19:29:12 raspberrypi kernel: Buffer I/O error on dev sdb2, logical block 486281216, async page read
    Jan 08 19:29:12 raspberrypi kernel: blk_update_request: critical medium error, dev sdb, sector 3907028992
    Jan 08 19:29:12 raspberrypi kernel: blk_update_request: critical medium error, dev sdb, sector 3907028992
    Jan 08 19:29:12 raspberrypi kernel: Buffer I/O error on dev sdb1, logical block 2097136, async page read
    Jan 08 19:29:12 raspberrypi kernel: blk_update_request: critical medium error, dev sdb, sector 16779136
    Jan 08 19:29:12 raspberrypi kernel: blk_update_request: critical medium error, dev sdb, sector 16779136
    Jan 08 19:28:47 raspberrypi kernel: JBD2: Error -5 detected when updating journal superblock for sdb1-8.
    Jan 08 19:28:47 raspberrypi kernel: Buffer I/O error on dev sdb1, logical block 1081344, lost sync page write
    Jan 08 19:28:47 raspberrypi kernel: blk_update_request: I/O error, dev sdb, sector 8652800
    Jan 08 19:28:47 raspberrypi kernel: blk_update_request: I/O error, dev sdb, sector 8652800
    Jan 08 19:28:46 raspberrypi kernel: Aborting journal on device sdb1-8.
    Jan 08 19:28:46 raspberrypi kernel: JBD2: Error -5 detected when updating journal superblock for sdb1-8.
    Jan 08 19:28:46 raspberrypi kernel: Buffer I/O error on dev sdb1, logical block 1081344, lost sync page write
    Jan 08 19:28:46 raspberrypi kernel: blk_update_request: I/O error, dev sdb, sector 8652800
    Jan 08 19:28:44 raspberrypi kernel: blk_update_request: I/O error, dev sdb, sector 55432
    Jan 08 19:28:44 raspberrypi kernel: blk_update_request: I/O error, dev sdb, sector 55192
    Jan 08 19:28:43 raspberrypi kernel: blk_update_request: I/O error, dev sdb, sector 54952
    Jan 08 19:28:43 raspberrypi kernel: blk_update_request: I/O error, dev sdb, sector 54712
    Jan 08 19:28:43 raspberrypi kernel: blk_update_request: I/O error, dev sdb, sector 54472
    Jan 08 19:28:43 raspberrypi kernel: blk_update_request: I/O error, dev sdb, sector 54232
    Jan 08 19:28:40 raspberrypi kernel: JBD2: Error -5 detected when updating journal superblock for sdb2-8.
    Jan 08 19:28:40 raspberrypi kernel: Buffer I/O error on dev sdb2, logical block 242778112, lost sync page write
    Jan 08 19:28:40 raspberrypi kernel: Aborting journal on device sdb2-8.
    Jan 08 19:28:40 raspberrypi kernel: JBD2: Error -5 detected when updating journal superblock for sdb2-8.
    Jan 08 19:28:40 raspberrypi kernel: Buffer I/O error on dev sdb2, logical block 242778112, lost sync page write
    Jan 08 19:28:40 raspberrypi kernel: blk_update_request: I/O error, dev sdb, sector 16793312
    Jan 08 19:28:39 raspberrypi kernel: blk_update_request: I/O error, dev sdb, sector 16793072
    Jan 08 19:28:39 raspberrypi kernel: blk_update_request: I/O error, dev sdb, sector 16792832
    Jan 08 19:28:39 raspberrypi kernel: blk_update_request: I/O error, dev sdb, sector 16792592
    Jan 08 19:28:39 raspberrypi kernel: blk_update_request: I/O error, dev sdb, sector 16792352
    Jan 08 19:28:39 raspberrypi kernel: blk_update_request: I/O error, dev sdb, sector 16792112
    Jan 08 19:28:38 raspberrypi kernel: blk_update_request: I/O error, dev sdb, sector 16791872
    Jan 08 19:28:38 raspberrypi kernel: blk_update_request: I/O error, dev sdb, sector 16791632
    Jan 08 19:28:38 raspberrypi kernel: blk_update_request: I/O error, dev sdb, sector 16791504
    Jan 08 19:28:38 raspberrypi kernel: blk_update_request: I/O error, dev sdb, sector 16791264

[joffrey575]

Mes deux disques dur sont branchés sur chacun un port USB de ma raspberry pi de 2To chacun.

J'ai effectué un rsync entre mes deux disques dur.

Je me retrouve avec cette erreur :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

rsync: mkstemp "/mnt/my_data_clone/Archives_D/" failed:Read-only file system (30)

puis après me voici avec un disque dur démonté et avec ces erreurs lors d'un fsck :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
j@jpcportable:~$ sudo fsck /dev/sdb
fsck de util-linux 2.29.2
e2fsck 1.43.4 (31-Jan-2017)
ext2fs_open2: Numéro magique invalide dans le super-bloc fsck.ext2*: Superbloc invalide, tentons d'utiliser les blocs de sauvetage... fsck.ext2: Numéro magique invalide dans le super-bloc lors de la tentative d'ouverture de /dev/sdb

Le superbloc n'a pu être lu ou ne contient pas un système de fichiers ext2/ext3/ext4 correct. 
Si le périphérique est valide et qu'il contient réellement un système de fichiers ext2/ext3/ext4 (et non pas de type swap, ufs ou autre), alors le superbloc est corrompu, et vous pourriez tenter d'exécuter e2fsck avec un autre superbloc*:
    e2fsck -b 8193 <périphérique>
 ou
    e2fsck -b 32768 <périphérique>

Trouvé une table de partitions gpt dans /dev/sdb

=> Conclusion :
1-trouver un autre schéma de boot
2-mettre les deux disques dans mon PC fixe et réveiller le PC fixe à chaque sauvegarde.
3-soit mettre le hub USB en plus mais les disques durs sont alimentés -> Possibilité d'obtenir les même erreurs
4-booter sur la carte SD et monter les 2 HDD dans le /mnt sachant que la carte microSD sera utilisé ! Possibilité d'obtenir les même erreurs

=> 2ème conclusion : avec des HDD et non des SSD, c'est encore plus mal barré pour faire des sauvegardes je pense à cause des latances !

=> comment reformater lentement mes deux disques dur qui ont subi le coup du rsync ?

[joffrey575]

Voici les erreurs après les deux premiers rsync :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
sharing@raspberrypi:/home/pi$ rsync -pavz --partial --progress --delete /mnt/my_data/Archives_D/ /mnt/my_data_clone/Archives_D/ > /tmp/log_rsync.txt
rsync: send_files failed to open "/mnt/my_data/Archives_D/.~lock.journal_2.txt#": Permission denied (13)
rsync: write failed on "/mnt/my_data_clone/Archives_D/Autres/Cd rom au fil de l'histoire/F1500.Dxr": Read-only file system (30)
rsync: failed to set times on "/mnt/my_data_clone/Archives_D/Autres/Cd rom au fil de l'histoire/.F1500.Dxr.V9sfuz": Read-only file system (30)
rsync: rename "/mnt/my_data_clone/Archives_D/Autres/Cd rom au fil de l'histoire/.F1500.Dxr.V9sfuz" -> "Autres/Cd rom au fil de l'histoire/F1500.Dxr": Read-only file system (30)
rsync error: error in file IO (code 11) at receiver.c(393) [receiver=3.1.2]

sharing@raspberrypi:/mnt$ rsync -pavz --partial --progress --delete /mnt/my_data/Archives_D/Electronique /mnt/my_data_clone/Archives_D/Electronique > /tmp/log_rsync_electronique.txt
rsync: recv_generator: mkdir "/mnt/my_data_clone/Archives_D/Electronique/Electronique" failed: Read-only file system (30)
*** Skipping any contents from this failed directory ***
rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1196) [sender=3.1.2]

[Philippe Dpt35]

Bonjour,

J'ai un RPi 1B qui me sert de serveur réseau sur lequel j'ai monté deux disques durs USB 2.5 1To sur un hub USB disposant de sa propre alimentation.
Je n'ai pas de problèmes.
Ils sont partitionnés en NTFS pour des raisons de compatibilité avec certains appareils que j'utilise sur le réseau, mais étaient initialement partitionnés en ext4 sans plus de problème.
Voici les lignes correspondantes de mon fichier /etc/fstab

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
UUID=xxxxxxxxxxxxxxxx /media/Partage 	ntfs defaults 0 2
UUID=xxxxxxxxxxxxxxxx /media/Medias ntfs-3g defaults 0 2

Je vois que dans ton fstab le type de système de fichiers n'apparaît pas dans la ligne de montage. Cela peut-il être la cause du problème ?

Il faut que le chemin de montage existe pour que celui-ci puisse se faire, donc que tu aies préalablement créé les dossiers /mnt/my_data_clone et /mnt/rootfs_clone. Je le précise à tout hasard car je suppose que cela tu le sais.

[joffrey575]

Je vais voir ça oui pour l'ext4, je viens de rechecker, l'ext4 est bien présent.

Sur ta raspberry pi 1, tu boot sur ta carte microSD ? Depuis combien de temps tu fonctionnes avec cette solution ?

Si on fonctionne sur carte microSD il faudrait donc avoir le moins d'écriture/lecture dessus non ?

----------------------------

As-tu déjà essayé un "cp" ou "rsync" de gros volumes entre tes deux disques dur ?

[Philippe Dpt35]

Sur ta raspberry pi 1, tu boot sur ta carte microSD ? Depuis combien de temps tu fonctionnes avec cette solution ?
Si on fonctionne sur carte microSD il faudrait donc avoir le moins d'écriture/lecture dessus non ?

Le système est sur la carte SD, depuis des années. Et je n'ai pas eu à la changer encore. Ce RPi est très rarement éteint et rallumé.
Il est possible de limiter les opérations d'écriture/lecture pour protéger la carte SD, notamment en limitant les écritures de log ou de cache. Mais je ne l'ai pas fait pour ce RPi.
Je ne l'utilise que pour accéder au contenu des disques durs.

As-tu déjà essayé un "cp" ou "rsync" de gros volumes entre tes deux disques dur ?

Non.
En revanche je fais sans problème des synchronisations quotidiennes de fichiers du contenu d'un des disques durs depuis le réseau vers un disque USB relié à un PC sous Windows.

[joffrey575]

La 1ère solution est effectivement de booter sur la carte SD et de monter les deux HDD.

=> de cette configuration on peut tenter de faire un cp entre les deux disques ou un rsync.
=> cp ou rsync par USB entre les deux HDD

La 2ème solution est de garder la config boot HDD par usb et fonctionner sur le HDD comme ça pas de souci de carte microSD.

=> de cette configuration, faire un rsync du HDD USB vers un autre HDD d'un autre PC.
=> cp ou rsync via le réseau entre la pi et un PC

----------------------------------------------

Laquelle des solutions est la plus approprié ?

Solution 1 : cp/rsync USB sur pi
-Avantage : rapidité du bus USB
-Inconvénient : gestion de durée de via microSD

Solution 2 : cp/rsync réseau entre pi et un PC
-Avantage : durée de vie HDD
-Inconvénient : latence réseau pour les sauvegardes

Qu'en penses-tu ?

[Philippe Dpt35]

De mon expérience, le système sur carte SD n'a pas été pénalisant sur la durée de vie de celle-ci jusqu'à présent.

J'ai eu un problème de carte SD sur un autre RPi, un RPi2 utilisé comme lecteur multimédia avec Kodi, les fichiers multimédias étant stockés sur le réseau. Ce RPi a pourtant été peu utilisé, mais à chaque fois éteint et rallumé. Mauvaise carte SD ? Beaucoup d'écritures de la part de Kodi ? Usure prématurée par les extinctions-allumages à chaque utilisation ?
Je n'ai pas la réponse.

Comme la carte SD de mon RPi serveur n'a pas eu des problèmes depuis des années d'utilisation, je serais tenté de dire que le système sur carte SD n'est pas très pénalisant si tu ne l'utilises que pour la gestion de tes disques durs et l'accès à leurs fichiers, sauf si l'usage de cp et rsync provoquaient des écritures intermédiaires sur la carte SD (à vérifier donc).

[joffrey575]

Je reviens vers vous pour vous spécifier que mon problème est résolu.

Avec un Hub USB alimenté en externe le boot sur HDD1 et rsync sur HDD2 de clonage fonctionne, lentement mais fonctionne sans erreur dans journalctl.

Était-ce un problème d'alimentation (ce serait étrange car mes HDD ont une alimentation externe) ?

Était-ce un problème d'interface USB de la raspberry-pi ? En tout les cas je me demande quel chemin prend le flux géré par rsync, seulement le Hub USB ou un chemin classique HDD -> pi -> HDD ?

[joffrey575]

Voici le montage d'avant et d'après.

Avant ça ne fonctionnait pas malgré l'alimentation des disques dur. Alors peut être que l'alimentation des disques dur n'alimentait pas le bus USB allant vers la Pi. Ca c'est possible.

https://www.net-c.com/netc/mail/atta...jb20%2B&file=0

[Philippe Dpt35]

Tout ça fait beaucoup d'alims !

En ce qui me concerne, je n'ai qu'une alimentation, celle du hub USB. Celle-ci fournit, en même temps que le transfert USB, l'alimentation nécessaire au fonctionnement des deux disques durs. C'est le hub USB qui alimente également mon RPi en connectant l'un de ses ports USB au port micro USB d'alimentation du RPi .

Je ne suis pas allé jusqu'à tester 3 disques durs pour savoir si l'alimentation serait suffisante !