RAID : construction et délai - [RESOLU]

RidingAround · Le 17/11/2020, à 22:25

Bonsoir à tous,

je suis en train de me monter un deuxième pc.
J'opte pour le raid 5 avec mdadm, partant d'un SSD déjà installé.

Voici mes étapes :

mdadm --create /dev/md0 --level=5 --raid-devices=4 /dev/sdb /dev/sdc /dev/sdd /dev/sde
mdadm monitor --daemonise /dev/md0
mdadm --detail /dev/md0
mkfs.ext4 /dev/md0 (1)
cryptsetup luksFormat /dev/md0
cryptsetup lukOpen /dev/md0 xxx
mkfs.ext4 /dev/mapper/xxx
mount /dev/mapper/home /mnt/yyy
umount /mnt/yyy
cat /proc/mdstat
sudo mdadm --detail --scan | sudo tee -a /etc/mdadm/mdadm.conf
sudo update-initramfs -u

crypttab
home /dev/md0 none luks

fstab
/dev/mapper/xxx /home ext4 defaults 0 0

ou
echo '/dev/md0 /mnt/md0 ext4 defaults,nofail,discard 0 0' | sudo tee -a /etc/fstab

Je me pose deux questions:
(1) suis-je obligé de formater /dev/md0 avant de le chiffrer et donc de le reformater ?
(2) est-il normal de voir une resync avec un premier disque dégradé dès le début ? (4 disques neufs, config neuve)
(2) est-il impératif d'attendre les 2108 minutes annoncées avant d'oser redémarrer le pc ? je l'ai fait 30 min après la création du raid, au démarrage, les disques étaient non-raid, et j'ai dû tout recommencer; même avec une création de raid par le bios ...
peut-on faire une entrée mdadm.conf en pensant que cela suffirait à redémarrer avant de pouvoir se lancer dans de longs transferts de données ?
(2 toujours) j'ai vu la vitesse de resynchro passer de 50000 à 8000 dans cat /proc/mdstat, pourquoi de tels écarts ?
(2 ultime) dans fdisk -l j'ai
"La table de partitions GPT primaire est corrompue, mais la sauvegarde semble fonctionnelle, elle sera donc utilisée."
alors que j'ai encore rien pu/osé faire avec mon raid ... étrange non ?

merci

Dernière modification par RidingAround (Le 18/11/2020, à 20:24)

geole · Le 18/11/2020, à 10:36

Bonjour.
Je vais te donner un avis archi-connu. "essayer avant d'installer"!
Je joue ton scénario à échelle réduite et vais t'en dire plus.

Lorsque tu décides d'utiliser des disques entiers au lieu de partitions, ne sois pas surpris que la table de partition soit devenue inutile.
Dans le meilleur des cas, cela te fait gagner environ 3 Mo d'espace disque dans le RAIDS et beaucoup moins (48 Ko) si tu fabriques une partition qui commence au secteur 36 avec 'gnome disk utility' au lieu du secteur 2048 avec gparted.

Vu ce que tu dis, je pense que tes 4 disques ne contiennent aucune donnée personnelle.
Tu aurais certainement pu mettre l'option "- -assume-clean " qui évite certainement la synchronisation

sudo mdadm --create /dev/md10  --assume-clean --level=5 --raid-devices=4  /dev/sdc11 /dev/sdc12 /dev/sdc13 /dev/sdc14
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md10 started.

