[Help] RAID 5 mdadm op Ubuntu Server werkt niet meer.

[Amarog]

Hopelijk op de correcte plaats. Excuses als dit niet het geval is.

Om een lang verhaal kort te maken: Mijn Software RAID 5 was vol en ik wou een nieuwe schijf bijsteken. De schijf werd gisteren geleverd. Fier als een gieter zet ik mijn server uit (Nog geen hot swap) en steek ik de schijf in. Na de opstart wordt de schijf in de BIOS niet gevonden. Wat testen uitgevoerd. Werkt niet. In een andere PC gestoken, werkt niet. Terug in de server willen steken, wat kabeltjes verstoken en de server terug aangezet, onmiddellijk een rookwolk Onmiddellijk de stekker er uit!! En op onderzoek. Vlug gevonden, 1 van de RAID5 schijven had plots een zwarte vlek... VERDORIE!! Nog geen paniek, het is een RAID5, 1 disk mag Failen. Onmiddellijk 2 nieuwe schijven laten leveren. Getest, beide werken. 1 in de server gestoken om zo de RAID5 te kunnen herstellen.

En daar loopt het mis...

Bij opstart van de server krijg ik onmiddellijk:

The disk drive for /storage is not ready yer or not present.
Keys: Continue to wait or Press S to skip mounting or M for manual recovery

Ok, ik druk op S om door te gaan, de server start vlotjes op. Echter geen RAID5 te zien.

cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10] 
md0 : inactive sdb1[1](S) sdc1[2](S)
      5860268032 blocks super 1.2
       
unused devices: <none>

Googlen hoe ik een failed schijf moet vervangen, ik vind daar genoeg info over.
Ik moet blijkbaar eerst de schijf "failen" en dan "removen". Ok, daar gaan we, ik vermoed dat het schijf sdd was die down is. Echter krijg ik volgende foutmelding:

mdadm --manage /dev/md0 --fail /dev/sdd1
mdadm: cannot get array info for /dev/md0

Zo wordt het moeilijk iets te doen natuurlijk... Ik zie dat de nieuwe schijf ook sdd noemt nu.
Ik heb deze klaar gemaakt om te includen in de Array, mss bouwt hij zo alles weer op.

parted -a optimal /dev/sdd
GNU Parted 2.3
Using /dev/sdd
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) mklabel gpt                                                      
(parted) mkpart primary 1 -1                                              
(parted) set 1 raid on                                                    
(parted) print                                                            
Model: ATA WDC WD30EFRX-68E (scsi)
Disk /dev/sdd: 3001GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt

Number  Start   End     Size    File system  Name     Flags
 1      1049kB  3001GB  3001GB               primary  raid

(parted) quit                                                             
Information: You may need to update /etc/fstab.

Dan maar volgende gedaan:

mdadm --manage /dev/md0 --add /dev/sdd1
mdadm: cannot get array info for /dev/md0

Ok, na nog wat googlen deed ik dan maar het volgende:

mdadm --assemble --scan -v
mdadm: Devices UUID-61d15719:62f3814a:e5712e01:994bec15 and UUID-61d15719:62f3814a:e5712e01:994bec15 have the same name: /dev/md/0
mdadm: Duplicate MD device names in conf file were found.

Nu zit ik volledig met m'n handen in het haar. Ik weet het niet, google kan me niet redden, dus hoop ik opnieuw dat jullie me uit de nood kunnen helpen.

Nog wat info:

lsblk -o NAME,FSTYPE,SIZE,MOUNTPOINT,LABEL
NAME   FSTYPE              SIZE MOUNTPOINT LABEL
sda                      238.5G            
├─sda1 vfat                 94M /boot/efi  
├─sda2 ext4              206.7G /          
└─sda3 swap               31.7G [SWAP]     
sdb                        2.7T            
└─sdb1 linux_raid_member   2.7T            Server:0
sdc                        2.7T            
└─sdc1 linux_raid_member   2.7T            Server:0
sdd                        2.7T            
└─sdd1                     2.7T

Nog wat info:

cat /etc/mdadm/mdadm.conf
# mdadm.conf
#
# Please refer to mdadm.conf(5) for information about this file.
#

# by default (built-in), scan all partitions (/proc/partitions) and all
# containers for MD superblocks. alternatively, specify devices to scan, using
# wildcards if desired.
#DEVICE partitions containers

# auto-create devices with Debian standard permissions
CREATE owner=root group=disk mode=0660 auto=yes

# automatically tag new arrays as belonging to the local system
HOMEHOST <system>

# instruct the monitoring daemon where to send mail alerts
MAILADDR root

# definitions of existing MD arrays
ARRAY /dev/md/0 metadata=1.2 UUID=61d15719:62f3814a:e5712e01:994bec15 name=Server:0

# This file was auto-generated on Wed, 03 Apr 2013 19:34:13 +0200
# by mkconf $Id$
ARRAY /dev/md/0 metadata=1.2 UUID=61d15719:62f3814a:e5712e01:994bec15 name=Server:0

