Contenu | Rechercher | Menus

Annonce

Si vous avez des soucis pour rester connecté, déconnectez-vous puis reconnectez-vous depuis ce lien en cochant la case
Me connecter automatiquement lors de mes prochaines visites.

À propos de l'équipe du forum.

#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 !! roll
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 smile




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

Geole a écrit :

Ne vas  pas vite: Un FSCK  détruit les données.

... @%$@... je savais bien qu'il fallait que je touche à mes fesses !!! roll

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 ?

geole a écrit :

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 !!! cool

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 ?

Geole a écrit :

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 wink

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

la page a écrit :
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