Nota: le raid est composé de 4 partitions de 1 Go préalablement remises à zéro. (C'est facultatif)

date
mer. 18 nov. 2020 11:09:34 CET

sudo cryptsetup luksFormat /dev/md10

WARNING!
========
Cette action écrasera définitivement les données sur /dev/md10.

Are you sure? (Type uppercase yes): YES
Saisissez la phrase secrète pour /dev/md10 : 
Vérifiez la phrase secrète : 

date
mer. 18 nov. 2020 11:10:43 CET

Donc , il n'y a pas lieu de formater préalablement en ext4.
Puis la suite telle que tu la prévoies.

sudo cryptsetup luksOpen  /dev/md10 MD10
Saisissez la phrase secrète pour /dev/md10 : 

sudo mkfs.ext4 /dev/mapper/MD10
mke2fs 1.45.5 (07-Jan-2020)
En train de créer un système de fichiers avec 780672 4k blocs et 195456 i-noeuds.
UUID de système de fichiers=03f35c05-eaef-44c6-84a6-ec8cd79660a4
Superblocs de secours stockés sur les blocs : 
	32768, 98304, 163840, 229376, 294912

Allocation des tables de groupe : complété                            
Écriture des tables d'i-noeuds : complété                            
Création du journal (16384 blocs) : 
complété
Écriture des superblocs et de l'information de comptabilité du système de
fichiers : complété

sudo mkdir /media/md10
sudo mount -v /dev/mapper/MD10 /media/md10
mount : /dev/mapper/MD10 monté sur /media/md10.

ls -als /media/md10
total 24
 4 drwxr-xr-x  3 root root  4096 nov.  18 12:38 .
 4 drwxr-xr-x 21 root root  4096 nov.  18 10:50 ..
16 drwx------  2 root root 16384 nov.  18 12:38 lost+found

Ma remarque
Si tes 4 disques ont une taille quasiment identique, tu peux fabriquer au niveau disque. Cela évite la création de partitions.
Sinon tu as intérêt à fabriquer au niveau partition de cette façon.
1) Rechercher le disque le plus petit en taille.
2) Lui fabriquer une partition occupant la totalité de l'espace disponible. Avec gnome disque utility, en choisissant comme unité le Kio, tu pourras avoir un maxima d'espace.
Cela donnera une partition N° 1
3) Pour chacun des trois autres disques
Fabriquer une partition N°1 de taille identique à la première.
Fabriquer une partition N°2 avec le reste de l'espace disponible.
4) Avec les partitions N°2 tu pourras faire ce que tu veux. Par exemple un LVM.

Mon coup de gueule! Laisse donc le répertoire /home dans le SSD et contente-toi de mettre tes données personnelles en sécurité dans ce raid chiffré.
.

En espérant que cet essai puisse te servir.

Dernière modification par geole (Le 18/11/2020, à 13:05)

RidingAround · Le 18/11/2020, à 17:00

Merci à toi.
Je vais donc remonter ce raid en supprimant les étapes (des tutoriels) pas nécessaires.
Tu penses que :

sudo mdadm --detail --scan | sudo tee -a /etc/mdadm/mdadm.conf
sudo update-initramfs -u

est vraiment nécessaire ? On n'en parle pas tout le temps.

Pour le home sur le ssd, non, je préfère en raid chiffré. J'ai déjà un pc monté comme ça et ça marche très bien depuis 5 ans.
La seule différence entre ces deux machines, puisque c'est aussi le même matos, c'est que le raid de la première est fait par le bios, et que je voulais le faire à présent en mdadm pour l'expérience.

Mes disques sont tous les mêmes, 1To, et neufs. Je passerai donc directement par une ràz des disques avant de monter le raid.

merci !

geole · Le 18/11/2020, à 17:10

Puisque tu mets tout le répertoire home dans le raids, comme ce répertoire est absolument nécessaire pour booter, il faut que tu fasses les deux commandes

tail -2  /etc/mdadm/mdadm.conf
# This configuration was auto-generated on Tue, 27 Oct 2020 14:56:12 +0100 by mkconf

sudo mdadm --detail --scan | sudo tee -a /etc/mdadm/mdadm.conf

tail -3 /etc/mdadm/mdadm.conf
# This configuration was auto-generated on Tue, 27 Oct 2020 14:56:12 +0100 by mkconf
ARRAY /dev/md/0 metadata=1.2 name=b:0 UUID=331e0e1b:11067f6d:e9799556:57614582
ARRAY /dev/md10 metadata=1.2 name=b:10 UUID=9453315f:aa6eacc7:518c55c6:bb6a8ff2

