Raid: Unterschied zwischen den Versionen

Aus Store2 Wiki
Zur Navigation springen Zur Suche springen
Zeile 241: Zeile 241:
nachh dd_rescue evtl. Reparaturversuch mit '''SpinRite'''
nachh dd_rescue evtl. Reparaturversuch mit '''SpinRite'''
  /dev/sda -> 28  : 1SWX1JSL0C0615 (1.5T) bzw. Serial S1XWJ1LSC06051  
  /dev/sda -> 28  : 1SWX1JSL0C0615 (1.5T) bzw. Serial S1XWJ1LSC06051  
kommt auf
/dev/sdv ->




Zeile 257: Zeile 259:
Superblock für mdadm auf sdj vorhanden, NICHT auf sdj1
Superblock für mdadm auf sdj vorhanden, NICHT auf sdj1
  /dev/sdj -> 25 : 1SWX1JSL0C9558 (1.5T)
  /dev/sdj -> 25 : 1SWX1JSL0C9558 (1.5T)
kommt auf
/dev/sdw ->

Version vom 16. März 2010, 14:49 Uhr

Raid-Status

mdadm --detail /dev/md127

Raid-Baustatus

cat /proc/mdstat

Raidgröße

1000000000000

als ext3


auch als ext3

Raid Baubefehl

mdadm --create /dev/md127 --level=raid6 --raid-devices=5 /dev/sdb1 /dev/sdc1 /dev/sdd1 /dev/sde1 /dev/sdf1 
mdadm --create /dev/md127 --chunk=64 --level=raid6 --layout=ls --raid-devices=5 /dev/sdb1 /dev/sdc1 /dev/sdd1 /dev/sde1 /dev/sdf1 

Verschlüssel von Hand (ohne Yast2)

Verschlüsseln:

cryptsetup -v --key-size 256 luksFormat /dev/md127 

Öffnen:

cryptsetup luksOpen /dev/md127 cr_md127 

Filesystem drauf:

mkfs.reiserfs /dev/mapper/cr_md127 

Status:

cryptsetup luksDump /dev/md127

Grown

yast2, neue Primärpartition mit Größe : 1000000000000 als Linux RAID, nicht formatieren oder einhängen
mdadm --add /dev/md127 /dev/sdg1
mdadm --grow --raid-devices=6 /dev/md127 --backup-file=/home/gagi/mda127backup

um zu sehen, wer/was gerade Zugriff nimmt:

lsof /data 

Unmounten:

umount /data 

Filesystem überprüfen:

reiserfsck --check /dev/mapper/cr_md127 

(Falls nötig, mit dm_crypt öffnen:)

(cryptsetup luksOpen /dev/md127 cr_md127)
(schließen übrigens mit cryptsetup luksClose)

Verschlüsselten Container wachsen:

cryptsetup --verbose resize cr_md127

Reiser-Filesystem wachsen:

resize_reiserfs /dev/mapper/cr_md127

Filesystem überprüfen:

reiserfsck --check /dev/mapper/cr_md127

Mounten:

mount /dev/mapper/cr_md127 /data

Read-Only Mounten:

mount -o ro /dev/mapper/cr_md127 /data

Mounten über Samba

mount //192.168.0.1/alte_Q /mnt

RAID6 aufblasen auf 1,5TB

Software-Raid-Dienst unster OpenSuse starten:

/etc/init.d/boot.md start 

0. UUID kaputt machen und Partitionstabelle zerstören für 1TB Platteninhalt dd-t auf 1,5TB Platte

dd if=/dev/zero bs=1024 count=2000 of=/dev/sdi

1. Farbikneue Festplatten über MB-SATA-Anschluss in Opensuse mit Partition (komplette Platte) und Filesystem (RAID) versehen

Dann für jede Platte sukzessive:

2. Platte failed setzen und aus Raidverbund rausnehmen:

 mdadm --set-faulty /dev/md127 /dev/sdo1
 mdadm --remove /dev/md127 /dev/sdo1

3. Plattenpartition maximiert (komplette Platte) mit Yast2 -> Partitioner neu anlegen (formatieren nicht nötig) -> Dieser Schritt DOCH nötig! -> Legacy

4. Wieder ins Raid reinnehmen

 mdadm --add /dev/md127 /dev/sdo
 

5. Bauen lassen

6. Nächste Platte

7. Wenn die 5 1TB-Platten "befreit" sind, aus denen ein neues Raid5 aufsetzen (siehe Anleitung) und darauf das alte Raid5 verschieben.

8. Wenn alle 14 1,5TB Platten im Raid6 sind, dann das Raid6 grown lassen

mdadm --grow /dev/md127 --size=max

9. Unmounten, Filesystem-Check, Cryptcontainer wachsen, ReiserFS wachsen (wie sonst auch, siehe oben).

RAID Layout mit Serials

01  : 1SWX1JSK292519 (1.5T)
02  : 1S6Y1JSK175967 (1.5T)
03  : 1S6Y1JSK175957 (1.5T)
04  : WD-WCAU40406122 (1.0T)
05  : 9VS0CVSE (1.5T)
06  : WD-WCAU40497763 (1.0T)
07  : 1SWX1JSK292509 (1.5T) 

08  : 9VS0CTFS (1.5T)
09  : 9VS0CWXA (1.5T)
10  : 9VS0HDNS (1.5T)
11  : W_-DCWUA54200342 (1.0T)
12  : W_-DCWUA54003755 (1.0T)
13  : 1SP31JQM041080 (1.0T)
14  : V91S44W6 (1.5T)
15  : WD-WMAM9DKR6107 (80G)

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

