Debian
Debian-France
Debian-Facile
Debian-fr.org
Forum-Debian.fr
Debian ?
Communautés
Vous n'êtes pas identifié(e).
Dernière modification par debi3368 (28-09-2022 00:06:37)
Hors ligne
-->les cahiers du debutant<-- WikiDF-->Découvrir les principales commandes Linux<--
L' expérience, c'est le nom que chacun donne à ses erreurs. Oscar Wilde
En ligne
d'un point de vue pratique :
si un disque dur A fait défaut :
si Debian est installé sur ce disque A, je devrais :
créer une partition sur un disque B;
si ce disque B n'a pas suffisamment d'espace libre, je devrais transférer ses données sur d'autres disques C, D, etc;
installer Debian sur la nouvelle partition créée de B;
si Debian est installé sur une clé USB, je n'aurai pas à faire ces 3 manipulations;
si Debian est installé sur une clé USB qui fait défaut :
je n'aurais pas à toucher aux disques durs;
je remplacerais simplement la clé USB par une autre clé USB (clone de la clé USB retirée);
d'un point de vue matériel :
une clé USB est nettement mois chère qu'un disque SAS;
une clé USB s’achète partout, un disque SAS est plus dur à trouver.
Par contre je ne sais pas si les "avantages" (?) décrits ici l'emportent sur le risque d'avoir à fréquemment remplacer la clé USB... D'où ma présence ici ^^
Je re-précise que les données de disques ne sont pas critiques et que dans ces conditions, en terme de données, perdre un disque avec ou sans système revient au même. En revanche en terme de temps et d'efforts, avec un disque système cela nécessitera plus de temps et de manipulations pour retrouver la configuration initiale (avec un disque en moins ou avec un nouveau disque). En tout cas c'est mon impression...
Dernière modification par debi3368 (27-09-2022 18:41:07)
Hors ligne
Hors ligne
Hors ligne
Pour préserver au maximum les disques SAS
Pardon ? Tu crois que Debian va fatiguer un disque SAS qui est censé être conçu pour une utilisation intensive ?
pour ne pas avoir à ré-installer Debian en cas de défaillance de l'un de ses disques
Le RAID sert précisément à ça, entre autres choses. Si tu ne veux pas mettre les disques entiers en RAID, tu peux utiliser le RAID logiciel de Linux sur une portion seulement.
par défaut Debian n'est pas optimisé pour être installé sur une clé USB
Aucune installation normale n'est optimisée pour fonctionner sur une clé USB. En fait ce sont les clés USB qui ne sont pas prévues pour cet usage mais pour le stockage simple avec peu d'écritures.
Les seuls systèmes optimisés pour les clés USB sont les systèmes live, où la clé USB est utilisée essentiellement en lecture seule.
j'ai activé les options discard
Pas sûr que beaucoup de clés USB supportent le TRIM/discard. C'est plutôt l'apanage des SSD.
Voyez-vous d'autre paramètres de Debian à modifier pour ne pas réduire la durée de vie en écriture de la clé USB ?
L'option "sync" risque au contraire d'accélérer l'usure de la clé. L'option "nodiratime" est déjà incluse dans "noatime". Cf. man mount.
un autre système de fichier que ext4 ?
Les systèmes de fichiers dits "structurés en log" comme f2fs seraient plus adaptés aux clés USB (écriture par gros blocs, nivellement de l'usure) que les systèmes de fichiers traditionnels comme ext4 conçus à l'origine pour les supports magnétiques rotatifs.
une clé USB est nettement mois chère qu'un disque SAS;
une clé USB s’achète partout, un disque SAS est plus dur à trouver.
On peut brancher un disque SATA sur un contrôleur SAS.
Dernière modification par raleur (27-09-2022 22:46:07)
Il vaut mieux montrer que raconter.
Hors ligne
debi3368 a écrit :Pour préserver au maximum les disques SAS
Pardon ? Tu crois que Debian va fatiguer un disque SAS qui est censé être conçu pour une utilisation intensive ?
Je reconnais mon ignorance sur le sujet. Je croyais que tout OS, quel qu'il soit, fatiguait obligatoirement son support. Peut-être Debian un peu moins. Mais indépendamment de l'OS, je comprends en effet la logique qui veut qu'un SAS serait plus résistant qu'un SATA et que je n'ai pas trop à m'inquiéter sur ce point.
debi3368 a écrit :pour ne pas avoir à ré-installer Debian en cas de défaillance de l'un de ses disques
Le RAID sert précisément à ça, entre autres choses. Si tu ne veux pas mettre les disques entiers en RAID, tu peux utiliser le RAID logiciel de Linux sur une portion seulement.
Ok. Toutefois, je n'ai pas encore pris le temps de regarder l'état des disques : il est possible que plusieurs soient proches de la fin. Il faut que je vérifie ça. Faire du RAID1 sur 2 partitions de 2 disques vieillissants (ou plus si RAID5) ne sera peut-être pas une bonne idée. Je vais y réfléchir.
debi3368 a écrit :par défaut Debian n'est pas optimisé pour être installé sur une clé USB
Aucune installation normale n'est optimisée pour fonctionner sur une clé USB. En fait ce sont les clés USB qui ne sont pas prévues pour cet usage mais pour le stockage simple avec peu d'écritures. Les seuls systèmes optimisés pour les clés USB sont les systèmes live, où la clé USB est utilisée essentiellement en lecture seule.
Voila qui est limpide. Je comprends tout à fait.
debi3368 a écrit :j'ai activé les options discard
Pas sûr que beaucoup de clés USB supportent le TRIM/discard. C'est plutôt l'apanage des SSD.
Oui je n'y croyais pas trop mais je l'ai cochée au cas où la clé le supporterait.
debi3368 a écrit :Voyez-vous d'autre paramètres de Debian à modifier pour ne pas réduire la durée de vie en écriture de la clé USB ?
L'option "sync" risque au contraire d'accélérer l'usure de la clé. L'option "nodiratime" est déjà incluse dans "noatime". Cf. man mount.
Pour sync, inattention de ma part. Merci. Pour nodiratime, j'avais bien lu mais j'avoue avoiri coché en me disant (bêtement) "je ne risque rien à la rajouter".
debi3368 a écrit :un autre système de fichier que ext4 ?
Les systèmes de fichiers dits "structurés en log" comme f2fs seraient plus adaptés aux clés USB (écriture par gros blocs, nivellement de l'usure) que les systèmes de fichiers traditionnels comme ext4 conçus à l'origine pour les supports magnétiques rotatifs.
Merci pour cet éclairage.
debi3368 a écrit :une clé USB est nettement mois chère qu'un disque SAS;
une clé USB s’achète partout, un disque SAS est plus dur à trouver.
On peut brancher un disque SATA sur un contrôleur SAS.
Effectivement, j'avais envisagé cette possibilité.
Bon, et bien il semble évident que mon choix n'était pas le bon. Merci Raleur, Croutons et VBrice.
Dernière modification par debi3368 (28-09-2022 00:09:50)
Hors ligne
Dernière modification par raleur (28-09-2022 10:45:42)
Il vaut mieux montrer que raconter.
Hors ligne
Disque A (disque de boot principal)
partition boot ext2 (créée via installateur - assisté : utiliser tout un disque avec LVM)
Groupe de volume contenant 3 volumes logiques
Debian
swap
données
Disque B (disque de boot secondaire)
partition boot ext2
Groupe de volume contenant 3 volumes logiques
Debian
swap
données
Disque C à H (disque de données)
partition boot ext2
Groupe de volume contenant un unique volume logique de données
L'idée serait de faire régulièrement un clone des 2 partitions boot et système du disque A vers les 2 partitions boot et système du disque B, afin qu'en cas de défaillance du disque A, je n'ai qu'à booter sur le disque B pour obtenir rapidement un système opérationnel.
Et pour le cas où c'est le disque B secondaire qui serait défaillant, j'utiliserai un disque tiers (C à H) comme disque secondaire :
en réduisant son unique volume logique puis en créant 2 autres volumes logiques système et swap;
en clonant les partitions boot et système du disque A dans la partition système du disque tiers.
Sauf erreur de ma part, c'est la configuration qui nécessiterait le moins de manipulations en cas de défaillance d'un disque.
A ce stade, je ne sais pas encore :
s'il me faudra désactiver dans le bios le boot sur le disque secondaire et les 6 disques de données;
s'il me faudra démonter en permanence les partitions boot et systèmes du disque secondaire et la partition boot des 6 disques de données;
comment cloner les partitions boot et système du disque principal;
mais j'ai bon espoir de trouver la réponse en lisant de la doc sur le sujet. Dans le cas contraire je viendrai probablement demander de l'aide sur ce forum 
Merci encore pour vos précédents commentaires.
Hors ligne
Disque A et B: Pourquoi ne pas le mettre en RAID 1 / miroir avec mdadm (raid logiciel) dès l'installation ? C'est fait pour et le "clonage en cas de défaillance" devient "natif"...
Non ? Tu dis "sans RAID " dans ton premier post: il y a une raison ?
Pourquoi des partitions ext2 ?
@+
Travaille du chapeau: "Je sais que vous croyez comprendre ce que vous pensez que j'ai dit, mais je ne suis pas certain que vous réalisiez que ce que vous avez entendu n'est pas exactement ce que je voulais dire..."
Hors ligne
je ne m'en suis jamais servi et donc en cas de défaillance d'un des deux disques montés en RAID1 j'imagine cela comme difficile de reconstruire le RAID avec un disque tiers non vide;
au boulot et dans mes lectures, j'ai déjà entendu et lu que la reconstruction du RAID sur des disques vieillissants étaient risqué dans le sens ou le disque restant est fortement sollicité pendant la reconstruction et qu'à cette occasion il pouvait lâché lui aussi justement à ce moment-là.
Voilà, ça reste peut-être juste une peur à affronter ^^ Mais mes disques SAS n'étant pas trop récents, je me disais qu'un clone du système de temps en temps serait plus sûr et moins fatiguant pour les 2 disques. Mais faute de ne pas y connaître grand-chose, c'est une supposition.
Ext2 ne concerne que la partition boot : lorsque j'ai installé Debian sur la clé USB en choisissant dans l'installateur Debian le partitionnement "Assisté - utiliser tout un disque avec LVM", cette partition a été créée automatiquement en ext2, en plus des partitions système et swap. Donc je me suis dis que c'était nécessaire qu'elle soit en ext2 à cause de l'utilisation de LVM. En revanche la partition système étaient bien en ext4, ce que je prévois également.
J'espère avoir répondu à tes 2 questions.
Dernière modification par debi3368 (04-10-2022 22:13:04)
Hors ligne
pour le RAID, j'ai deux a priori
Non fondés. La reconstruction est très simple et ne stresse pas plus le disque restant qu'un clonage.
Au passage, ta méthode de clonage ne marche pas.
le partitionnement "Assisté - utiliser tout un disque avec LVM", cette partition a été créée automatiquement en ext2
Ce qui n'a aucune justification sérieuse. En fait c'est carrément la création d'une partition séparée pour /boot qui n'a plus aucune justification sérieuse de nos jours.
je me suis dis que c'était nécessaire qu'elle soit en ext2 à cause de l'utilisation de LVM
N'importe quoi.
En revanche la partition système étaient bien en ext4,
Non, en LVM.
Dernière modification par raleur (04-10-2022 23:39:28)
Il vaut mieux montrer que raconter.
Hors ligne
debi3368 a écrit :pour le RAID, j'ai deux a priori
Non fondés. La reconstruction est très simple et ne stresse pas plus le disque restant qu'un clonage.
Entendu, je prends note.
Au passage, ta méthode de clonage ne marche pas.
Peux-tu être plus précis ou expliquer pourquoi ? Parce que le système cloné ferait référence à un disque qui n'est pas celui sur lequel il serait installé ?
debi3368 a écrit :le partitionnement "Assisté - utiliser tout un disque avec LVM", cette partition a été créée automatiquement en ext2
Ce qui n'a aucune justification sérieuse. En fait c'est carrément la création d'une partition séparée pour /boot qui n'a plus aucune justification sérieuse de nos jours.
Je veux bien te croire, mais voici ce qu'affichait l'installateur Debian lorsque j'ai fais un test d'installation sur une clé usb branchée sur un notebook (j'avais retiré le disque dur du notebook, seules étaient branchées la clé iso et la clé destinée à Debian :
Mais peut-être est-ce lié au fait que :
il s'agissait d'une clé usb et non d'un disque dur;
la clé n'était pas vide lors du lancement de l'installateur Debian.
Je verrais bien si j'obtiens la même proposition de partitionnement assisté avec un disque dur.
D'autre part :
https://wiki.debian.org/LVM : "If you plan to encrypt your root filesystem /boot may need to be located in a separate unencrypted Logical Volume or partition. Refer to the Cryptsetup documentation for more information. GRUB v1 and LILO are not compatible with LVM, if you use one of those legacy bootloaders /boot should be outside the storage disk managed by LVM."
Si je comprends bien le paragraphe ci-dessus, Grub2 est compatible avec LMV non crypté et ne nécessite pas de partition de boot, contrairement à Grub1 et LILO. C'était donc peut-être un bug du partitionnement assisté de l'installateur.
debi3368 a écrit :je me suis dis que c'était nécessaire qu'elle soit en ext2 à cause de l'utilisation de LVM
N'importe quoi.
Quand on ne comprends pas on suppose en attendant de trouver des réponses ^^
debi3368 a écrit :En revanche la partition système étaient bien en ext4,
Non, en LVM.
Ah. Donc si je comprends bien il faut écrire la partition est de type LVM et cette partition est décomposée en 2 volumes logiques : A de type ext4 et B de type swap. Je suis d'accord avec toi que les mots sont importants.
Au vu de tout cela, que me recommandes-tu (ou que ferais-tu en te mettant à la place d'un non-initié) comme configuration avec un minimum de manipulations à faire en cas de défaillance d'un disque ? Créer 3 partitions (système, swap, données) sur 2 disques et 1 partition LMV (données) sur les 6 autres disques. Construire une partition multi-disque en RADI1 avec les 2 partitions systèmes et construire une partition multi-disque en RADI1 avec les 2 partitions swap, et installer Debian sur ces 2 partitions multi-disques ? Je m'excuse d'avance si ce que j'écris te parait absurde.
Dernière modification par debi3368 (05-10-2022 02:39:44)
Hors ligne
Peux-tu être plus précis ou expliquer pourquoi ? Parce que le système cloné ferait référence à un disque qui n'est pas celui sur lequel il serait installé ?
En gros, oui. Le système fait référence à des volumes logiques LVM différents de ceux du clone dans /etc/fstab, /boot/grub/grub.cfg et d'autre fichiers moins importants.
Je veux bien te croire, mais voici ce qu'affichait l'installateur Debian lorsque j'ai fais un test d'installation
C'est ce que le partitionnement assisté avec LVM est programmé pour faire, probablement pour des raisons historiques obsolètes. Mais cela ne signifie pas que c'est encore utile.
Mais peut-être est-ce lié au fait que :
il s'agissait d'une clé usb et non d'un disque dur;
la clé n'était pas vide lors du lancement de l'installateur Debian.
Non, rien à voir. L'installateur se moque bien que ce soit une clé ou un disque et efface toutes les partitions existantes si on choisit d'utiliser le disque entier.
Je verrais bien si j'obtiens la même proposition de partitionnement assisté avec un disque dur.
C'est tout vu.
Si je comprends bien le paragraphe ci-dessus, Grub2 est compatible avec LVM non crypté et ne nécessite pas de partition de boot, contrairement à Grub1 et LILO.
Oui. En fait même /boot peut être chiffré dans certaines conditions, mais ce n'est pas supporté par l'installateur même en partitionnement manuel. Ça dépend de la version de GRUB, de la version de l'en-tête LUKS, du type de slot pour la clé de chiffrement... En ce moment c'est un peu compliqué car GRUB 2.04 ne supporte pas encore le nouveau format LUKS2 qui est utilisé par défaut par cryptsetup depuis Buster. Mais il vient d'être remplacé dans buster et bullseye par GRUB 2.06 qui supporte LUKS2 mais pas tous ses algorithmes de chiffrement de clé (si j'ai bien suivi)...
que me recommandes-tu (ou que ferais-tu en te mettant à la place d'un non-initié)
Je ne peux pas me mettre à la place d'un non initié, il m'est objectivement impossible de faire abstraction de ce que je sais.
Ce que je ferais :
- système (racine, swap...) dans un VG LVM en RAID 1 (simple et robuste) sur une partie d'au moins deux disques
- données dans un autre VG en RAID 5 ou 6 sur le reste de l'espace disque
- éventuellement un disque en hot spare.
Pas de LVM étendu sur plusieurs disques sans RAID car si un disque tombe en panne tout est perdu.
Il vaut mieux montrer que raconter.
Hors ligne
Ce que je ferais :
- système (racine, swap...) dans un VG LVM en RAID 1 (simple et robuste) sur une partie d'au moins deux disques
- données dans un autre VG en RAID 5 ou 6 sur le reste de l'espace disque
- éventuellement un disque en hot spare.
Pas de LVM étendu sur plusieurs disques sans RAID car si un disque tombe en panne tout est perdu.
Ok. Je n'avais pas compris qu'on pouvait faire du RAID dans un VG LVM (je pensais sans raison qu'ils étaient exclusifs).
Il faudra que je me plonge dans la documentation de partman-md ou mdadm pour comprendre quelle est la procédure à suivre pour être averti d'une défaillance de disque et reconstruire le RAID avec une partition située sur un autre disque, voir à automatiser cela si j'utilise un hot spare. C'est justement ce que je voulais éviter, étant novice en la matière, mais ce n'est peut-être pas si compliqué.
L'ironie c'est qu'en voulant initialement ne peut pas me compliquer la vie avec du RAID, j'ai exclu l'idée d'utiliser le contrôleur RAID matériel... Mais puisque finalement vous me conseillez d'utiliser du RAID, je devrais peut-être plutôt me servir du RAID matériel...
Hors ligne
Je n'avais pas compris qu'on pouvait faire du RAID dans un VG LVM
On peut, mais ce n'est pas ce que je propose et l'installateur ne le prend pas en charge. Je reste sur du classique : un ensemble RAID utilisé comme PV LVM, donc LVM dans du RAID et non l'inverse.
Il vaut mieux montrer que raconter.
Hors ligne
debi3368 a écrit :Je n'avais pas compris qu'on pouvait faire du RAID dans un VG LVM
On peut, mais ce n'est pas ce que je propose et l'installateur ne le prend pas en charge. Je reste sur du classique : un ensemble RAID utilisé comme PV LVM, donc LVM dans du RAID et non l'inverse.
Ok. Je n'ai pas l'installateur sous les yeux, donc je ne vois pas ce qu'il permet de faire ou ne pas faire. Merci pour la précision.
Vu que tu ne mentionnes pas le RAID matériel (DELL PERC H200), j'imagine que tu ne le recommandes pas (ou que tu n'as pas de retour d'expérience sur ce point). Si je constate que son utilisation est plus simple que le RAID logiciel je l'utiliserais peut-être... Il faut que je prenne le temps de lire sa doc.
Hors ligne
Dernière modification par raleur (06-10-2022 07:05:15)
Il vaut mieux montrer que raconter.
Hors ligne
Je n'ai pas d'expérience avec le RAID matériel. Si c'est du vrai RAID matériel et pas du "fake RAID", pourquoi pas. C'est plus transparent pour l'OS, mais pas forcément aussi flexible (possible de découper un disque en plusieurs ensembles de niveaux différents ?) et il faut voir la supervision par l'OS en cas de panne d'un disque.
Ok. A priori ce n'est pas du "fake RAID" (ce n'est pas la carte mère qui le gère mais bien une carte spécifique). Je prendrais ma décision après avoir lu sa doc. Pour la supervision en cas de panne d'un disque, j'imagine que ce sera transparent pour Debian. Pareil, il faut que lise la doc de la carte.
En tout cas, peu importe le type de RAID (logiciel ou matériel), je me suis décidé pour une configuration en RAID6, contenant un VG LVM de 2 volumes logiques : / et swap. Ce qui me permettra d'utiliser les 8 disques et de ne perdre ni système ni données si 2 disques lâchent en même temps ou successivement (avant que le premier ayant lâché ait pu être remplacé). Ça me semble être l'idéal.
Hors ligne
Pour la supervision en cas de panne d'un disque, j'imagine que ce sera transparent pour Debian.
Ça ne peut pas être transparent, il faut bien un mécanisme pour prévenir l'administrateur qu'un disque est en panne et doit être remplacé, par exemple par mail. Avec le RAID logiciel, c'est mdadm --monitor qui le fait. Il y a des programmes specifiques pour certains modèles de contrôleurs RAID.
Dernière modification par raleur (07-10-2022 07:47:59)
Il vaut mieux montrer que raconter.
Hors ligne
debi3368 a écrit :Pour la supervision en cas de panne d'un disque, j'imagine que ce sera transparent pour Debian.
Ça ne peut pas être transparent, il faut bien un mécanisme pour prévenir l'administrateur qu'un disque est en panne et doit être remplacé, par exemple par mail.
Effectivement, c'est logique...
Pour le RADI6, je viens de me rappeler de ce que mentionne le manuel d'installation de Debian : https://www.debian.org/releases/stable/ … -partition "Note : Assurez-vous que le système peut être amorcé avec le schéma de partitionnement prévu. Quand on utilise RAID pour le système de fichiers racine (/), il est nécessaire de créer un système de fichiers distinct pour /boot. La plupart des programmes d'amorçage (grub par exemple) ne peuvent fonctionner qu'avec le type RAID1 (RAID en mode miroir, sans bande). Ainsi, il est possible d'utiliser RAID5 pour / et RAID1 pour /boot.".
J'en déduis que si je tiens absolument à maintenir le système en cas de défaillance de 2 disques, il me faut faire du RAID 1 sur 3 disques pour /boot et du RAID6 sur 8 disques pour /.
Quel bazar 
.
Hors ligne
Quand on utilise RAID pour le système de fichiers racine (/), il est nécessaire de créer un système de fichiers distinct pour /boot. La plupart des programmes d'amorçage (grub par exemple) ne peuvent fonctionner qu'avec le type RAID1
Cette restriction ne concerne que le RAID logiciel. De plus elle est obsolète avec GRUB2 qui sait lire la plupart des niveaux de RAID (0, 1, 10, 4, 5, 6). Il ne supporte pas le RAID "linear" mais je ne vois pas qui peut avoir envie d'utiliser ça, LVM est bien plus souple.
Il vaut mieux montrer que raconter.
Hors ligne
. Je n'ai donc plus qu'à me décider entre RAID logiciel et RAID matériel..
Hors ligne