sudo update-initramfs -u
update-initramfs: Generating /boot/initrd.img-5.4.0-54-generic

geole · Le 18/11/2020, à 18:08

Mais cela ne suffit pas pour monter le raids

Je vais garnir le fichier /etc/crypttab

cat /etc/crypttab
 ###Modifier le fichier /etc/crypttab :

 # <target name> <source device>         <key file>      <options>
MD10 /dev/md10  none    luks

et le fichier /etc/fstab

tail -5 /etc/fstab


/dev/mapper/MD10  /media/md10 auto nosuid,nodev,nofail,x-gvfs-show 0 0

Voila c'est bon.... Il est monté sur md10

mount | grep mapper
/dev/mapper/MD10 on /media/md10 type ext4 (rw,nosuid,nodev,relatime,stripe=384,x-gvfs-show)

lsblk -fe7 -o +size
NAME FSTYPE LABEL UUID                                 FSAVAIL FSUSE% MOUNTPOINT   SIZE
.......
sdc                                                                                3,7T
....

├─sdc11
│    linux_ b:10  9453315f-aa6e-acc7-518c-55c6bb6a8ff2                               1G
│ └─md10
│    crypto       665766e4-45c8-45b3-ba3f-c8fc8d9a606c                               3G
│   └─MD10
│      ext4         03f35c05-eaef-44c6-84a6-ec8cd79660a4    2,7G     0% /media/md1     3G
├─sdc12
│    linux_ b:10  9453315f-aa6e-acc7-518c-55c6bb6a8ff2                               1G
│ └─md10
│    crypto       665766e4-45c8-45b3-ba3f-c8fc8d9a606c                               3G
│   └─MD10
│      ext4         03f35c05-eaef-44c6-84a6-ec8cd79660a4    2,7G     0% /media/md1     3G
├─sdc13
│    linux_ b:10  9453315f-aa6e-acc7-518c-55c6bb6a8ff2                               1G
│ └─md10
│    crypto       665766e4-45c8-45b3-ba3f-c8fc8d9a606c                               3G
│   └─MD10
│      ext4         03f35c05-eaef-44c6-84a6-ec8cd79660a4    2,7G     0% /media/md1     3G
├─sdc14
│    linux_ b:10  9453315f-aa6e-acc7-518c-55c6bb6a8ff2                               1G
│ └─md10
│    crypto       665766e4-45c8-45b3-ba3f-c8fc8d9a606c                               3G
│   └─MD10
│      ext4         03f35c05-eaef-44c6-84a6-ec8cd79660a4    2,7G     0% /media/md1     3G
.

Dernière modification par geole (Le 18/11/2020, à 18:33)

RidingAround · Le 18/11/2020, à 18:32

En effet, j'ai dû remonter le raid à la main sur mon premier pc suite à défaillance, et crypttab est nécessaire; j'en parle dans mon premier post.
J'ai réussi sur le premier ce que je n'arrive pas à faire sur le deuxième.

Tiens regarde, j'ai fait celui dont on parle hier, j'étais à 53% de resync aujourd'hui, je redémarre le pc, et lsblk me donne ça :

sdb      8:16   0 931,5G  0 disk 
sdc      8:32   0 931,5G  0 disk 
sdd      8:48   0 931,5G  0 disk 
sde      8:64   0 931,5G  0 disk 
sdf      8:80   0   2,7T  0 disk 
├─sdf1   8:81   0   128M  0 part 
└─sdf2   8:82   0   2,7T  0 part /media/m/raid

Dernière modification par RidingAround (Le 18/11/2020, à 18:32)

RidingAround · Le 18/11/2020, à 18:39

Je viens de faire ça:

mdadm --create /dev/md0 --assume-clean --level=5 --raid-devices=4 /dev/sdb /dev/sdc /dev/sdd /dev/sde

J'obtiens ça:

