Raid Recovery: do's en don'ts

Van tijd tot tijd krijgen we raid-systemen binnen voor datarecovery.
Een raid op zich recoveren is in veel gevallen al niet eenvoudig, maar de zaak kan nog veel complexer worden door ondoordachte handelingen van de gebruiker of IT verantwoordelijke.

Eerst een korte beschrijving van de verschillende raid-systemen:

Raid 0: Minimum 2 schijven, de data is verdeeld in 'stripes' over de verschillende schijven. Valt één schijf uit, dan is de data niet meer toegankelijk.

Raid1: Bestaat uit twee schijven, die een kopie zijn van elkaar. Valt één schijf uit, dan kan normaal met de andere schijf voortgewerkt worden.
Nadeel: Soms is een schijf al maanden geleden uitgevallen, zonder dat men dat merkt. Valt dan ook de andere uit, dan kan men niet meer aan de data.

Raid5: Bestaat uit minimum drie schijven. De data is verdeeld over de drie schijven, samen met pariteitsblokken. Valt één schijf uit, dan kan men nog voortwerken met de twee andere.

Raid6:  Bestaat uit minimum vier schijven. De data is verdeeld over de vier schijven, samen met 2 verschillende pariteitsblokken. Hier mogen twee schijven uitvallen en nog kan men voortwerken.

Er bestaan ook nog andere raid-configuraties, zoals 0 + 1 of 5 + 1, maar dit zijn combinaties van de bovenstaande raid-systemen.

Wat kan er foutgaan ?

Raid0: 

1 schijf valt uit; data is niet meer bereikbaar. Alle schijven zijn nodig voor datarecovery

Raid1:

Scenario 1:

1 schijf valt uit en men merkt het niet. Na een tijdje valt ook de tweede uit en is de data onbereikbaar.

Grootste fout hier is dat men maar één van de twee schijven bezorgt. Het gebeurt dat één schijf enkel logische fouten heeft, en de andere een headcrash.

Scenario 2:

1 schijf valt uit en men merkt het niet. Men werkt door met de andere schijf. Na enkele maanden besluit de schijf die eerst uitviel toch terug op te starten (reden onbekend). De raid 1 synchroniseert terug maar in de verkeerde richting. Beide schijven bevatten nu oude data.

Scenario 3:

1 schijf valt uit, en men merkt het wel. Men vervangt de defecte schijf door een nieuwe schijf, en het systeem synchroniseert beide schijven. Echter in de verkeerde richting. Men heeft nu twee blanco schijven.

Praktijkvoorbeeld:

Een klant bracht ons één schijf en hergebruikte de andere (die nog bleek te werken, maar het logisch volume was weg) om een oude backup te herinstalleren. Bleek nadien dat juist die schijf het laatst uitviel, en de schijf die ons bezorgd werd bevatte enkel oude data. Gezien de nog werkende schijf overschreven werd met een oude backup was hun data weg.

Wat niet doen:

Schijven terug synchroniseren zonder backup want de synchronisatie kan verkeerd uitdraaien

Raid5:

Bij een raid 5 treden maar problemen op als er twee schijven uitvallen.

Scenario 1:

Een schijf valt uit, en men werkt verder zonder ze te vervangen, denkende dat men toch veilig zit. Het gebeurt vaak dat vrij snel een tweede schijf sneuvelt en dan heeft men een probleem. Zeker als de laatste schijf sneuvelt met een headcrash, want de schijf die eerst uitviel bevat oude data.

Scenario 2:

Verschillende schijven vallen uit op hetzelfde moment, bvb. door een stroomstoring.

Scenario 3:

De Raid-controller geraakt defect, en hoewel de schijven nog goed zijn heeft men ook geen toegang meer tot de data. Vooral bij oudere controllers is dit een probleem aangezien ze nog maar moeilijk te vinden zijn.

Praktijkvoorbeeld 1:

Een schijf van een raid5 valt uit.  De klant vervangt de schijf en doet een rebuild. Na een tijdje stopt de rebuild met een foutmelding bij een andere schijf.
De klant neemt nu de andere schijf uit de raid en vervangt ze door een nieuwe en forceert een rebuild.

Het spreekt voor zich dat dit niet goed kan aflopen. Aangezien de eerste rebuild niet voltooid is, zal de nieuwe rebuild de data corrupt maken en zelfs overschrijven zodat een volledige recovery niet meer mogelijk is.

Praktijkvoorbeeld 2:

Twee schijven van een raid 5 vallen uit. De klant vervangt beide schijven en forceert een rebuild. Uiteraard kan dit niet lukken, want er ontbreekt een stuk van de data gezien er twee schijven uitgevallen zijn.

Als een raid niet meer recupereerbaar is, is dit in de meeste gevallen te wijten aan de handelingen die de klant uitvoerde voor hij bij ons kwam.

Wat niet doen:

Nooit een rebuild uitvoeren zonder de schijven eerst te klonen (sector by sector copy) of een goede backup te hebben

Raid6:

Bij een raid 6 treden maar problemen op als er drie schijven uitvallen. Gezien de grote redundantie gebeurt het maar zelden dat we een raid 6 binnenkrijgen. Gezien de grotere complexiteit zijn deze recoveries ook duurder.

Wat niet doen:

Nooit een rebuild uitvoeren zonder de schijven eerst te klonen (sector by sector copy) of een goede backup te hebben.