Ik ben een leek op gebied van RAID en Linux enzo, alles wat ik voor elkaar kreeg was door jullie hulp of door de hulp van Google. Dus hopelijk kan ik op jullie geduld rekenen.

Alvast bedankt voor ENIGE hulp,
Groeten,
Luke.

[ Voor 2% gewijzigd door Amarog op 25-03-2017 17:52 . Reden: Extra dingen trachten te doen. ]

[DJVG]

Bij twijfel niks doen als de data belangrijk is!

Je array is inactief. Even de array stoppen en geforceerd starten. Wat je ook doet, probeer schrijven te voorkomen zolang je array niet clean is!

code:

mdadm -S /dev/md0
mdadm --assemble --scan --force

Bij twijfel post een examine van elke schijf:

code:

mdadm --examine <disk>

Als dit ook niet werkt, probeer de array (met de kapotte schijf missing) te assembleren dit ALLEEN doen als je ZEKER weet dat de array kan werken met de huidige superblocks:

code:

mdadm --create /dev/md0 --level=5 --raid-devices=<originele aantal> <schijven> missing

[ Voor 53% gewijzigd door DJVG op 25-03-2017 17:54 ]

[Amarog]

Op je eerste voorstel krijg ik volgende foutmelding:

mdadm: Devices UUID-61d15719:62f3814a:e5712e01:994bec15 and UUID-61d15719:62f3814a:e5712e01:994bec15 have the same name: /dev/md/0
mdadm: Duplicate MD device names in conf file were found.

Meer info voor je:

mdadm --examine /dev/sd*
/dev/sda:
   MBR Magic : aa55
Partition[0] :    500118191 sectors at            1 (type ee)
/dev/sda1:
   MBR Magic : aa55
mdadm: No md superblock detected on /dev/sda2.
mdadm: No md superblock detected on /dev/sda3.
/dev/sdb:
   MBR Magic : aa55
Partition[0] :   4294967295 sectors at            1 (type ee)
/dev/sdb1:
          Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x0
     Array UUID : 61d15719:62f3814a:e5712e01:994bec15
           Name : Server:0  (local to host Server)
  Creation Time : Tue Apr  2 16:38:49 2013
     Raid Level : raid5
   Raid Devices : 3

 Avail Dev Size : 5860268032 (2794.39 GiB 3000.46 GB)
     Array Size : 5860267008 (5588.79 GiB 6000.91 GB)
  Used Dev Size : 5860267008 (2794.39 GiB 3000.46 GB)
    Data Offset : 262144 sectors
   Super Offset : 8 sectors
          State : clean
    Device UUID : 4631e72a:8628e5af:6aa67a57:72b92e0a

    Update Time : Fri Mar 24 19:25:18 2017
       Checksum : 6bd0e706 - correct
         Events : 515

         Layout : left-symmetric
     Chunk Size : 512K

   Device Role : Active device 1
   Array State : AAA ('A' == active, '.' == missing)
/dev/sdc:
   MBR Magic : aa55
Partition[0] :   4294967295 sectors at            1 (type ee)
/dev/sdc1:
          Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x0
     Array UUID : 61d15719:62f3814a:e5712e01:994bec15
           Name : Server:0  (local to host Server)
  Creation Time : Tue Apr  2 16:38:49 2013
     Raid Level : raid5
   Raid Devices : 3

 Avail Dev Size : 5860268032 (2794.39 GiB 3000.46 GB)
     Array Size : 5860267008 (5588.79 GiB 6000.91 GB)
  Used Dev Size : 5860267008 (2794.39 GiB 3000.46 GB)
    Data Offset : 262144 sectors
   Super Offset : 8 sectors
          State : clean
    Device UUID : 1f886971:9b615fa9:4475c4f3:4959449f

    Update Time : Fri Mar 24 19:25:18 2017
       Checksum : dd2ce5a7 - correct
         Events : 515

         Layout : left-symmetric
     Chunk Size : 512K

   Device Role : Active device 2
   Array State : AAA ('A' == active, '.' == missing)
/dev/sdd:
   MBR Magic : aa55
Partition[0] :   4294967295 sectors at            1 (type ee)
mdadm: No md superblock detected on /dev/sdd1.

Ik wacht nog even om op je tweede voorstel in te gaan.

[ Voor 78% gewijzigd door Amarog op 25-03-2017 17:58 . Reden: Extra info. ]

[DJVG]

Amarog schreef op zaterdag 25 maart 2017 @ 17:56:
Op je eerste voorstel krijg ik volgende foutmelding:

mdadm: Devices UUID-61d15719:62f3814a:e5712e01:994bec15 and UUID-61d15719:62f3814a:e5712e01:994bec15 have the same name: /dev/md/0
mdadm: Duplicate MD device names in conf file were found.

Ik wacht nog even om op je tweede voorstel in te gaan.

Verwijder even de onderste regel uit /etc/mdadm/mdadm.conf, want die staat er inderdaad dubbel in. En draai --assemble opnieuw.