sdb      8:16   0 931,5G  0 disk  
└─md0    9:0    0   2,7T  0 raid5 
sdc      8:32   0 931,5G  0 disk  
└─md0    9:0    0   2,7T  0 raid5 
sdd      8:48   0 931,5G  0 disk  
└─md0    9:0    0   2,7T  0 raid5 
sde      8:64   0 931,5G  0 disk  
└─md0    9:0    0   2,7T  0 raid5

Je vais faire ça:

sudo mdadm --detail --scan | sudo tee -a /etc/mdadm/mdadm.conf

sudo update-initramfs -u

et redémarrer de suite pour voir si je perds pas mon temps avec le reste.

Dernière modification par RidingAround (Le 18/11/2020, à 18:40)

RidingAround · Le 18/11/2020, à 18:44

Tu vois ce que je ne comprends pas, c'est que le raid au démarrage, il semble avoir disparu :

lsblk
sdb      8:16   0 931,5G  0 disk 
sdc      8:32   0 931,5G  0 disk 
sdd      8:48   0 931,5G  0 disk 
sde      8:64   0 931,5G  0 disk

cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10] 
unused devices: <none>

Mais pour aller plus loin même avec le montage du raid par le bios, il ne tient pas au redémarrage !

Dernière modification par RidingAround (Le 18/11/2020, à 18:54)

RidingAround · Le 18/11/2020, à 19:10

Encore plus fou:

je viens de faire de nouvelles partitions GPT avec fdisk sur mes 4 disques.

Puis

mdadm --create /dev/md0 --assume-clean --level=5 --raid-devices=4 /dev/sdb /dev/sdc /dev/sdd /dev/sde

et

mkfs.ext4 /dev/md0

me donne:

/dev/md0 contient un système de fichiers crypto_LUKS

là je comprends plus rien. Si j'ai de telles persistences dans les disques, je maîtrise plus rien.

RidingAround · Le 18/11/2020, à 19:36

Ok j'ai compris pour ça:

j'avais construit le raid directement sur les disques.

mdadm --create /dev/md0 --assume-clean --level=5 --raid-devices=4 /dev/sdb /dev/sdc /dev/sdd /dev/sde

j'ai cette fois créé des partitions raid avec fdisk :

fdisk /dev/sdx

successivement

et dedans :
g = pour constituer une nouvelle table de partitions GPT
n = pour faire une nouvelle partition
et surtout
t pour changer le type de partition vers 29, le numéro des partitions appelées Linux RAID

Ensuite j'ai construit le raid sur les partitions, cette fois :

mdadm --create /dev/md0 --assume-clean --level=5 --raid-devices=4 /dev/sdb1 /dev/sdc1 /dev/sdd1 /dev/sde1

Je me suis fendu d'un

sudo mdadm --detail --scan | sudo tee -a /etc/mdadm/mdadm.conf

bien que certains se réclament de son inutilité.
et même d'un

update-initramfs -u

au reboot, ça tient... et --assume-clean en effet, évite le resync inutile, puisque dédié à la propagation de donénes dans la grappe.

Je continue

RidingAround · Le 18/11/2020, à 20:23

RESOLU !

en effet, après application du crypttab et du fstab, boot ok, déchiffrement proposé et montage automatique.

Donc voilà les commandes à réaliser POUR CRÉER ET MONTER UN RAID 5 CHIFFRÉ AU DÉMARRAGE :

1/ partitionner successivement les disques avec fdisk

fdisk /dev/sdx

taper g - pour nouvelle table GPT
n et entrée 3 fois - pour créer une partition
t - pour changer le type de partition
29 - car c'est l'identifiant des Linux RAID
w - pour écrire et sortir
=> attention, idéalement, les partitions doivent avoir la même taille, sous peine d'amputer la capacité globale du raid, pour cause de redondance équilibrée des données

2/ créer le raid sur les partitions

mdadm --create /dev/md0 --assume-clean --level=5 --raid-devices=4 /dev/sdb1 /dev/sdc1 /dev/sdd1 /dev/sde1

=> si vous ne passez pas --assume-clean, vous aurez droit à une resync qui peut durer des jours et ne sert à rien en création