16  :
17  :
18  :
19  :
20  :
21  :
22  :

23  : 1SWX1JSK2C4853 (1.5T)
24  : 1SWX1JSK2C4814 (1.5T)
25  : 1SWX1JSL0C9558 (1.5T)
26  : S1XWJ1KSC31152 (1.5T)
27  : 1SWX1JSL0C1584 (1.5T)
28  : 1SWX1JSL0C0615 (1.5T)
29  : S1XWJ1KSC31145 (1.5T)
30  :

Festplatten Seriennummern auslesen

/root/bin/diskserial.sh | sort +2 -3 -n

oder

/root/bin/diskserial_sort.sh

Serials auslesen

Für RAID-Stauts einer einzelnen Platte:

mdadm --examine /dev/sdi

Zum Serial auslesen:

udevadm info --query=all --name=/dev/sdi

bzw.

udevadm info --query=all --name=/dev/sdi | grep ID_SERIAL_SHORT

HPT RAID Managment Server

läuft auf Port 7402 (wegen Putty SSH Tunnel und so)

Login: RAID

Pass: hpt

Raid wieder assemblen

Raid5 (5 x 1TB)

mdadm --assemble /dev/md125 /dev/sda1 /dev/sdb1 /dev/sdq1 /dev/sdr1 /dev/sds1

Raid6 (14 x 1,5TB)

mdadm --assemble /dev/md127 /dev/sdc1 /dev/sdd1 /dev/sde1 /dev/sdf1 /dev/sdh1 /dev/sdi1 /dev/sdj1 /dev/sdk1 /dev/sdl1 /dev/sdm1 /dev/sdn1 /dev/sdo1 /dev/sdp1 /dev/sdt1

SMART Test

Starten

smartctl -t offline /dev/sda 

Auslesen

smartctl -l selftest /dev/sda

Ideen

ddn von sdg (Platz 28, SC06051 oder verdreht) -> dd_rescue

SpinRite

reiserfsck evtl. mit badblocks liste, aber: dev sda ist Grundlage für badblocks-Liste, nicht md127!

mdadm --create zusammen mit "missing"'


In short: Especially if you run a RAID5 array, trigger an active bad block check on a regular basis, or there is a high chance of hidden bad blocks making your RAID unusable during reconstruction. Normally, RAID passively detects bad blocks. If a read error occurs, the data is reconstructed from the rest of the array, and the bad block is rewritten. If the block can not be rewritten, the defective disk is kicked out of the active array. Once the defective drive is replaced, reconstruction will cause all blocks of the remaining drives to be read. If this process runs across a previously undetected bad block on the remaining drives, another drive will be marked as failed, making RAID5 unusable. The larger the disks, the higher the odds that passive bad block detection will be inadaquate. Therefore, with today's large disks it is important to actively perform data scrubbing on your array. With a modern (>=2.6.16) kernel, this command will initiate a data consistency and bad block check, reading all blocks, checking them for consistency, and attempting to rewrite inconsistent blocks and bad blocks.

echo check >> /sys/block/mdX/md/sync_action 

You can monitor the progress of the check with:

watch -n .1 cat /proc/mdstat

You should have your array checked daily or weekly by adding the appropriate command to /etc/crontab.

If you find yourself needlessly checking your array (like I was) and want to stop it safely, you can either stop the entire array, or:

echo idle >> /sys/block/mdX/md/sync_action

Force-Mount zum Wegkopieren

mdadm --assemble -f /dev/md127 /dev/sdc1 /dev/sdd1 /dev/sde1 /dev/sdf1 /dev/sdi1 /dev/sdk1 /dev/sda1 /dev/sdm1 /dev/sdn1 /dev/sdo1 /dev/sdp1 /dev/sdq1
cryptsetup luksOpen /dev/md127 cr_md127
mount -o ro /dev/mapper/cr_md127 /data

Identifikationen während Rettungsversuch

sda:

die mit ca. 1500 Bad Blocks; kann mit --update=summaries -f als 12. Platte reingeforced werden, hat aber bad blocks. nachh dd_rescue evtl. Reparaturversuch mit SpinRite

/dev/sda -> 28  : 1SWX1JSL0C0615 (1.5T) bzw. Serial S1XWJ1LSC06051 

kommt auf

/dev/sdv -> 


sdl:

aus dem Raid rausgeflogen, war bis zur Hälfte gebaut, bis sda als 12. Platte flog -> Raid weg -> Rebuild abgebrochen

Superblock für mdadm auf sdl vorhanden, NICHT auf sdl1 -> evtl. auch mal ohne "1" eingebunden, aus Logfile aber nicht direkt nachvollziehbar

/dev/sdl -> 23 : 1SWX1JSK2C4853 (1.5T) 


sdj:

war wohl als sdj nicht als sdj1 eingebunden (damals sdb statt sdb1); enthält evtl. noch sinnvolle Raid-Daten, könnte defekte sda als 12. Platte im Raid ersetzen, um wieder rebuilden zu können. Hat wohl ein Problem mit der Partitionsinfo/Superblock (Hexeditoraktion mit JoJo)

Superblock für mdadm auf sdj vorhanden, NICHT auf sdj1

/dev/sdj -> 25 : 1SWX1JSL0C9558 (1.5T)

kommt auf

/dev/sdw ->