ARRAY /dev/md/0 metadata=1.2 UUID=61d15719:62f3814a:e5712e01:994bec15 name=Server:0

Edit 18:01:
Je array ziet er goed uit en zou met een geforceerde assemble gewoon online moeten komen. Dat doet hij nu niet omdat het een raid5 is en al 1 disk weg is.

[ Voor 11% gewijzigd door DJVG op 25-03-2017 18:01 ]

[Amarog]

Ik heb de laatste regel er uit gelaten:

cat /etc/mdadm/mdadm.conf
# mdadm.conf
#
# Please refer to mdadm.conf(5) for information about this file.
#

# by default (built-in), scan all partitions (/proc/partitions) and all
# containers for MD superblocks. alternatively, specify devices to scan, using
# wildcards if desired.
#DEVICE partitions containers

# auto-create devices with Debian standard permissions
CREATE owner=root group=disk mode=0660 auto=yes

# automatically tag new arrays as belonging to the local system
HOMEHOST <system>

# instruct the monitoring daemon where to send mail alerts
MAILADDR root

# definitions of existing MD arrays
ARRAY /dev/md/0 metadata=1.2 UUID=61d15719:62f3814a:e5712e01:994bec15 name=Server:0

# This file was auto-generated on Wed, 03 Apr 2013 19:34:13 +0200
# by mkconf $Id$
ARRAY /dev/md/0 metadata=1.2 UUID=61d15719:62f3814a:e5712e01:994bec15 name=Server:0

ik blijf dezelfde foutmelding krijgen:

mdadm --assemble --scan --force
mdadm: Devices UUID-61d15719:62f3814a:e5712e01:994bec15 and UUID-61d15719:62f3814a:e5712e01:994bec15 have the same name: /dev/md/0
mdadm: Duplicate MD device names in conf file were found.

[DJVG]

Amarog schreef op zaterdag 25 maart 2017 @ 18:01:
Ik heb de laatste regel er uit gelaten:

cat /etc/mdadm/mdadm.conf
# mdadm.conf
#
# Please refer to mdadm.conf(5) for information about this file.
#

# by default (built-in), scan all partitions (/proc/partitions) and all
# containers for MD superblocks. alternatively, specify devices to scan, using
# wildcards if desired.
#DEVICE partitions containers

# auto-create devices with Debian standard permissions
CREATE owner=root group=disk mode=0660 auto=yes

# automatically tag new arrays as belonging to the local system
HOMEHOST <system>

# instruct the monitoring daemon where to send mail alerts
MAILADDR root

# definitions of existing MD arrays
ARRAY /dev/md/0 metadata=1.2 UUID=61d15719:62f3814a:e5712e01:994bec15 name=Server:0

# This file was auto-generated on Wed, 03 Apr 2013 19:34:13 +0200
# by mkconf $Id$
ARRAY /dev/md/0 metadata=1.2 UUID=61d15719:62f3814a:e5712e01:994bec15 name=Server:0

ik blijf dezelfde foutmelding krijgen:

mdadm --assemble --scan --force
mdadm: Devices UUID-61d15719:62f3814a:e5712e01:994bec15 and UUID-61d15719:62f3814a:e5712e01:994bec15 have the same name: /dev/md/0
mdadm: Duplicate MD device names in conf file were found.

ARRAY /dev/md/0

Staat nog steeds 2 keer in mdadm.conf.

[Amarog]

Idd, ik zag het, het stond er blijkbaar 3x in...

mdadm: /dev/md/0 has been started with 2 drives (out of 3).

[DJVG]

Amarog schreef op zaterdag 25 maart 2017 @ 18:03:
Idd, ik zag het, het stond er blijkbaar 3x in...

mdadm: /dev/md/0 has been started with 2 drives (out of 3).

Perfect! Nu kan je de nieuwe schijf toevoegen aan de raid!

[Amarog]

Dus gewoon

mdadm --manage /dev/md0 --add /dev/sdd1

of moet ik gewoon sdd pakken? (Ik heb die schijf met gparted reeds klaar gemaakt zoals je kan lezen in de eerste topic, ik deed dit volgens google instructies.)

[DJVG]

Amarog schreef op zaterdag 25 maart 2017 @ 18:05:
Dus gewoon

mdadm --manage /dev/md0 --add /dev/sdd1

of moet ik gewoon sdd pakken? (Ik heb die schijf met gparted reeds klaar gemaakt zoals je kan lezen in de eerste topic, ik deed dit volgens google instructies.)

Dit zou moeten werken:

mdadm --add /dev/md0 /dev/sdd1

Beste is als alle schijven dezelfde partitie layout hebben qua alignen, maar het MOET niet.

[Amarog]

Het werkt idd, hij zou bezig zijn alles te herstellen:

cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10] 
md0 : active raid5 sdd1[3] sdb1[1] sdc1[2]
      5860267008 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [_UU]
      [>....................]  recovery =  0.0% (329728/2930133504) finish=444.2min speed=109909K/sec
      
unused devices: <none>