3/ constater la présence du raid

mdadm --detail /dev/md0

ou

cat /proc/mdstat

4/ éventuellement activer le monitoring (santé disques)

mdadm monitor --daemonise /dev/md0

5/ formater le raid (je ne sais pas si c'est nécessaire)

mkfs.ext4 /dev/md0

6/ activer le chiffrement et créer le mot de passe
cryptsetup luksFormat /dev/md0

7/ ouvrir la partition - on a besoin de lui donner un nom pour la retrouver dans /dev/mapper/xxx

cryptsetup lukOpen /dev/md0 xxx

8/ formater la partition chiffrée pour la rendre montable et utilisable - cette fois dans dev/mapper/

mkfs.ext4 /dev/mapper/xxx

9/ monter la partition obtenue

mount /dev/mapper/home /mnt/yyy

10/ si tout fonctionne bien, renseigner /proc/mdadm/mdadm.conf - (je ne sais pas si c'est nécessaire)

sudo mdadm --detail --scan | sudo tee -a /etc/mdadm/mdadm.conf

11/ renseigner le système - (je ne sais pas si c'est nécessaire)

sudo update-initramfs -u

12/ à partir de là, votre raid est stable, vous pouvez donc le monter au boot - ici en /home

nano /etc/crypttab

xxx /dev/md0 none luks
=> dans cet exemple, on dit, à l'envers, que /dev/md0 doit être décrypté au boot (saisie mdp) puis mappé comme xxx

fstab
/dev/mapper/xxx /home ext4 defaults 0 0
=> ici, on lui dit de monter en /home avec des options de traitement par défaut.

J'utilise des raid5 de 4 HDD de 1To depuis des années pour tout, cela me donne toute satisfaction - et j'ai un actuellement un Celeron G3900... La racine est sur un SSD en M2, mais on peut tout mettre dedans. Avec 4 disques, la capa et la vitesse sont bonnes pour un usage très diversifié. On peut faire 5 ou 6 disques, utiliser des SSD - avec un processeur puissant.

Youp !

Dernière modification par RidingAround (Le 18/11/2020, à 20:47)

kamaris · Le 18/11/2020, à 21:06

Il est préférable de mettre l'UUID dans le /etc/crypttab, car les noms en /dev/* peuvent changer.
Par contre attention, il s'agit de l'UUID du conteneur luks, pas de ce qu'il contient (voir le retour de lsblk pour ça, en lui faisant afficher entre autres l'UUID).

RidingAround · Le 18/11/2020, à 21:47

Oui, en effet, j'avais vu sur la route que je pouvais le faire, comme dans fstab en fait.

ls -la /dev/disk/by-uuid/
total 0
drwxr-xr-x 2 root root 140 nov.  18 21:31 .
drwxr-xr-x 8 root root 160 nov.  18 21:28 ..
lrwxrwxrwx 1 root root  10 nov.  18 21:31 2986ed8f-a7bd-46bd-bb4c-c4627c89eb79 -> ../../dm-0
lrwxrwxrwx 1 root root  10 nov.  18 21:28 82ef4417-23b1-4dc8-bd37-da8d0ef7d190 -> ../../sda5
lrwxrwxrwx 1 root root  10 nov.  18 21:28 b4ecbad3-a0cb-4bfe-ae6d-e795d0464249 -> ../../sda1
lrwxrwxrwx 1 root root  10 nov.  18 21:28 e1902f31-d118-4355-9f7c-d269b0a44c60 -> ../../sdf2
lrwxrwxrwx 1 root root   9 nov.  18 21:31 e3f8d828-21e5-4892-a29f-bed65b704dc5 -> ../../md0

Ce serait la dernière ligne dans le cas de mon exmple avec md0.
Par contre, la première je vois pas.

Dernière modification par RidingAround (Le 18/11/2020, à 21:59)

kamaris · Le 18/11/2020, à 21:53

Peut-être ce qu'il y a dans le conteneur justement.
Fais voir le retour de

lsblk -o name,size,type,fstype,mountpoint,uuid

RidingAround · Le 18/11/2020, à 22:00

Oui, commande intéressante.
J'ai lu à l'instant que c'est un truc par défaut pour LVM. Pas utilisé semble-t-il dans mon cas.

Tiens:

sda        238,5G disk                                                   
├─sda1      37,3G part  ext4              /                              b4ecbad3-a0cb-4bfe-ae6d-e795d0464249
├─sda2         1K part                                                   
└─sda5     197,4G part  ext4                                             82ef4417-23b1-4dc8-bd37-da8d0ef7d190
sdb        931,5G disk                                                   
└─sdb1     931,5G part  linux_raid_member                                da423de3-2028-b007-53b6-2ba60740f3f8
  └─md0      2,7T raid5 crypto_LUKS                                      e3f8d828-21e5-4892-a29f-bed65b704dc5
    └─raid   2,7T crypt ext4              /home                          2986ed8f-a7bd-46bd-bb4c-c4627c89eb79
sdc        931,5G disk                                                   
└─sdc1     931,5G part  linux_raid_member                                da423de3-2028-b007-53b6-2ba60740f3f8
  └─md0      2,7T raid5 crypto_LUKS                                      e3f8d828-21e5-4892-a29f-bed65b704dc5
    └─raid   2,7T crypt ext4              /home                          2986ed8f-a7bd-46bd-bb4c-c4627c89eb79
sdd        931,5G disk                                                   
└─sdd1     931,5G part  linux_raid_member                                da423de3-2028-b007-53b6-2ba60740f3f8
  └─md0      2,7T raid5 crypto_LUKS                                      e3f8d828-21e5-4892-a29f-bed65b704dc5
    └─raid   2,7T crypt ext4              /home                          2986ed8f-a7bd-46bd-bb4c-c4627c89eb79
sde        931,5G disk                                                   
└─sde1     931,5G part  linux_raid_member                                da423de3-2028-b007-53b6-2ba60740f3f8
  └─md0      2,7T raid5 crypto_LUKS                                      e3f8d828-21e5-4892-a29f-bed65b704dc5
    └─raid   2,7T crypt ext4              /home                          2986ed8f-a7bd-46bd-bb4c-c4627c89eb79
sdf          2,7T disk                                                   
├─sdf1       128M part                                                   
└─sdf2       2,7T part  ext4              /media/m/raid                  e1902f31-d118-4355-9f7c-d269b0a44c60

kamaris · Le 18/11/2020, à 22:10

Oui c'est ça, le dm-0 correspond à la partition ext4 dans ton conteneur, on peut faire le lien via l'UUID.
Et pour le conteneur lui-même, c'était bien la dernière ligne dans ton retour en #13.
Donc pour le /etc/crypttab, ça donnerait :

xxx UUID=e3f8d828-21e5-4892-a29f-bed65b704dc5 none luks

geole · Le 19/11/2020, à 09:26

RidingAround a écrit :

Pour le home sur le ssd, non, je préfère en raid chiffré.

Bonjour,
Bien que cette discussion soit fermée, je me permets de revenir sur ce point.
Je t'ai dit que je souhaite que le répertoire /home soit dans la même partition que le logiciel, car s'il est absent, cela ne boote plus, La rectification en recovery n'est pas évidente, il a fallu restaurer. ( https://forum.ubuntu-fr.org/viewtopic.php?id=2058297 )
En voici une autre par laquelle c'est mal parti https://forum.ubuntu-fr.org/viewtopic.php?id=2056088
Je sais que le problème n'arrive qu'aux autres et que maintenant il est trop tard.

Malgré tout, voici mon conseil pour que le sous-répertoire $HOME soit ailleurs.

Souvent je dis qu'il est pratique d'avoir un second utilisateur administrateur qui ne sert qu'en mode dépannage.

Voici donc la démarche. Elle est inversée dans mon contexte. Je pense n'avoir rien oublié car j'écris après avoir réalisé.
1) Créer normalement les utilisateurs ( a et sos dans mon contexte).
2) Fabriquer le raids chiffré et vérifier qu'il fonctionne bien.
3) Lorsque c'est fait, migrer l'utilisateur principal dans le RAIDS et faire un lien mais ne pas toucher à l'utilisateur de secours .
Donc en théorie, si le RAIDS ou le chiffrage foire, on pourra toujours se connecter avec l'utilisateur de secours .
4) Réalisation.
a) Se connecter avec l'utilisateur de secours .
b) Se positionner dans le répertoire.

    cd /media/md10

