#1 Le 29/07/2021, à 11:02
- kholo
raid 5 : perte données après create... récupération possible ?
Bonjour,
J'ai fait une mise à jour d'un de mes serveurs de 16.04 à 20.04...
à cette occasion, j'ai marqué et débranché les disques en raid, fait la mise à jour et rebranché les disques dans le même ordre...
sauf que j'ai refait un create pour remonter le raid... et c'est là que je me suis rendu compte de ma bêtise...
j'ai rien fait de plus...
y a t'il un moyen de recréer le raid maintenant...
a priori d'après cette page oui... mais je ne veux pas rajouter de faute en plus alors je préfère demander avant...
le PC est monté autour de 5 disques :
4 pour le raid sur sda, sdb, sdc et sdd
1 pour l'OS sur sde
kholo@monde:~$ sudo blkid
[sudo] Mot de passe de kholo :
/dev/sde2: UUID="44c01bbb-1c8f-4885-8d7a-29110f69c7f4" TYPE="swap" PARTUUID="4ee0b1e5-5d78-4453-9b65-cb97d8db0ea4"
/dev/sde1: UUID="debd4158-d9a8-4300-bfb8-8a8ea603d38e" TYPE="ext4" PARTUUID="7db717dd-122e-4d99-a9aa-7f005562d520"
/dev/loop0: TYPE="squashfs"
/dev/loop1: TYPE="squashfs"
/dev/loop2: TYPE="squashfs"
/dev/loop3: TYPE="squashfs"
/dev/loop4: TYPE="squashfs"
/dev/sda: UUID="ddcbf221-4e72-bb6d-e317-e5a02e94376d" UUID_SUB="95902af9-388c-cdd9-970d-8cf23099a0c8" LABEL="monde:0" TYPE="linux_raid_member"
/dev/sdc: UUID="ddcbf221-4e72-bb6d-e317-e5a02e94376d" UUID_SUB="4979763d-0277-73fa-963d-1fcdf65d5668" LABEL="monde:0" TYPE="linux_raid_member"
/dev/sdd: UUID="ddcbf221-4e72-bb6d-e317-e5a02e94376d" UUID_SUB="2bc8ac01-4752-2d46-4774-5f950a10b7ff" LABEL="monde:0" TYPE="linux_raid_member"
/dev/sde3: UUID="6c387736-8d10-415c-a920-7d441ccf0c29" TYPE="ext4" PARTUUID="9ce22340-e189-4001-92f1-15b999738ead"
/dev/sdb: UUID="ddcbf221-4e72-bb6d-e317-e5a02e94376d" UUID_SUB="e9345cb1-f29e-c7fd-3f60-9916b94a883e" LABEL="monde:0" TYPE="linux_raid_member"
mon fstab... au cas où...
kholo@monde:~$ cat /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point> <type> <options> <dump> <pass>
# / was on /dev/sda1 during installation
UUID=debd4158-d9a8-4300-bfb8-8a8ea603d38e / ext4 errors=remount-ro 0 1
# /home was on /dev/sda3 during installation
UUID=6c387736-8d10-415c-a920-7d441ccf0c29 /home ext4 defaults 0 2
# swap was on /dev/sda2 during installation
UUID=44c01bbb-1c8f-4885-8d7a-29110f69c7f4 none swap sw 0 0
ce que j'ai fait pour le premier montage
sudo apt install mdadm
sudo mdadm --create --verbose /dev/md0 --level=raid5 --raid-devices=4 /dev/sda /dev/sdb /dev/sdc /dev/sdd
sudo mdadm --detail --scan | sudo tee /etc/mdadm.conf
sudo mkfs.ext4 /dev/md0
sudo mount /dev/md0 /mnt/raid1
cd /mnt/raid1
sudo mkdir Monde
sudo chown $USER:$USER Monde
après mise à jour et rebranchement ma bêtise :
kholo@monde:~$ sudo mdadm --create --verbose /dev/md0 --level=raid5 --raid-devices=4 /dev/sda /dev/sdb /dev/sdc /dev/sdd
mdadm: layout defaults to left-symmetric
mdadm: layout defaults to left-symmetric
mdadm: chunk size defaults to 512K
mdadm: /dev/sda appears to be part of a raid array:
level=raid5 devices=4 ctime=Wed Mar 18 15:10:26 2020
mdadm: /dev/sdb appears to be part of a raid array:
level=raid5 devices=4 ctime=Wed Mar 18 15:10:26 2020
mdadm: /dev/sdc appears to be part of a raid array:
level=raid5 devices=4 ctime=Wed Mar 18 15:10:26 2020
mdadm: /dev/sdd appears to be part of a raid array:
level=raid5 devices=4 ctime=Wed Mar 18 15:10:26 2020
mdadm: partition table exists on /dev/sdd but will be lost or
meaningless after creating array
mdadm: size set to 488254464K
mdadm: automatically enabling write-intent bitmap on large array
Continue creating array? yes
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md0 started.
... il faut vraiment que j'apprenne à lire !!
puis...
kholo@monde:~$ sudo mdadm --detail --scan | sudo tee /etc/mdadm.conf
ARRAY /dev/md0 metadata=1.2 spares=1 name=monde:0 UUID=ddcbf221:4e72bb6d:e317e5a0:2e94376d
su@monde:~$ sudo mount /dev/md0 /mnt/raid1
NTFS signature is missing.
Failed to mount '/dev/md0': Argument invalide
The device '/dev/md0' doesn't seem to have a valid NTFS.
Maybe the wrong device is used? Or the whole disk instead of a
partition (e.g. /dev/sda, not /dev/sda1)? Or the other way around?
kholo@monde:~$ ls /mnt
raid1
par avance merci pour les informations
14:17 EDIT :
je continue mes investigations en tentant de toucher le moins possible :
kholo@monde:~$ cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 sdd[4] sdc[2] sdb[1] sda[0]
1464763392 blocks super 1.2 level 5, 512k chunk, algorithm 2 [4/3] [UUU_]
[===================>.] recovery = 98.2% (479623544/488254464) finish=4.1min speed=34939K/sec
bitmap: 0/4 pages [0KB], 65536KB chunk
unused devices: <none>
kholo@monde:~$ sudo fdisk -l
[sudo] Mot de passe de kholo :
Disque /dev/loop0 : 54,98 MiB, 57626624 octets, 112552 secteurs
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d'E/S (minimale / optimale) : 512 octets / 512 octets
Disque /dev/loop1 : 255,58 MiB, 267980800 octets, 523400 secteurs
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d'E/S (minimale / optimale) : 512 octets / 512 octets
Disque /dev/loop2 : 62,9 MiB, 65105920 octets, 127160 secteurs
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d'E/S (minimale / optimale) : 512 octets / 512 octets
Disque /dev/loop3 : 49,8 MiB, 52203520 octets, 101960 secteurs
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d'E/S (minimale / optimale) : 512 octets / 512 octets
Disque /dev/loop4 : 29,9 MiB, 31334400 octets, 61200 secteurs
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d'E/S (minimale / optimale) : 512 octets / 512 octets
Disque /dev/sda : 465,78 GiB, 500107862016 octets, 976773168 secteurs
Disk model: WDC WD5003ABYX-1
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d'E/S (minimale / optimale) : 512 octets / 512 octets
Disque /dev/sdc : 465,78 GiB, 500107862016 octets, 976773168 secteurs
Disk model: WDC WD5000AUDX-7
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 4096 octets
taille d'E/S (minimale / optimale) : 4096 octets / 4096 octets
La table de partitions GPT primaire est corrompue, mais la sauvegarde semble fonctionnelle, elle sera donc utilisée.
Disque /dev/sdd : 465,78 GiB, 500107862016 octets, 976773168 secteurs
Disk model: ST500DM002-1BD14
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 4096 octets
taille d'E/S (minimale / optimale) : 4096 octets / 4096 octets
Type d'étiquette de disque : gpt
Identifiant de disque : 17DAD5C4-A03E-43E9-AC98-5BCBBF6792AF
Disque /dev/sde : 232,91 GiB, 250058268160 octets, 488395055 secteurs
Disk model: ST3250820AS
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d'E/S (minimale / optimale) : 512 octets / 512 octets
Type d'étiquette de disque : gpt
Identifiant de disque : F87DBE9C-6A5B-4F6B-893C-6BA865DE6F4A
Périphérique Début Fin Secteurs Taille Type
/dev/sde1 34 102398309 102398276 48,8G Système de fichiers Linux
/dev/sde2 102398310 118784609 16386300 7,8G Partition d'échange Linux
/dev/sde3 118784610 488392064 369607455 176,2G Système de fichiers Linux
Disque /dev/sdb : 465,78 GiB, 500107862016 octets, 976773168 secteurs
Disk model: ST500DM002-1BD14
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 4096 octets
taille d'E/S (minimale / optimale) : 4096 octets / 4096 octets
Disque /dev/md0 : 1,37 TiB, 1499917713408 octets, 2929526784 secteurs
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 4096 octets
taille d'E/S (minimale / optimale) : 524288 octets / 1572864 octets
kholo@monde:~$ sudo fsck.ext4 /dev/md0
e2fsck 1.45.5 (07-Jan-2020)
ext2fs_open2: Numéro magique invalide dans le super-bloc
fsck.ext4 : Superbloc invalide, tentons d'utiliser les blocs de sauvetage...
fsck.ext4: Numéro magique invalide dans le super-bloc lors de la tentative d'ouverture de /dev/md0
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>
et, bien sûr...
kholo@monde:~$ sudo mount /dev/md0 /mnt/raid1/
NTFS signature is missing.
Failed to mount '/dev/md0': Argument invalide
The device '/dev/md0' doesn't seem to have a valid NTFS.
Maybe the wrong device is used? Or the whole disk instead of a
partition (e.g. /dev/sda, not /dev/sda1)? Or the other way around?
je me tâte à faire un formatage que j'avais fait sur une autre machine auparavant sans aucun soucis...
un RAID 5 à 3 disques sur une machine que j'ai mise à jour, create puis
sudo mkfs.ext4 /dev/md0
et j'ai eu accès aux quelques données contenues...
coup de chance ?
la partie :
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>
est elle une solution ?
14:43 EDIT :
encore une info...
kholo@monde:~$ sudo mdadm --detail /dev/md0
[sudo] Mot de passe de kholo :
/dev/md0:
Version : 1.2
Creation Time : Thu Jul 29 11:07:34 2021
Raid Level : raid5
Array Size : 1464763392 (1396.91 GiB 1499.92 GB)
Used Dev Size : 488254464 (465.64 GiB 499.97 GB)
Raid Devices : 4
Total Devices : 4
Persistence : Superblock is persistent
Intent Bitmap : Internal
Update Time : Thu Jul 29 13:59:26 2021
State : clean
Active Devices : 4
Working Devices : 4
Failed Devices : 0
Spare Devices : 0
Layout : left-symmetric
Chunk Size : 512K
Consistency Policy : bitmap
Name : monde:0 (local to host monde)
UUID : ddcbf221:4e72bb6d:e317e5a0:2e94376d
Events : 1985
Number Major Minor RaidDevice State
0 8 0 0 active sync /dev/sda
1 8 16 1 active sync /dev/sdb
2 8 32 2 active sync /dev/sdc
4 8 48 3 active sync /dev/sdd
Dernière modification par kholo (Le 29/07/2021, à 13:44)
Hors ligne
#2 Le 29/07/2021, à 15:21
- geole
Re : raid 5 : perte données après create... récupération possible ?
Bonjour
Ne vas pas vite: Un FSCK détruit les données.
Avec la version 20.04, le logiciel MADAM est en version 1.2 metadata
Mais comme tu as créé en version 16.04 (si j'ai bien compris) il est possible que cela ne soit pas cette version mais une plus ancienne. Il va falloir mettre la main sur un vieux forum ou vérifier ce qui se passe en 16.04
A mon avis, tu pourrais tenter sans trop de risque d'assembler dans un autre point
sudo mdadm --assemble --verbose /dev/md69 --level=raid5 --raid-devices=4 /dev/sda /dev/sdb /dev/sdc /dev/sdd
AJOUT. Fausse piste
a@a:~$ sudo mdadm --create /dev/md69 --level=5 --raid-devices=4 /dev/sda13 /dev/sda14 /dev/sda19 /dev/sda21
[sudo] Mot de passe de a :
mdadm: An option must be given to set the mode before a second device
(/dev/md69) is listed
a@a:~$ sudo mdadm --create /dev/md69 --level=5 --raid-devices=4 /dev/sda13 /dev/sda14 /dev/sda19 /dev/sda21
mdadm: /dev/sda13 appears to contain an ext2fs file system
size=1048576K mtime=Thu Jan 1 01:00:00 1970
mdadm: /dev/sda14 appears to contain an ext2fs file system
size=1048576K mtime=Thu Jan 1 01:00:00 1970
mdadm: /dev/sda19 appears to contain an ext2fs file system
size=1048576K mtime=Thu Jan 1 01:00:00 1970
mdadm: /dev/sda21 appears to contain an ext2fs file system
size=1048576K mtime=Thu Jan 1 01:00:00 1970
Continue creating array? yes
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md69 started.
a@a:~$ cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=16.04
DISTRIB_CODENAME=xenial
DISTRIB_DESCRIPTION="Ubuntu 16.04.7 LTS"
sudo mkfs.ext4 /dev/md69
Dernière modification par geole (Le 29/07/2021, à 16:14)
Les grilles de l'installateur https://doc.ubuntu-fr.org/tutoriel/inst … _subiquity
"gedit admin:///etc/fstab" est proscrit, utilisez "pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY xdg-open /etc/fstab" Voir https://doc.ubuntu-fr.org/gedit
Les partitions EXT4 des disques externes => https://forum.ubuntu-fr.org/viewtopic.p … #p22697248
Hors ligne
#3 Le 29/07/2021, à 15:55
- kholo
Re : raid 5 : perte données après create... récupération possible ?
salut,
merci Geole
Ne vas pas vite: Un FSCK détruit les données.
... @%$@... je savais bien qu'il fallait que je touche à mes fesses !!!
j'ai d'abord fait :
kholo@monde:~$ sudo mdadm --assemble --verbose /dev/md69 --level=raid5 --raid-devices=4 /dev/sda /dev/sdb /dev/sdc /dev/sdd
[sudo] Mot de passe de su :
mdadm: :option --level not valid in assemble mode
puis au cas où :
sudo mv /etc/mdadm.conf /etc/mdadm.conf.old
reboot
puis recommencé et j'ai la même chose...
Hors ligne
#4 Le 29/07/2021, à 16:01
- geole
Re : raid 5 : perte données après create... récupération possible ?
Prépare-toi un jeu d'essai de 4 partitions de 1 Go sur le disque SDE puis simule les tests
Les grilles de l'installateur https://doc.ubuntu-fr.org/tutoriel/inst … _subiquity
"gedit admin:///etc/fstab" est proscrit, utilisez "pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY xdg-open /etc/fstab" Voir https://doc.ubuntu-fr.org/gedit
Les partitions EXT4 des disques externes => https://forum.ubuntu-fr.org/viewtopic.p … #p22697248
Hors ligne
#5 Le 29/07/2021, à 16:06
- kholo
Re : raid 5 : perte données après create... récupération possible ?
j'ai ça :
kholo@monde:~$ cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4] [linear] [multipath] [raid0] [raid1] [raid10]
md127 : active (auto-read-only) raid5 sdc[2] sdd[4] sda[0] sdb[1]
1464763392 blocks super 1.2 level 5, 512k chunk, algorithm 2 [4/4] [UUUU]
bitmap: 0/4 pages [0KB], 65536KB chunk
unused devices: <none>
Hors ligne
#6 Le 29/07/2021, à 16:07
- kholo
Re : raid 5 : perte données après create... récupération possible ?
Prépare-toi un jeu d'essai de 4 partitions de 1 Go sur le disque SDE puis simule les tests
ok !
Hors ligne
#7 Le 29/07/2021, à 16:36
- kholo
Re : raid 5 : perte données après create... récupération possible ?
j'ai un autre serveur avec le même type de config et également en 16.04 et qui a la même config de disque...
celui là, je peux le buriner...
je le passe en 20.04 de la même façon que le premier
et je recommence mon voire mes erreurs et je pourrai essayer !
si tu veux voir avec des fichiers à sauvegarder avant de refaire mes bêtises je peux le faire
comme mdadm.conf par exemple
merci de ton aide !!
Hors ligne
#8 Le 29/07/2021, à 16:36
- geole
Re : raid 5 : perte données après create... récupération possible ?
Je te confirme que si tu formates, tu perds le contenu.
Souvent, on conseille de dupliquer les quatre disques avant de faire des tentatives de remise en état
Les grilles de l'installateur https://doc.ubuntu-fr.org/tutoriel/inst … _subiquity
"gedit admin:///etc/fstab" est proscrit, utilisez "pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY xdg-open /etc/fstab" Voir https://doc.ubuntu-fr.org/gedit
Les partitions EXT4 des disques externes => https://forum.ubuntu-fr.org/viewtopic.p … #p22697248
Hors ligne
#9 Le 29/07/2021, à 16:42
- kholo
Re : raid 5 : perte données après create... récupération possible ?
merci oui...
j'ai beaucoup de petits fichiers sur ces disques et certainement des backup de presque toutes mes données sur d'autres disques durs que j'avais justement conservé au cas où..
je me suis lancé dans le raid autant pour la fiabilité que pour apprendre mais j'ai bien anticipé que je pourrais peut être avoir ce genre de problème...
donc pas de soucis...
quand je passerai sur l'original, ce sera après avoir validé une procédure qui tient la route !
Hors ligne
#10 Le 29/07/2021, à 17:06
- kholo
Re : raid 5 : perte données après create... récupération possible ?
voilà... passé en 20.04...
je suis en train de terminer la mise à jour...
mon Lamp a dégagé mais ça je m'y attendais...
la màj ne devrait plus être longue...
je me met ssh pour y avoir accès depuis mon portable (mais j'ai un écran, clavier et souris dessus aussi) et je serai dans la situation avant ma bêtise...
quand tu me donneras le feu vert, je pourrai lancer les LDC telle que tu me les enverras !
on peut même tenter des trucs si tu veux...
le tuto que j'ai lu ce matin m'a pas mal éclairé sur les façons de faire en cas de pépin !!
une fois ssh installé, je te met les infos du bouzin... mais il ressemble beaucoup à celui que j'ai cassé :
dual core (celui de test est core 2, l'autre est un Xeon)... les 2 en HP
4 hdd de 500 Go sda sdb sdc et sdd
1 hdd de 250 Go en sde
avec le système dessus : / en sde1, + une partition étendue avec home en sde5, swap en sde6
l'installation de mdadm et le paramétrage a été fait sous 16.04 de la même façon que l'autre !
donc ce sera presque une copie de mon serveur principal...
c'est là que je me dis que j'ai tout fait à l'envers... j'aurais du commencer par celui là...
encore que j'ai fait la même sur un autre upgradé en 18.04 et c'est passé tout seul...
bref !
je te (vous) tiens au courant
Hors ligne
#11 Le 29/07/2021, à 17:14
- geole
Re : raid 5 : perte données après create... récupération possible ?
Je pense qu'il y a un autre problème de caché.
J'ai créé MD0 en 20.04 et l'ai populé avec le répertire home puis stoppé.
Je fabrique MD1 puis j'accède aux anciennes données sans problème. Exemple
a@a:~$ sudo mdadm --create /dev/md1 --level=5 --raid-devices=4 /dev/sda13 /dev/sda14 /dev/sda19 /dev/sda21
mdadm: /dev/sda13 appears to contain an ext2fs file system
size=1048576K mtime=Thu Jan 1 01:00:00 1970
mdadm: /dev/sda13 appears to be part of a raid array:
level=raid5 devices=4 ctime=Thu Jul 29 17:45:36 2021
mdadm: /dev/sda14 appears to contain an ext2fs file system
size=1048576K mtime=Thu Jan 1 01:00:00 1970
mdadm: /dev/sda14 appears to be part of a raid array:
level=raid5 devices=4 ctime=Thu Jul 29 17:45:36 2021
mdadm: /dev/sda19 appears to contain an ext2fs file system
size=1048576K mtime=Thu Jan 1 01:00:00 1970
mdadm: /dev/sda19 appears to be part of a raid array:
level=raid5 devices=4 ctime=Thu Jul 29 17:45:36 2021
mdadm: /dev/sda21 appears to contain an ext2fs file system
size=1048576K mtime=Thu Jan 1 01:00:00 1970
mdadm: /dev/sda21 appears to be part of a raid array:
level=raid5 devices=4 ctime=Thu Jul 29 17:45:36 2021
Continue creating array? y
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started.
a@a:~$ sudo mount /dev/md1 /media/RAID
a@a:~$ ls -als /media/RAID
total 28
4 drwxr-xr-x 4 root root 4096 juil. 29 17:43 .
4 drwxr-xr-x 3 root root 4096 juil. 29 17:41 ..
4 drwxr-xr-x 3 root root 4096 juil. 29 17:43 home
16 drwx------ 2 root root 16384 juil. 29 17:33 lost+found
a@a:~$
Dernière modification par geole (Le 29/07/2021, à 17:15)
Les grilles de l'installateur https://doc.ubuntu-fr.org/tutoriel/inst … _subiquity
"gedit admin:///etc/fstab" est proscrit, utilisez "pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY xdg-open /etc/fstab" Voir https://doc.ubuntu-fr.org/gedit
Les partitions EXT4 des disques externes => https://forum.ubuntu-fr.org/viewtopic.p … #p22697248
Hors ligne
#12 Le 29/07/2021, à 17:29
- kholo
Re : raid 5 : perte données après create... récupération possible ?
oui... en effet...
peut être ce que j'ai fait...
un history... désolé c'est un peu le bordel mais tu devrais t'y retrouver...
608 sudo apt install gawk inxi mdadm
609 sudo mdadm --create --verbose /dev/md0 --level=raid5 --raid-devices=4 /dev/sda /dev/sdb /dev/sdc /dev/sdd
610 sudo /dev/md0 /mnt/raid1
611 sudo mdadm --create --verbose /dev/md0 --level=raid5 --raid-devices=4 /dev/sda /dev/sdb /dev/sdc /dev/sdd
612 sudo mdadm --detail --scan | sudo tee /etc/mdadm.conf
613 sudo mount /dev/md0 /mnt/raid1
614 ls /mnt
615 ls /mnt/raid1/
616 sudo blkid
617 cat /etc/fstab
618 cat /proc/mdstat
619 fdisk -l
620 sudo fdisk -l
621 fsck.ext4 /dev/md1
622 fsck.ext4 /dev/md0
623 sudo fsck.ext4 /dev/md0
624 sudo mount /dev/md0 /mnt/raid1/
625 sudo mdadm --detail /dev/md0
626 ls /media
627 ls /mnt
628 htop
629 sudo apt install htop
630 htop
ensuite c'est ce que tu m'as demandé...
631 sudo mdadm --assemble --verbose /dev/md69 --level=raid5 --raid-devices=4 /dev/sda /dev/sdb /dev/sdc /dev/sdd
632 sudo mv /etc/mdadm.conf /etc/mdadm.conf.old
633 sudo reboot
634 sudo mdadm --assemble --verbose /dev/md69 --level=raid5 --raid-devices=4 /dev/sda /dev/sdb /dev/sdc /dev/sdd
635 ls /etc/mdadm.conf
636 ls /etc/mdadm*
637 mdadm --examine --scan
638 sudo mdadm --assemble --verbose /dev/md69 --level=5 --raid-devices=4 /dev/sda /dev/sdb /dev/sdc /dev/sdd
639 cat /proc/mdstat
640 sudo poweroff
641 history
j'ai aussi vu passer une erreur sur un des disque dur au détour d'un check...
dans le #1 à l'édit de 14h17:
kholo@monde:~$ sudo fdisk -l
...
Disque /dev/sdc : 465,78 GiB, 500107862016 octets, 976773168 secteurs
Disk model: WDC WD5000AUDX-7
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 4096 octets
taille d'E/S (minimale / optimale) : 4096 octets / 4096 octets
La table de partitions GPT primaire est corrompue, mais la sauvegarde semble fonctionnelle, elle sera donc utilisée.
Disque /dev/sdd : 465,78 GiB, 500107862016 octets, 976773168 secteurs
Disk model: ST500DM002-1BD14
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 4096 octets
taille d'E/S (minimale / optimale) : 4096 octets / 4096 octets
Type d'étiquette de disque : gpt
Identifiant de disque : 17DAD5C4-A03E-43E9-AC98-5BCBBF6792AF
...
c'est bon... ma machine de test est terminée !
juste passée en 20.04 et Màj
j'installe juste ce qu'il me faut et je suis à tes ordres !!!
Hors ligne
#13 Le 29/07/2021, à 17:30
- geole
Re : raid 5 : perte données après create... récupération possible ?
Une proposition: Libère 16 Go sur le disque SDE et installe la version 16.04 ( Elle est encore maintenue) puis mdadm et au boot suivant regarde si md127 n'est pas automatiquement créé.
a@a:~$ sudo mdadm --create /dev/md69 --level=5 --raid-devices=4 /dev/sda13 /dev/sda14 /dev/sda19 /dev/sda21
mdadm: cannot open /dev/sda13: Device or resource busy
a@a:~$ lsblk -fe7
NAME FSTYPE LABEL UUID MOUNTPOINT
sr0
sda
├─sda4 ntfs Windows10SIMPLE 6CB8862A7B84D3A0
├─sda16 ntfs Commun1 007A992054C5D589
├─sda2 vfat FAT32ESP A3C1-2EA7 /boot/efi
├─sda14 linux_raid_member a:1 e5a28409-183b-7584-80ca-d79563df16f3
│ └─md127 ext4 54ddb097-0c2b-49ec-ac60-64df0c317471
├─sda12 LVM2_member T3jVJu-0kF8-NpWK-Rlnq-6PgJ-BBPx-FI1BrU
│ └─Geole--vg-Data ext4 117580eb-9394-4eaf-82f0-7688c62c4e67
├─sda9 crypto_LUKS 16f1cc0a-2cc5-4ed6-893d-f233cf283821
├─sda20 ext4 U2004-2 18b28382-0ec9-4bea-a0b3-24729bd90810
├─sda10 ext4 Boot18.04-1SECUR 3e767c74-4bbd-4279-896a-182a079d8db0
├─sda7 ext2 U21.04-EXT2 ef9c27ce-366f-425b-a698-50e13590e013
├─sda19 linux_raid_member a:1 e5a28409-183b-7584-80ca-d79563df16f3
│ └─md127 ext4 54ddb097-0c2b-49ec-ac60-64df0c317471
├─sda5 ntfs WindowsRE 94662D96662D79DE
├─sda17 ext4 U20.04.2 96d31832-a414-4282-a76f-630e5d66c7c1
├─sda3 vfat W10-COMPLET 74C3-06ED
├─sda15 ntfs Windows10COMPLET A606949C06946ED5
├─sda1
├─sda13 linux_raid_member a:1 e5a28409-183b-7584-80ca-d79563df16f3
│ └─md127 ext4 54ddb097-0c2b-49ec-ac60-64df0c317471
├─sda21 linux_raid_member a:1 e5a28409-183b-7584-80ca-d79563df16f3
│ └─md127 ext4 54ddb097-0c2b-49ec-ac60-64df0c317471
├─sda11 ext4 U18041 cb50473a-5d9c-441a-9502-690c1c8684d6
├─sda8 ext4 HOME 03a46224-eb03-41ae-83e3-43453db97f80
├─sda6 ext4 U16.04.5 c0c68bb1-cd2a-4f04-adec-558973da267c /
└─sda18 ext4 U18.10 3e9adae1-accd-46f8-b346-767fa906b605
a@a:~$ cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=16.04
DISTRIB_CODENAME=xenial
DISTRIB_DESCRIPTION="Ubuntu 16.04.7 LTS"
a@a:~$
Dernière modification par geole (Le 29/07/2021, à 17:36)
Les grilles de l'installateur https://doc.ubuntu-fr.org/tutoriel/inst … _subiquity
"gedit admin:///etc/fstab" est proscrit, utilisez "pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY xdg-open /etc/fstab" Voir https://doc.ubuntu-fr.org/gedit
Les partitions EXT4 des disques externes => https://forum.ubuntu-fr.org/viewtopic.p … #p22697248
Hors ligne
#14 Le 29/07/2021, à 17:38
- kholo
Re : raid 5 : perte données après create... récupération possible ?
Une proposition: Libère 16 Go sur le disque SDE et installe la version 16.04 puis mdadm et au boot suivant regarde si md127 n'est pas automatiquement créé.
ok... je met un hdd (j'en ai plein en stock !!) et je lui colle 16.04 dessus... ça risque de me prendre encore un peu de temps
Hors ligne
#15 Le 29/07/2021, à 18:22
- kholo
Re : raid 5 : perte données après create... récupération possible ?
voilà... je suis donc sur ma machine principale
j'avais un disque de 250Go avec une 16.04...
ça fait drôle de retrouver docky !!!
wifi... mises à jour... install de mdadm, reboot...
su@htpc:~$ cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=16.04
DISTRIB_CODENAME=xenial
DISTRIB_DESCRIPTION="Ubuntu 16.04.7 LTS"
su@htpc:~$ uname -a
Linux htpc 4.4.0-210-generic #242-Ubuntu SMP Fri Apr 16 09:57:56 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
su@htpc:~$ mdadm --version
mdadm - v3.3 - 3rd September 2013
j'ouvre bêtement gnome disks...
là j'ai mon /dev/md/0 de 1.5 To...
su@htpc:~$ sudo mdadm --detail /dev/md0
[sudo] Mot de passe de su :
/dev/md0:
Version : 1.2
Creation Time : Thu Jul 29 11:07:34 2021
Raid Level : raid5
Array Size : 1464763392 (1396.91 GiB 1499.92 GB)
Used Dev Size : 488254464 (465.64 GiB 499.97 GB)
Raid Devices : 4
Total Devices : 4
Persistence : Superblock is persistent
Intent Bitmap : Internal
Update Time : Thu Jul 29 13:59:26 2021
State : clean
Active Devices : 4
Working Devices : 4
Failed Devices : 0
Spare Devices : 0
Layout : left-symmetric
Chunk Size : 512K
Name : monde:0
UUID : ddcbf221:4e72bb6d:e317e5a0:2e94376d
Events : 1985
Number Major Minor RaidDevice State
0 8 0 0 active sync /dev/sda
1 8 16 1 active sync /dev/sdb
2 8 32 2 active sync /dev/sdc
4 8 48 3 active sync /dev/sdd
et...
su@htpc:~$ lsblk -fe7
NAME FSTYPE LABEL UUID MOUNTPOINT
sda linux_raid_member monde:0 ddcbf221-4e72-bb6d-e317-e5a02e94376d
└─md0
sdb linux_raid_member monde:0 ddcbf221-4e72-bb6d-e317-e5a02e94376d
└─md0
sdc linux_raid_member monde:0 ddcbf221-4e72-bb6d-e317-e5a02e94376d
└─md0
sdd linux_raid_member monde:0 ddcbf221-4e72-bb6d-e317-e5a02e94376d
└─md0
sde
├─sde1 ext4 ubuntu 791fa7ca-0439-4c19-8040-3d0e79c794b0 /
├─sde2 swap b3e62abe-4016-4cd0-9da9-c9e82d89c0d5 [SWAP]
└─sde3 ext4 home 33412f18-451a-4472-a2ed-545c6ee4bbf7 /home
sr0
Hors ligne
#16 Le 29/07/2021, à 18:37
- geole
Re : raid 5 : perte données après create... récupération possible ?
Bonne surprise,
C'est le moment de sauver logiquement son contenu si du moins c'est lisible
NOTA
Je n'ai pas réussi à reproduire ton contexte
Le raid fabriqué en 16.04 est automatiquement monté en 20.04. donc ma commande de création est refusée car les ressources sont occupées....
De plus, je ne comprends pas pourquoi cela parle de NTFS
su@monde:~$ sudo mount /dev/md0 /mnt/raid1
NTFS signature is missing.
Failed to mount '/dev/md0': Argument invalide
The device '/dev/md0' doesn't seem to have a valid NTFS.
Maybe the wrong device is used? Or the whole disk instead of a
partition (e.g. /dev/sda, not /dev/sda1)? Or the other way around?
Dernière modification par geole (Le 29/07/2021, à 18:54)
Les grilles de l'installateur https://doc.ubuntu-fr.org/tutoriel/inst … _subiquity
"gedit admin:///etc/fstab" est proscrit, utilisez "pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY xdg-open /etc/fstab" Voir https://doc.ubuntu-fr.org/gedit
Les partitions EXT4 des disques externes => https://forum.ubuntu-fr.org/viewtopic.p … #p22697248
Hors ligne
#17 Le 29/07/2021, à 18:51
- kholo
Re : raid 5 : perte données après create... récupération possible ?
il faut dire que j'ai ait un create mais jamais je n'ai fait de FS...
je me disais cela quand j'ai pensé à testdisk...
mis quand je lance testdisk et que je vais sur md0 il me demande de quelle table de partition il s'agit...
et là je sèche...
Hors ligne
#18 Le 29/07/2021, à 19:21
- kholo
Re : raid 5 : perte données après create... récupération possible ?
j'ai toujours un disque corrompu
su@htpc:/etc/mdadm$ sudo parted -l
Erreur: Impossible d'ouvrir /dev/sda - étiquette de disque non reconnue.
Modèle: ATA WDC WD5003ABYX-1 (scsi)
Disque /dev/sda : 500GB
Taille des secteurs (logiques/physiques): 512B/512B
Table de partitions : unknown
Disk Flags:
Erreur: Impossible d'ouvrir /dev/sdb - étiquette de disque non reconnue.
Modèle: ATA ST500DM002-1BD14 (scsi)
Disque /dev/sdb : 500GB
Taille des secteurs (logiques/physiques): 512B/4096B
Table de partitions : unknown
Disk Flags:
Erreur: Impossible d'ouvrir /dev/sdc - étiquette de disque non reconnue.
Modèle: ATA WDC WD5000AUDX-7 (scsi)
Disque /dev/sdc : 500GB
Taille des secteurs (logiques/physiques): 512B/4096B
Table de partitions : unknown
Disk Flags:
Erreur: La table primaire GPT est corrompue mais sa sauvegarde semble valide,
elle sera donc utilisée.
OK/Annuler/Cancel? C
Modèle: ATA ST500DM002-1BD14 (scsi)
Disque /dev/sdd : 500GB
Taille des secteurs (logiques/physiques): 512B/4096B
Table de partitions : unknown
Disk Flags:
Modèle: ATA ST3250312AS (scsi)
Disque /dev/sde : 250GB
Taille des secteurs (logiques/physiques): 512B/512B
Table de partitions : gpt
Disk Flags:
Numéro Début Fin Taille Système de fichiers Nom Fanions
1 17,4kB 52,4GB 52,4GB ext4 ubuntu
2 52,4GB 60,8GB 8390MB linux-swap(v1) swap
3 60,8GB 250GB 189GB ext4 home
Erreur: Impossible d'ouvrir /dev/md0 - étiquette de disque non reconnue.
Modèle: Grappe RAID logiciel Linux (md)
Disque /dev/md0 : 1500GB
Taille des secteurs (logiques/physiques): 512B/4096B
Table de partitions : unknown
Disk Flags:
pause, le temps de souffler et grignoter...
bonne appétit si ce n'est pas encore fait !
et merci encore pour le suivi...
Dernière modification par kholo (Le 29/07/2021, à 19:27)
Hors ligne
#19 Le 29/07/2021, à 20:32
- geole
Re : raid 5 : perte données après create... récupération possible ?
Oublie ces messages
Table de partitions : unknown
puisque tu as décidé d'installer directement sur la totalité du disque pour ne pas gaspiller 1 Mo d'espace.
Je ne comprends pas pourquoi tu évoques testdisk
Dernière modification par geole (Le 29/07/2021, à 20:34)
Les grilles de l'installateur https://doc.ubuntu-fr.org/tutoriel/inst … _subiquity
"gedit admin:///etc/fstab" est proscrit, utilisez "pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY xdg-open /etc/fstab" Voir https://doc.ubuntu-fr.org/gedit
Les partitions EXT4 des disques externes => https://forum.ubuntu-fr.org/viewtopic.p … #p22697248
Hors ligne
#20 Le 29/07/2021, à 20:45
- kholo
Re : raid 5 : perte données après create... récupération possible ?
en fait, je ne sais pas trop ce que le create a fait...
j'ai pensé naïvement au tout début qu'il suffirait de reprendre la ligne de création
mais de ne pas créer de FS pour retrouver ma partition ext créé au départ.
mais dès le montage, ne trouvant pas de FS j'ai herché et me suis rendu compte de mon erreur...
donc un testdisk me semblait une bonne idée pour rechercher une partition ext4...
Hors ligne
#21 Le 29/07/2021, à 21:05
- geole
Re : raid 5 : perte données après create... récupération possible ?
il me semble que testdisk propose un choix "sans table de partition".
( je suis actuellement sur ipad)
Mais sous 16.04, peux-tu monter normalement ton raids et y accéder?
Dernière modification par geole (Le 29/07/2021, à 21:07)
Les grilles de l'installateur https://doc.ubuntu-fr.org/tutoriel/inst … _subiquity
"gedit admin:///etc/fstab" est proscrit, utilisez "pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY xdg-open /etc/fstab" Voir https://doc.ubuntu-fr.org/gedit
Les partitions EXT4 des disques externes => https://forum.ubuntu-fr.org/viewtopic.p … #p22697248
Hors ligne
#22 Le 29/07/2021, à 21:12
- kholo
Re : raid 5 : perte données après create... récupération possible ?
non toujours pas de montage possible...
en tout cas pas avant le testdisk...
j'ai le retour du testdisk qui ne semble pas concluant...
TestDisk 7.0, Data Recovery Utility, April 2015
Christophe GRENIER <grenier@cgsecurity.org>
http://www.cgsecurity.org
Disk /dev/md0 - 1499 GB / 1396 GiB - CHS 366190848 2 4
The harddisk (1499 GB / 1396 GiB) seems too small! (< 35 TB / 32 TiB)
Check the harddisk size: HD jumpers settings, BIOS detection...
The following partitions can't be recovered:
Partition Start End Size in sectors
> Linux Swap 676735 0 1 492540 1 4 68718003184
FAT32 LBA 148233479 1 2 368879457 1 3 1765167826
FAT16 >32M 349021032 1 4 593011819 1 2 1951926295
FAT12 388624397 1 4 676053727 0 3 2299434636
FAT16 <32M 446351198 0 2 896846382 0 1 3603961472
FAT32 LBA 470019178 0 3 950335803 1 3 3842533005
FAT16 <32M 519197550 1 1 743454233 1 3 1794053467
FAT16 LBA 530325002 1 2 950087875 0 2 3358102981
FAT12 534772139 1 1 809161081 1 1 2195111537
FAT16 <32M 535918225 0 2 582403002 0 4 371878219
[ Continue ]
SWAP2 version 3343413484, pagesize=8192, 35 TB / 31 TiB
puis
TestDisk 7.0, Data Recovery Utility, April 2015
Christophe GRENIER <grenier@cgsecurity.org>
http://www.cgsecurity.org
Disk /dev/md0 - 1499 GB / 1396 GiB - CHS 366190848 2 4
Partition Start End Size in sectors
* Linux Swap 676736 0 1 1653885 1 4 7817200
D FAT32 302519417 0 3 317930150 1 1 123285867
D Linux 317066112 0 1 322479743 1 4 43309056
P FAT12 328693396 1 1 328693980 1 4 4676 [NO NAME]
P FAT12 329315479 0 1 329324950 1 4 75776 [MGAEFI]
L FAT12 343905960 1 1 343906552 1 4 4740 [NO NAME]
L FAT12 348427779 1 1 348428045 1 4 2132
L HPFS - NTFS 354595840 0 1 354811135 1 4 1722368
L HPFS - NTFS 355231995 0 1 355232766 1 4 6176
L HPFS - NTFS 355241472 0 1 358891263 1 4 29198336
L HPFS - NTFS 360991330 0 1 360992101 1 4 6176
L Linux Swap 363145727 0 1 363145728 1 4 16
L Linux Swap 363145855 0 1 363145856 1 4 16
>L FAT12 364278376 0 1 364278735 1 4 2880 [EFISECTOR]
Structure: Ok. Use Up/Down Arrow keys to select partition.
Use Left/Right Arrow keys to CHANGE partition characteristics:
*=Primary bootable P=Primary L=Logical E=Extended D=Deleted
Keys A: add partition, L: load backup, T: change type, P: list files,
Enter: to continue
FAT12, blocksize=512, 1474 KB / 1440 KiB
je ne pense pas que cela soit ce que je cherche
pour aller plus loin dans mon raisonnement précédent...
j'ai ce qui semble être la traduction de la page que je lisais ce matin
root@test:~# umount /mnt/raid5 root@test:~# mdadm --stop /dev/md0 mdadm: stopped /dev/md0 root@test:~# cat /proc/mdstat Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10] unused devices: <none> root@test:~# mdadm --create /dev/md1 --chunk=512 --level=5 --raid-devices=3 /dev/sdb1 /dev/sdc1 /dev/sdd1 mdadm: /dev/sdb1 appears to be part of a raid array: level=raid5 devices=3 ctime=Sat Jan 7 21:07:06 2012 mdadm: /dev/sdc1 appears to be part of a raid array: level=raid5 devices=3 ctime=Sat Jan 7 21:07:06 2012 mdadm: /dev/sdd1 appears to be part of a raid array: level=raid5 devices=3 ctime=Sat Jan 7 21:07:06 2012 Continue creating array? y mdadm: Defaulting to version 1.2 metadata mdadm: array /dev/md1 started. root@test:~# cat /proc/mdstat Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10] md1 : active raid5 sdd1[2] sdc1[1] sdb1[0] 203776 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3] [UUU] unused devices: <none>
La resynchronisation s'est terminée très rapidement avec ces minuscules disques, mais cela s'est produit. Alors voici ce qui m'ennuyait de plus tôt; votre fdisk -lsortie. N'avoir aucune table de partition sur le mdpériphérique n'est pas un problème du tout, c'est prévu. Votre système de fichiers réside directement sur le faux périphérique de bloc sans table de partition.
root@test:~# fdisk -l ... Disk /dev/md1: 208 MB, 208666624 bytes 2 heads, 4 sectors/track, 50944 cylinders, total 407552 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 524288 bytes / 1048576 bytes Disk identifier: 0x00000000 Disk /dev/md1 doesn't contain a valid partition table
Oui, pas de table de partition. Mais...
root@test:~# fsck.ext4 /dev/md1 e2fsck 1.41.14 (22-Dec-2010) /dev/md1: clean, 12/51000 files, 12085/203776 blocks
Système de fichiers parfaitement valide, après une resynchronisation. Donc c'est bien; vérifions nos fichiers de données:
root@test:~# mount /dev/md1 /mnt/raid5/ root@test:~# cat /mnt/raid5/datafile data root@test:~# sha1sum /mnt/raid5/randomdata 847685a5d42524e5b1d5484452a649e854b59064 /mnt/raid5/randomdata
alors, j'avoue que ce qui me fait le plus flipper est de faire un
fsck.ext4 /dev/md1
enfin md0 dans mon cas...
Hors ligne
#23 Le 29/07/2021, à 21:18
- kholo
Re : raid 5 : perte données après create... récupération possible ?
... je reprends au début...
quand j'ai fait ça, que s'est il passé ?
kholo@monde:~$ sudo mdadm --create --verbose /dev/md0 --level=raid5 --raid-devices=4 /dev/sda /dev/sdb /dev/sdc /dev/sdd
mdadm: layout defaults to left-symmetric
mdadm: layout defaults to left-symmetric
mdadm: chunk size defaults to 512K
mdadm: /dev/sda appears to be part of a raid array:
level=raid5 devices=4 ctime=Wed Mar 18 15:10:26 2020
mdadm: /dev/sdb appears to be part of a raid array:
level=raid5 devices=4 ctime=Wed Mar 18 15:10:26 2020
mdadm: /dev/sdc appears to be part of a raid array:
level=raid5 devices=4 ctime=Wed Mar 18 15:10:26 2020
mdadm: /dev/sdd appears to be part of a raid array:
level=raid5 devices=4 ctime=Wed Mar 18 15:10:26 2020
mdadm: partition table exists on /dev/sdd but will be lost or
meaningless after creating array
mdadm: size set to 488254464K
mdadm: automatically enabling write-intent bitmap on large array
Continue creating array? yes
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md0 started.
Hors ligne
#24 Le 29/07/2021, à 21:35
- kholo
Re : raid 5 : perte données après create... récupération possible ?
si je stop md0 et refais un create, est ce que cela va empirer les choses ?
par exemple effacer un backup qui pourrait exister...
... et existe t'il un backup de l'entete de la partition ext4 qui se trouvait sur ma grappe...
ou le create a t'il casser plus profond encore ?
le fsck.ext4 que j'ai fait à t'il empirer les choses ?
Hors ligne
#25 Le 29/07/2021, à 21:49
- kholo
Re : raid 5 : perte données après create... récupération possible ?
... j'en suis là...
sous 16.04 à jour...
su@htpc:/etc/mdadm$ sudo mount /dev/md0 /mnt/raid1
[sudo] Mot de passe de su :
mount: wrong fs type, bad option, bad superblock on /dev/md0,
missing codepage or helper program, or other error
Dans certains cas des renseignements utiles sont dans le journal
système — essayez « dmesg | tail » ou quelque chose du genre.
su@htpc:/etc/mdadm$ cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4] [linear] [multipath] [raid0] [raid1] [raid10]
md0 : active raid5 sdd[4] sdc[2] sdb[1] sda[0]
1464763392 blocks super 1.2 level 5, 512k chunk, algorithm 2 [4/4] [UUUU]
bitmap: 0/4 pages [0KB], 65536KB chunk
unused devices: <none>
su@htpc:/etc/mdadm$ sudo fdisk -l
Disque /dev/sda : 465,8 GiB, 500107862016 octets, 976773168 secteurs
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d'E/S (minimale / optimale) : 512 octets / 512 octets
Disque /dev/sdc : 465,8 GiB, 500107862016 octets, 976773168 secteurs
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 4096 octets
taille d'E/S (minimale / optimale) : 4096 octets / 4096 octets
Disque /dev/sde : 232,9 GiB, 250059350016 octets, 488397168 secteurs
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d'E/S (minimale / optimale) : 512 octets / 512 octets
Type d'étiquette de disque : gpt
Identifiant de disque : 841F2D86-6231-4E89-A370-C42B04BC5F50
Périphérique Début Fin Secteurs Taille Type
/dev/sde1 34 102398309 102398276 48,8G Système de fichiers Linux
/dev/sde2 102398310 118784609 16386300 7,8G Partition d'échange Linux
/dev/sde3 118784610 488392064 369607455 176,2G Système de fichiers Linux
Disque /dev/sdb : 465,8 GiB, 500107862016 octets, 976773168 secteurs
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 4096 octets
taille d'E/S (minimale / optimale) : 4096 octets / 4096 octets
La table de partitions GPT primaire est corrompue, mais la sauvegarde semble fonctionnelle, elle sera donc utilisée.
Disque /dev/sdd : 465,8 GiB, 500107862016 octets, 976773168 secteurs
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 4096 octets
taille d'E/S (minimale / optimale) : 4096 octets / 4096 octets
Type d'étiquette de disque : gpt
Identifiant de disque : 17DAD5C4-A03E-43E9-AC98-5BCBBF6792AF
Disque /dev/md0 : 1,4 TiB, 1499917713408 octets, 2929526784 secteurs
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 4096 octets
taille d'E/S (minimale / optimale) : 524288 octets / 1572864 octets
Hors ligne