ik hou het in de gaten, als het werkt dan ben je mijn held!! Echt waar.
Als ik dan nog een schijf wil toevoegen om de RAID te vergroten (Wat natuurlijk de eerste bedoeling was) moet ik dan dezelfde stappen herhalen. De schijf klaar maken en gewoon toevoegen?

[DJVG]

Amarog schreef op zaterdag 25 maart 2017 @ 18:08:
Het werkt idd, hij zou bezig zijn alles te herstellen:

cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10] 
md0 : active raid5 sdd1[3] sdb1[1] sdc1[2]
      5860267008 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [_UU]
      [>....................]  recovery =  0.0% (329728/2930133504) finish=444.2min speed=109909K/sec
      
unused devices: <none>

ik hou het in de gaten, als het werkt dan ben je mijn held!! Echt waar.
Als ik dan nog een schijf wil toevoegen om de RAID te vergroten (Wat natuurlijk de eerste bedoeling was) moet ik dan dezelfde stappen herhalen. De schijf klaar maken en gewoon toevoegen?

Yes, herstellen ziet er goed uit, pas mounten als sync helemaal klaar is! Al is raid5 natuurlijk niet aan te raden, maar dat is natuurlijk je eigen keuze.

Voor het vergroten van je array:

mdadm --add /dev/md0 <extra/nieuw disk>
mdadm --grow --raid-devices=4 --backup-file=<backup bestand op plek buiten de array (e.g. /root/md.bak)> /dev/md0

Als dit klaar is natuurlijk nog je filesystem growen, maar ik weet niet welk fs je gebruikt, dus kan ik nu niks over zeggen.

Succes!

[Amarog]

Alvast heel straf bedankt man! Mijn server verliezen was als een arm kwijt zijn, ik weet het, een rare vergelijking, maar toch... Het was raar

En waarom zou je een RAID5 niet aan raden? 1 schijf die mag falen lijkt me ideaal. Neen?

[.Maarten]

Kans op failure bij rebuilden is best hoog omdat het heel intensief is. Daarom wordt raid5 afgeraden bij grote schijven. Het rebuilden duurt dan zo lang dat het best een risico is.

[DJVG]

Omdat de kans op het verliezen van je data groot is. Al is het de simpele reden dat je soms meerdere schijven koopt uit dezelfde productie lijn, die dus ook zeer kort na elkaar kunnen falen (sneller dan jij kan rebuilden).

Leesvoer:
https://news.ycombinator.com/item?id=8306499
http://www.zdnet.com/arti...e-raid-5-on-small-arrays/

[Amarog]

"That means if the data on the surviving drives totals 12TB, the probability of the array failing rebuild is close to 100%"

Slik... Dan kan ik maar beter gaan denken aan een RAID1 ?

[Q]

Het ZDNET artikel is onzin. RAID 5 is prima. De kans dat een rebuild fout gaat is erg klein.

Door het ZDNET artikel is een enorme hetze ontstaan tegen RAID5 maar de praktijk laat zien dat de getallen van Harris niet kloppen en dat de risico's veel kleiner zijn.

Hier wat argumenten:
http://louwrentius.com/ra...-fine-for-home-usage.html

Hier iemand met ervaring op schaal:

https://www.reddit.com/r/..._is_uncalled_for/d79xvls/

Volgens mij is er een setting die bepaald of een degraded array mag worden gestart als een disk mist.
Ik zal even zoeken waar dat zit.

Er is helemaal niets mis met RAID 5, het kern probleem hier is dat bij het sleutelen gewoon wat mis ging en zoals ik het nu begrijp heb je je data waarschijnlijk nog dankzij RAID 5.

Je kunt zonder enig risico je array proberen te mounten om even te kijken of dat lukt en of je weer bij je data kunt, dat kan gerust tijdens het rebuilden.

[ Voor 74% gewijzigd door Q op 25-03-2017 19:05 ]

[Amarog]

Q schreef op zaterdag 25 maart 2017 @ 18:55:
Er is helemaal niets mis met RAID 5, het kern probleem hier is dat bij het sleutelen gewoon wat mis ging en zoals ik het nu begrijp heb je je data waarschijnlijk nog dankzij RAID 5.

Je kunt zonder enig risico je array proberen te mounten om even te kijken of dat lukt en of je weer bij je data kunt, dat kan gerust tijdens het rebuilden.

Idd, als er rook uit 1 van m'n schijven komt tijdens het "sleutelen" dan kan je dat wel zeggen. Wat een schrik momentje was me dat.

De Array is op zijn gemak aan het herstellen:

cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10] 
md0 : active raid5 sdd1[3] sdb1[1] sdc1[2]
      5860267008 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [_UU]
      [===>.................]  recovery = 15.9% (468675184/2930133504) finish=321.0min speed=127792K/sec
      
unused devices: <none>

Jullie zeggen om mijn Array terug te mounten na het herstellen. Hoe gaat dit dan in zijn werk? Ik ging eigenlijk gewoon de boel weer reboten nadat hij klaar was

Greetz

[Q]