c) Y transférer l'utilisateur principal (dans mon contexte).

     sudo    mv  /home/sos

d) Redonner à l'utilisateur ses droits.

   sudo chown sos:sos /media/md10/sos

e) Faire un lien.

    sudo ln -ls /media/md10/sos /home

f) Vérifier

 ls -ls /home
total 4
4 drwxr-xr-x 24 a    a    4096 nov.  19 08:29 a
0 lrwxrwxrwx  1 root root   15 nov.  19 08:26 sos -> /media/md10/sos

 ls -ls /media/md10
total 20
16 drwx------  2 root root 16384 nov.  18 12:38 lost+found
 4 drwxr-xr-x 15 sos  sos   4096 nov.   7 12:59 sos

ls -als /media/md10/sos
total 76
4 drwxr-xr-x 15 sos  sos  4096 nov.   7 12:59 .
4 drwxr-xr-x  4 root root 4096 nov.  19 08:25 ..
4 -rw-------  1 sos  sos   352 nov.   8 15:26 .bash_history
4 -rw-r--r--  1 sos  sos   220 août  16 18:49 .bash_logout
4 -rw-r--r--  1 sos  sos  3771 août  16 18:49 .bashrc
4 drwxr-xr-x  2 sos  sos  4096 nov.   7 12:52 Bureau
4 drwx------ 13 sos  sos  4096 nov.   7 12:55 .cache
4 drwx------ 11 sos  sos  4096 nov.   7 13:58 .config
4 drwxr-xr-x  2 sos  sos  4096 nov.   7 12:52 Documents
4 drwx------  3 sos  sos  4096 nov.   7 12:52 .gnupg
4 drwxr-xr-x  2 sos  sos  4096 nov.   7 12:52 Images
4 drwxr-xr-x  3 sos  sos  4096 nov.   7 12:52 .local
4 drwxr-xr-x  2 sos  sos  4096 nov.   7 12:52 Modèles
4 drwx------  5 sos  sos  4096 nov.   7 12:55 .mozilla
4 drwxr-xr-x  2 sos  sos  4096 nov.   7 12:52 Musique
4 -rw-r--r--  1 sos  sos   807 août  16 18:49 .profile
4 drwxr-xr-x  2 sos  sos  4096 nov.   7 12:52 Public
4 drwxr-xr-x  2 sos  sos  4096 nov.   7 12:52 Téléchargements
4 drwxr-xr-x  2 sos  sos  4096 nov.   7 12:52 Vidéos

g) Se reconnecter avec l'utilisateur principal.

Dernière modification par geole (Le 19/11/2020, à 09:35)

RidingAround · Le 19/11/2020, à 10:31

Oui, une idée qui peut avoir un intérêt pour /home
Toutefois, depuis 10 ans j'installe les /home séparés. C'est des centaines d'installations.
Ce que j'ai pu constater statistiquement, c'est que les migrations et réinstallations son largement simplifiées.
En cas de problème système, ce qui est l'écrasante majorité des cas, tu relances une live et tu installes sur / sans toucher au reste.
Ensuite tu refais pointer fstab et c'est fini, 10 minutes. C'est très fréquent, je dois en avoir une dizaine par an.
C'est aussi valable pour des updates avec des connexions lentes où tu aurais 20 min de download et le reste.
Je n'ai jamais eu de cas de home disparu, chiffré ou non. 100% de cas touchaient les racines, suites à upgrade ou release upgrade.

Pour l'exemple d'une partition effacée, là c'est quand même un évènement (que je n'ai jamais vu) où le type supprime sa partoche à la mimine devant Harry Potter !
Alors oui des défaillances de disque pourraient mener à cela, mais aussi à bousiller tout dossier et empêcher le démarrage. L'utilitaire Disques permet de lire la smart. Quand tu en es à opérer comme ces mecs, tu peux te fendre d'un coup d'oeil avant tout, avant même de faire ton dual-boot sur ton $ portable qui a 6 ans.