Een ander leermomentje voor jezelf is dat je nooit dit failure scenario getest hebt. Dus nu het mis gaat ben je in paniek en weet je niet wat je moet doen. Dat is nog gevaarlijker dan RAID0 draaien.



Ik vermoed dat als je gewoon

mount /directory

doet waarbij directory je map was waar de array op mountte, dat alles dan weer goed is. Echter, als je niet weet hoe je je array handmatig moet mounten, dan heb je niet veel kaas gegeten van Linux, dus alles wat je doet op eigen risico... Let even goed op wat je doet.

Ik ga er vanuit dat je fstab gewoon nog klopt en dat de naam van je array niet is veranderd (md0).

[ Voor 14% gewijzigd door Q op 25-03-2017 19:18 ]

[Amarog]

Ik heb zelf héél weinig kaas gegeten van Linux Ik heb geen enkel probleem dat toe te geven. Alles wat ik op m'n server doe heb ik mezelf via tutorials, google en dergelijk geleerd.

Ik ben idd iemand die iets aanpakt de moment dat het mis gaat Nu ging het mis met m'n schijf en ben ik aan het googlen geslaan, helaas hielp dit me niet onmiddellijk verder. Dan kom ik meestal even bij jullie langs. Ik hou wel altijd netjes bij wat ik heb gedaan en hoe ik het heb gedaan. Op die manier leer ik toch iets

Het is soms Chinees maar ik tracht wel alles te bekijken wat wat is en hoe ik iets heb gedaan. De Server draaide nu toch al 3 jaar probleemloos. Daar ben ik wel best trots op

[Q]

Je initiatief is positief, dat je Linux wilt leren, dat is een goede instelling. Maar je beheerst iets pas als je ook makkelijk problemen zelf kunt oplossen. Niet wachten totdat er iets mis gaat

[Amarog]

Wel, ik had al een hoop info opgezocht wat er kon mis gaan bij het toevoegen van een nieuwe schijf. Echter was het volledig down gaan van een reeds werkende schijf niet 1 van mijn bedenkingen

Eind goed al goed denk ik, na de restore kan ik alsnog proberen de nieuwe schijf toe te voegen en de RAID5 vergroten met 1 schijf. Ik heb nog steeds alle info open staan, ik heb ze onderwijl al 100x gelezen, dus ik denk niet dat dat nog mis mag gaan

[Q]

Kun je dan nu al weer bij je data, is het mounten gelukt?

[Amarog]

Ik durf nog niet mounten Ik laat hem op het gemak restoren en dan zie ik wel

[Amarog]

Alles werkt terug, nu begonnen aan het toevoegen van de nieuwe schijf.

cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10] 
md0 : active raid5 sde1[4] sdc1[2] sdb1[1] sdd1[3]
      5860267008 blocks super 1.2 level 5, 512k chunk, algorithm 2 [4/4] [UUUU]
      [>....................]  reshape =  0.3% (10129924/2930133504) finish=1072.8min speed=45360K/sec
      
unused devices: <none>

Dat gaat wel eventjes duren, klein vraagje, terwijl hij bezig is. Kan ik de RAID gebruiken? Bijvoorbeeld om muziek af te spelen? Of laat ik hem beter gewoon zijn gang gaan?

Groerten.

[ Voor 79% gewijzigd door Amarog op 26-03-2017 04:42 ]

[Scorpei]

Puur nog even nu 2 cents over je stress : is je data je wat waard? RAID is geen back-up! Raid is redundancy met goedkope hardware. Het is met name downtime verkorten. Heb zelf jaren raid5 toen 6 gedraaid met 8 1tb disks (steeds laten groeien dus alles uit verschillende batches en merken). Ook af en toe flink problemen gehad en bang mijn (niet kritische) data kwijt te zijn. Prima leerschool! Me toen ook flink verkeken op hoe lang een rebuild duurt (goede 8-11u). Op 6tb usable volume (deze array begon op 2) ging na 3 jaar een disk echt dood en heb ik alles overgezet op een zraid1 volume met 3x4tb (8tb effectief) en een single offsite back-up disk. Net na het overzetten van de data klapte er nog een disk uit dus goede timing xD. Disks waren toen wel 5, 6 a 7 jaar. Kritieke data staat overigens ook onsite op mijn gewone pc (snellere recovery met name en 2 backups is mooi, op de administratie daarvan na). 1ste zonder smart waarschuwingen gefaald 2de met en was hetzelfde type dus die zag ik komen.

Lees je voor je eigen beeldvorming ook even in op zfs / btrfs. En puur voor de vorm even de ecc of geen ecc discussie aantikken;). Ook temperatuur is een leuke mbt failure rates.

[ Voor 6% gewijzigd door Scorpei op 26-03-2017 08:11 ]

[Q]

Amarog schreef op zondag 26 maart 2017 @ 04:32:

Dat gaat wel eventjes duren, klein vraagje, terwijl hij bezig is. Kan ik de RAID gebruiken? Bijvoorbeeld om muziek af te spelen? Of laat ik hem beter gewoon zijn gang gaan?

Groerten.

Je kunt de RAID gewoon blijven gebruiken, performance is alleen wat minder.

[Amarog]

Scorpei schreef op zondag 26 maart 2017 @ 08:08:
Puur nog even nu 2 cents over je stress : is je data je wat waard?

Wat waard, neen, het is data die ik mag verliezen... Data die ik belangrijk vind staat momenteel op 3 verschillende plaatsen. Lijkt me genoeg voor thuis gebruik. De stress was vooral omdat ik geen oplossing vond. En dat heb ik niet graag.

Q schreef op zondag 26 maart 2017 @ 09:20:
[...]
Je kunt de RAID gewoon blijven gebruiken, performance is alleen wat minder.

Wat minder, ok, een film streamen zal dus wat lastiger gaan Nuja, ik heb geduld.

Allemaal veel dank voor de hulp, weer een wijze les geleerd

[Q]

Film streamen zal waarschijnlijk nog prima gaan ook: test het maar, dan weet je of het kan of niet.

Het ergste wat kan gebeuren is dat je wat leert.

[Amarog]

Werkt idd allemaal zonder problemen! Toppie

[Rolfie]

Q schreef op zaterdag 25 maart 2017 @ 18:55:
Het ZDNET artikel is onzin. RAID 5 is prima. De kans dat een rebuild fout gaat is erg klein.

Door het ZDNET artikel is een enorme hetze ontstaan tegen RAID5 maar de praktijk laat zien dat de getallen van Harris niet kloppen en dat de risico's veel kleiner zijn.

Wel lullig als jij net nu net onder die kleine kans zou vallen..... Of de getallen nu wel of niet kloppen.
Het is gewoon een risico, waar je over moet nadenken en goed over moet nadenken. Als je data op een 2de veilige locatie staat, dan is het risico erg klein.

Echter er is wel een risico, persoonlijk zou ik met grote data volumes niet doen. Maar mijn data is belangrijk voor mij.

[Verwijderd]

Ik wil toch even waarschuwen voor gebruikers als Q die zeggen dat RAID5 prima is en alle maatregelen die de industrie (Microsoft, Linux, Solaris, BSD, Synology, QNAP) nemen om opslag veilig te krijgen, onzin is. Hij staat daar volgens mij redelijk alleen in en ik wil wel gezegd hebben dat een dergelijke mening - want dat is het - volgens diverse maatstaven wel vrij extreem is.

RAID5 wordt door bijna iedereen afgeraden. Sowieso wordt ouderwets RAID vandaag de dag afgeraden, omdat je nauwelijks bescherming hebt tegen corruptie en bad sectors. Met hele dure hardware zoals Enterprise-hardeschijven, ben je nog wel redelijk veilig met legacy RAID. Maar wil je echt veilige opslag, kijk dan eens naar ZFS en laat je informeren uit meerdere bronnen. Vooral dat laatste is noodzakelijk om jezelf te weren tegen meningen en opvattingen die ver buiten de mainstream gaan en zeer waarschijnlijk onjuist zijn. Ik heb nog nooit een goed onderbouwde claim gezien van dergelijke meningen, terwijl aan de andere zijde dergelijk 'bewijs' is geleverd. En dat de hele industrie over gaat, inclusief oude rotten als Microsoft en QNAP/Synology die vooral minder-technisch onderlegde mensen als gebruikersgroep hebben, zegt mogelijk ook wat.

Volg je hart, maak een wijze keuze.

[Amarog]

Ik ga zeker ZFS eens bekijken. Je haalde reeds goede argumenten aan in m'n vorige topic: https://gathering.tweakers.net/forum/list_messages/1762365

Nu had ik echter vlug extra ruimte nodig, vandaar leek voor mij de RAID vergroten de quick solution. Het zorgde er wel voor dat ik geen data verlies heb bij het crashen van een schijf. Daar ben ik wel dankbaar voor. Ook al is die data niet levensbelangrijk, er is toch een hoop werk in gekropen om alles te verzamelen.

Overschakelen op ZFS is voor mij weer een stap in het duister, iets wat ik wel graag doe, zo'n projectjes tackelen zijn m'n dada, if you catch my drift Het zal waarschijnlijk weer véél lezen en vloeken worden, maar als m'n mij iets goed onderbouwd kan aanraden, dan zou m'n moeten dom zijn van het niet te proberen!

Groeten.

[Scorpei]

Check ook zendt zeker btrfs, documentatie van zfs schijnt minder te zijn inclusief minder recovery tools en zelf heb ik wel geemmer gehad met compatibiliteit tussen Linux en freebsd met zfs

[ Voor 9% gewijzigd door Scorpei op 26-03-2017 16:19 ]

[Q]

Ik vind het jammer dat CiPHER het bovenstaande schrijft, het is erg suggestief over mijzelf, MDADM, QNAPs en alles wat niet ZFS is. Maar het is allemaal wat genuanceerder dan dit.