Pour ce qui est de mon raid chiffré, je partirais d'une live de la même manière en cas de besoin.

J'ai aussi 4 avantages: la redondance du raid, j'ai un rsync quotidien vers mon NAS et un rsync bi-directionnel, dont j'ai parlé ici hier soir (rsync -protuvagHAWX --delete-after / autre fil) qui semble fonctionner; j'en saurai plus demain. La fonction monitoring du raid est un garde fou supplémentaire avec les alertes mail.

Globalement, dès que tu chiffres, tu sais que tu dois t'entourer de précautions qui s'ajouteront à la complication technique initiale, faute de quoi les contenus ont bien des moyens de disparaître. Déjà, juste avec ton mdp de session qui devient critique.

Merci de ta contribution, je sais que ça représente du temps quand les participants mettent en oeuvre.

Dernière modification par RidingAround (Le 19/11/2020, à 10:33)

geole · Le 19/11/2020, à 11:16

Je reconnais que l'exemple fourni est surprenant. Mais je peux t'en trouver des dizaines dans lesquels le boot était planté, Il fallait en chercher la cause car rien n'était indiqué. J'ai du demander des photos des incidents de boot avec la commande journalctl -xb pour trouver les lignes en rouge.... C'était le /home qui était dans une autre partition et qui avait besoin d'un FSCK pour se monter correctement.
Personnellement, je suis partisan d'un FSCK d'auto-réparation à chaque démarrage pour éviter ce pépin.
D'autres pensent que le masquer procure une fausse sécurité et c'est vrai!

Dernière modification par geole (Le 19/11/2020, à 11:17)

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 17/11/2020, à 22:25

RAID : construction et délai - [RESOLU]

#2 Le 18/11/2020, à 10:36

Re : RAID : construction et délai - [RESOLU]

#3 Le 18/11/2020, à 17:00

Re : RAID : construction et délai - [RESOLU]

#4 Le 18/11/2020, à 17:10

Re : RAID : construction et délai - [RESOLU]

#5 Le 18/11/2020, à 18:08

Re : RAID : construction et délai - [RESOLU]

#6 Le 18/11/2020, à 18:32

Re : RAID : construction et délai - [RESOLU]

#7 Le 18/11/2020, à 18:39

Re : RAID : construction et délai - [RESOLU]

#8 Le 18/11/2020, à 18:44

Re : RAID : construction et délai - [RESOLU]

#9 Le 18/11/2020, à 19:10

Re : RAID : construction et délai - [RESOLU]

#10 Le 18/11/2020, à 19:36

Re : RAID : construction et délai - [RESOLU]

#11 Le 18/11/2020, à 20:23

Re : RAID : construction et délai - [RESOLU]

#12 Le 18/11/2020, à 21:06

Re : RAID : construction et délai - [RESOLU]

#13 Le 18/11/2020, à 21:47

Re : RAID : construction et délai - [RESOLU]

#14 Le 18/11/2020, à 21:53

Re : RAID : construction et délai - [RESOLU]

#15 Le 18/11/2020, à 22:00

Re : RAID : construction et délai - [RESOLU]

#16 Le 18/11/2020, à 22:10

Re : RAID : construction et délai - [RESOLU]

#17 Le 19/11/2020, à 09:26

Re : RAID : construction et délai - [RESOLU]

#18 Le 19/11/2020, à 10:31

Re : RAID : construction et délai - [RESOLU]

#19 Le 19/11/2020, à 11:16

Re : RAID : construction et délai - [RESOLU]

Pied de page des forums