CiPHER doet denegrerend over Synologies en QNAP omdat dit soort apparaten een directe concurrent zijn voor zelfbouw oplossingen op basis van ZFS en CiPHER werkt nu aan ZFSGuru, hij heeft een belang bij zijn verhaal en promotie over ZFS.

Het feit is dat ZFS vooral door hobbyisten thuis wordt toegepast, maar het is geen must-have. Als Synologies en QNAPs zulke 'slechte' apparaten zouden zijn, die trouwens allemaal officieel RAID 5 supporten, dan zou je daar wel een hoop klachten over lezen. Maar in de praktijk werken die dingen prima. Idem voor MDADM.

Begrijp me niet verkeerd, ik draai zelf ook ZFS en ik ben er blij mee, maar het gaat om de juiste afweging. Op een andere machine pas ik MDADM toe.

Het is goed om je in ZFS te verdiepen, volg ook gerust de linkjes in mijn signature om juist een evenwichtig beeld te krijgen van ZFS.

ZFS is een heel mooi file system, mensen hoeven echt niet bang te zijn voor ZFS, ZFS op Linux werkt ook prima. Een 'gebrek' aan FCSK tools zou je niet tegen moeten houden.

Maar ZFS moet niet gepromoot worden op basis van fear uncertainty and doubt. Het moet gepromoot worden op basis van eerlijke argumenten.

Soms past ZFS goed bij wat iemand wil en biedt het meerwaarde. Soms heeft ZFS weinig toegevoegde waarde en heeft het beperkingen.

Vandaag heb je 1 schijf toegevoegd om capaciteit uit te breiden. Dat kan niet met ZFS op dezelfde efficiënte manier als MDADM dat kan. Is dat erg? Aan jou de keuze.

Volg je verstand, maak een wijze keuze

[ Voor 204% gewijzigd door Q op 26-03-2017 17:26 ]

[Renault]

Ik mis nog twéé argumenten: tijd en geld!

Het onderstaande bezie ik in het licht van niet-professionele toepassing van RAID, waarbij de I nog steeds is van "inexpensive"! En ook in het licht dat het bij RAID gaat om beschikbaarheid van data, niet om de "backup" van data. Waarbij prijzen van opslagmedia overall razendsnel zakken, maar die van professionele recovery niet.

Ik heb het gevoel dat de hoogtij dagen van RAID "5 en hoger" een beetje achter ons liggen.
Waarom?
- in het verleden was RAID vaak de enig aangewezen manier om een béétje betrouwbare opslag van data te verkrijgen, met de mogelijkheid om in een aantal gevallen van falen via een Rebuild een snellle beschikbaarheid van de data terug te verkrijgen.
- ook voor het verkrijgen van voldoende grote opslagvolumes was je bij de toenmalige (betaalbare ...) kleine schijfcapaciteiten bijna altijd aangewezen op RAID.
- die situatie baseerde deels óók op de kleine schijfcapaciteiten i.r.t. de processorsnelheden van de RAID-controllers: Rebuilds vonden vrij snel plaats.
- op dit moment zijn de opslagcapaciteiten héél snel gegroeid t.o.v. "toen", maar zijn de prosessorsnelheden van de RAID-controllers niet in verhouding mee gegroeid: het argument van een snelle rebuild komt daardoor bijna te vervallen als je "dagen" moet wachten i.p.v. "uren" (een backup terugzetten op gecontroleerde/nieuwe schijven is tegenwoordig vaak véél sneller!).
- de momenteel goedkope grote schijven maken het aanmaken en vervangen van grote opslagvolumes vrij eenvoudig, ook zonder RAID toe te passen (als ik JBOD e.d. even niet als RAID meetel).
- de momenteel grote schijfcapaciteiten en sterk toegenomen lees/schrijfsnelheden i.c.m. snelle interfaces, snelle netwerken en snelle Cloudtoegang maken het bijhouden en terugplaatsen van backups vrij eenvoudig, dat in grote tegenstelling tot vroeger.
- ook had je het vroeger vaak over duizenden guldens/Euro's voor harddisks, nu over "tientjes/honderdjes".
- de toegenomen invloed van "bitrot" maken (op RAID1 na) toepassen van RAID systemen voor opslag op lange termijn steeds riskanter voor niet-professionele omgevingen.
- de operationele mogelijkheden van SMART zijn onvoldoende als middel om (partiële) uitval van opslagcapaciteit te voorspellen, terwijl ik geen goed alternatief ken dat die mogelijkheid wel biedt.

Ik denk daarom dat de tijds-factor (én de toenemende capaciteit en betrouwbaarheid van SSD's) ons automatisch duwt in de richting van:
- koppeling van opslagmedia m.b.v. JBOD e.d. i.c.m. offline / offsite backups over snelle interfaces / verbindingen voor intern/online beschikbaar stellen van grote hoeveelheden data.
- (betaalde) cloudopslag, waarbij de "betaling" aanvullende garanties biedt en je als het ware vooraf "Recoverykosten"voorkomt.
- actuele bestandssystemen die beter bestand zijn tegen "bitrot".
- onveiliger plaatsing van data, omdat aan bijna elk opslagmedium een online verbinding zit die kan worden misbruikt/gekraakt.

Just my 2 cents.

[Q]

Renault schreef op zondag 26 maart 2017 @ 19:45:

Ik heb het gevoel dat de hoogtij dagen van RAID "5 en hoger" een beetje achter ons liggen.
Waarom?
- op dit moment zijn de opslagcapaciteiten héél snel gegroeid t.o.v. "toen", maar zijn de prosessorsnelheden van de RAID-controllers niet in verhouding mee gegroeid: het argument van een snelle rebuild komt daardoor bijna te vervallen als je "dagen" moet wachten i.p.v. "uren" (een backup terugzetten op gecontroleerde/nieuwe schijven is tegenwoordig vaak véél sneller!).

Sorry, maar dit argument is niet correct, RAID is een super simpel algoritme voor een CPU en rebuild snelheden zijn 100% afhankelijk van de doorvoer snelheid van een harde schijf, niet van de CPU.

In dit topic gaat het om software RAID op de reguliere CPU en daar zie je dat het naar boven afgerond ongeveer 8 uur duurt voor een rebuild. Dat is normaal onder deze omstandigheden.

- de toegenomen invloed van "bitrot" maken (op RAID1 na) toepassen van RAID systemen voor opslag op lange termijn steeds riskanter voor niet-professionele omgevingen.

Kun je naar relevant onderzoek verwijzen, dat er een toename is van schijven die door bad sectors / UREs worden getroffen?

[ Voor 7% gewijzigd door Q op 26-03-2017 20:29 ]

[Renault]

Nee hoor, het is puur op het gevoel geschreven (met een schuine blik naar de inhoud van de topics van de laatste jaren) zonder enige claim op gelijk hebben.
Ieder zijn mening en jij zou zomaar gelijk kunnen hebben!

[Amarog]

Woesh, ok, leuke discussie. Ik hou beide argumenten zeker bij me! De RAID zal sowieso blijven. Echter zou ik wel wat durven gaan spelen in een nieuw systeem met ZFS. Why not...

Effe on topic

Ik heb dus de RAID succesvol kunnen uitbreiden met een nieuwe schijf na de restore. Joepie! Nu las ik ergens dat er 5% van je schijven vrij blijven die alleen door root kunnen beschreven worden. Op 9 Terra RAID is dat toch al vlug wat. Dus effe opgezocht en dat uitgezet via volgende command:

tune2fs -m 0 /dev/md0

Nu valt het me echter op dat de RAID nog steeds maar 8.2 Terra groot is. (4 schijven van 3T zou moeten 9T vrij zijn neen?)

/dev/md0        8.2T  3.9T  4.3T  48% /storage

En ja, tijdens het toevoegen van de nieuwe schijf enzo per ongeluk een mapje met wat data gewist. Plots heb ik dus weer genoeg schijfruimte

[Q]

http://knowledge.seagate....Q/172191en?language=en_US

[Verwijderd]

Amarog schreef op maandag 27 maart 2017 @ 19:26:
En ja, tijdens het toevoegen van de nieuwe schijf enzo per ongeluk een mapje met wat data gewist. Plots heb ik dus weer genoeg schijfruimte

Nóg een goede reden om ZFS te overwegen: snapshots!

Na een ongelukje met de delete-knop haal je zo je oude data weer terug. En het beschermt ook uitstekend tegen ransomware en dergelijke.

[Q]

Kan ook met LVM, ZFS snapshots zijn 'mooier'.
Een backup history is echter veel belangrijker dan snapshots. Snapshot != backup

[ Voor 24% gewijzigd door Q op 28-03-2017 00:18 ]

[Verwijderd]

Maar wel kostbaarder. Maar ZFS leent zich natuurlijk ook uitstekend voor incremental backups. Het origineel kan eventueel zelfs op Ext4/NTFS/FAT staan, als het zou corrumperen kun je naar een oudere versie.

Snapshots zijn zeker niet uniek voor ZFS. Maar de implementatie en features zijn wel zeer goed. Zo kost het vrijwel geen ruimte; alleen de mutaties kosten ruimte. Dus het verwijderen van een bestand zal je niet direct diskruimte teruggeven, pas als de snapshot is verwijderd. Maar verder is er weinig overhead; het maken van snapshots gaat snel (<1sec), het kost geen performance overhead, nauwelijks disk overhead exclusief de mutaties en het doorzoeken van snapshotdirs is erg handig zonder een rollback te hoeven doen, waarbij het hele filesystem terug in de tijd gaat, definitief en onomkeerbaar. De snapshotdirs zijn handig om die ene file of ene dir die je perongeluk hebt gedelete of overschreven, terug te halen.

[Q]

Dat is waar, ZFS snapshots zijn erg gaaf en makkelijk te gebruiken.

[Amarog]

Q schreef op maandag 27 maart 2017 @ 22:37:
http://knowledge.seagate....Q/172191en?language=en_US

Ahzo... Dat verklaart wel wat. Pfft