NAS med 6 platser, hur ska man RAIDa?

Försök inte flytta diskar i en NAS till en annan NAS utan att först gjort backup på all data på diskarna till annan media - räkna med att diskarna du stoppar in så förloras all data på dem då det är alldeles för mycket automatik som drar igång för att det skall vara "enkelt" för användare och så gör det saker som du inte har räknat med som att expandera befintliga volymer och det första det gör är att skriva över datat på de nyss insatta diskarna. - om det ändå skulle fungera att flytta över rakt - bra, men räkna inte med det bara!

Det är många som förlorat all sin data för att man tror att det är bara att 'flytta över' diskar mellan olika NAS:ar

I det fallet är det mycket säkrare att ansluta diskar i diskdocka som körs mot ubuntu i en laptop/stationär data än att flytta diskar mellan 2 NAS:ar pga. just "nybörjavänliga" automatiken som finns i de flesta köpeNAS:ar

---

En RAID10 är inte lika säker som en RAID6

RAID10 är två Jbodade diskar som sedan där varje jbod-gren i sin tur är satt i en RAID1-koppling

Det innebär att om disk 1 (eller disk 2) går sönder i båda Jbod-grenarna samtidigt så är det kört med volymen medans det klarar sig om disk 1 på den ena och disk 2 på den andre jbod-grenen går sönder samtidigt eller att en hel jbod-gren (2 diskar) går sönder. - även RAID10 i många kombinationer klarar 2 diskfel samtidigt så är det vissa haverimatriser som det bara klarar en diskbortfall - och det är givetvis de 'förbjudna' kombinationerna som inträffar vid ett skarpt fel.

Det är inte så ofta 2 diskar går sönder samtidigt men ett läge det kan inträffa är efter plötslig strömavbrott - fick ett sådant lägen på en NAS med 2st WD-RED som tvärhängde sig under boot (diskarna frös sig fullständigt helt och ingen respons alls över SATA-busen - inte ens SMART uppdaterades att det hade varit problem) medans diskparet på varje RAID1 som var Seagate-disk klarade sig och därmed fick igång NAS:en. Efter att kollat vad som havererat var det ett dataområde på WD-RED som hade skrivits sönder - dessutom bara statisk data läses just vid boot och och inget som modifieras vid normal körning - men vid plötliga strömavbrottet hade varit där och skrivit så illa att inte ens diskdriverns läsning klarade av det eller gav några IO-fel och istället hängde sig hårt, två diskar exakt samtidigt (dock på varsin RAID1-par) - detta gick dock att åtgärda med att skriva '0' på alla sektorer från början till slut med 'dd' men efter detta litar jag inte på WD-RED, särskilt när vi hade ett sådant fall till ett år senare, också efter strömavbrott och det var återigen pardisken av Segate-typ som räddade datat.

Läxa av det är att var disk i RAID1-paret bör inte vara av samma fabrikat just för att hantera beteendefel som är olika mellan tillverkarna men lika inom samma batch av diskar.

Samma sak med RAID10 att diskar av olika fabrikat så att det som är disk 1 på ena Jbod-grenen sitter som disk 2 på den andra Jbod-grenen eller att varje jbod-gren är samma fabrikat men inte samma som den andra jbod-grenen så att man inte får ett fall som ovan med WD-red att båda diskarna '1' i respektive jbod-gren havererar samtidigt pga. fabrikat-issue efter tex. plötslig strömavbrott

---

RAID6 så klarar det 2 diskars bortfall i vilken diskkombination som helst och datat är kvar.

6 diskar är ungefär gränsen mellan att man kör RAID5 (och därmed 5 diskar som lagrar data och 1 paritet) och RAID6 där man har 4 diskar för data och 2 diskar för paritet - över 6 diskar i antal bör man alltid köra RAID6.

och slutligen - även om man fyller på en massa diskar i sin 6-slots NAS - så måste man fortfarande en uppsättning med backupdiskar som lagrar all data på NAS:en och att det synkas regelbundet och i övrig tid mellan backupperna skall vara urkopplat elektriskt och undanställda.

Det ingår att ha koll på att även backupen fungerar! - med 3-2-1 principen[1] skall det mycket till att sista exemplaret av den viktiga filen skulle försvinna.

Därför kan man inte överlåta backuphanteringen till script eller automatik eller att man litar på att någon annan gör det - för ingen gör det när det kommer till kritan och du verkligen behöver dina data... - backup är något som man själv personligen försäkrar sig att det görs och kontrollerar att det fungerar och att det går att återställa ifrån med lagom intervall.

Skall du ha underhållsfritt - samla inte på dig data som du är rädd om... annars är det förvaltning och kontroll att de är kvar och i tillräckligt många exemplar på oberoende media oavsett vad man tycker om detta.

[1]
3-2-1 principen dvs. alltid försäkrar sig att viktiga filen finns i minst 3 exemplar och aldrig blir färre än så under hanteringen när man tex kopierar mellan olika media/datorer - två stycken hemmavid (tex laptop och en backupdisk/NAS) och en off site (tex. molntjänst eller annan NAS på annan plats som det synkas mellan i lagom intervall). Detta för att klara av fallet om din bostad brinner ned.

Tar man bort filen från datorn så skall den flyttas till en annan lagring så att det _fortfarande_ finns 2 exemplar hemmavid - tex. en arkiv-disk som läggs undan förutom backupdisken/NAS:en som också har en kopia och har filerna kvar även om du missade en betalning eller fick kontot stängd för otillåten användning hos din molntjänst...

Tjänst? Man gör sig en björntjänst att tro att det är lämpligt att EN enhet både agerar lagring OCH backup. Separerar man lagring och backup är chansen väldigt mycket större att något överlever en oplanerad händelse. Själv får jag hopers epost varje morgon om sakers tillstånd och idag den 1'a i månaden fick jag extramånga då data-scrubbing utförts och diskhälsa rapporterats. dbcc checkdb görs manuellt.

Och du öppnar och läser alla SMS och email när det gäller detta?? - inte som det hände företaget jag jobbade på slutet av 1990-talet att den som hade hand om servern, att efter daglig SMS i månaders tid slutade att läsa innehållet att backuppen gick bra och bara nöjde sig med rubriken och den vägen missade i flera månaders tid att backuppen inte hade fungerat för att det inte stod direkt i rubriken... - det var en hårsmån från total haveri när man fick korruption i OLF-systemet och verkligen behövde den nyligen gjorda backuppen som inte fanns sedan flera månader tillbaka... Nej, jag var inte ansvarig på den tiden men lärde mig att hur automatiska system man än bygger upp så kan de sluta att fungera rätt som det är om man inte hela tiden kollar att de gör jobbet ordentligt.

Man kan fortfarande ha automatiska system - men kontrollen måste man själv göra manuellt då och då och det går inte att lämna vid för våg och tro att det fungerar den dagen när det verkligen gäller. Idag är den stora faran Microsoft utforcerade uppdateringar på vecko och varannan veckovis och eventuella automatiska backupprocesser med olika bakgrundsprogram kan att halta utan att man märker det.

Livsfarligt! man vill ju bara ha mail när det är något avvikande.

Livsfarligt är att inte få mail alls. Vi får mail från fler än ett system och från fler än en kund. Statusmail i den speciella inkorgen flyttas manuellt över till respektive underkatalog och spars i en månad. Detta göra manuellt varje morgon av speciellt utsedd person. Det tar ca 60 sekunder och är det första som görs på morgonen. Fler än en person ser den inkorgen. Torsk i någon av molninstanserna har en hysteres på 10 minuter, sen kommer mail även för det. Återläsning och verifiering av backupernas integritet sker på årsbasis i mellandagarna. Snapshots för DisasterRecovery görs dagligen med en veckas retention. Så gör vi och det är kunderna som bestämmer nivån och prislappen. Hur andra gör, ingen aning. Själv i hemmet gör jag backup på backupen med 3 månaders retention.

Det viktiga med backup är att den maskin som backas upp aldrig har direkt åtkomst till backupen. T.ex. i fallet med den här trådens "scope" så bör inte dators backup initieras av datorn själv utan av NAS'en som loggar in på datorn. På så sätt vet datorn ingenting om backup-NAS'en så en inkrementell backup med retention kommer att överleva ransomware i flera månader.

Ubuntu brukar kunna titta på diskarna direkt - dock om en disk är borta i en RAID1-konfig så går det inte automagiskt utan man måste pilla med argument i mdadm-RAID innan det kan monteras. De flesta lite äldre köpeNAS kör med mdadm-RAID, Synology har börja använda LVM som volymhanterare vilket hanteras på annat sätt än mdadm-RAID och inte alltid autmonteras i tex. Ubuntu ens när man har komplett diskset.

---

Alla som inte förlorat disk med unik data innan brukar säga att 'mina filer är inte så viktiga' - efter en sådan händelse brukar det vara helt annan ljud i pipan när man inser på riktigt vad man råkat ut för och känt dess konsekvenser.

Den smarte ser till att situationen inte uppstår med backupstrategi och med generationshantering av backupper då tex en ransomware kan arbeta länge innan skylten visar sig och alla backuper (som inte har generationshantering) också är krypterade...

Dessvärre måste det väldigt ofta svida rejält med kännbara dataförluster innan man lyssnar på dem som tjatar om backup hela tiden och till slut efter händelsen... - sorgeprocessen med först förnekelse att det har hänt, smärta, ilska och skuldkänslor varför gjorde man inte det och det (backupper alltså), försöka köpslå (dvs. skicka diskarna till IBAS för kanske > 20 papp i kostnaden per disk i desperation att det kanske kan ändå kan lösa problemet), depression att det finns inget hopp att rädda någon data hur man än gör och till sist acceptans över sin förlorade data verkligen är förlorade för alltid och och gå vidare och senare med erfarenheten av detta också tillhör kören som tjötar om att göra backupper

Några kan göra processen på en dag - andra behöver flera veckor att smälta detta ;-), det är samma sak med krypterade diskar och den första biten av disken är sönderskriven av någon orsak - det är då man önskade att man hade tagit ut recovery-nyckeln eller en kopia av headern av den krypterade volymen innan...

Vad annat än up-time är du ute efter? Frågans natur tyder på någon form av jag-måste-få-bekräftelse-att-det-jag-tänkt-ut-verkligen-fungerar. När du hot-swappar diskar blir NAS'ens prestanda som seg gräddkola och du knäpper händerna och ber att inga fler diskar ur samma batch lägger av medans rebuilden sker - som kan ta dygn med riktigt stora diskar.

Annat än att raid fungerar finns det inte så mycket att skriva om. När dess diskar går sönder biter man på naglarna. Har själv bara fem år på Koneo som referens där vi installerade och driftade små/mellanstora företags servrar. Bitvis jobbig tid när de berömda WD RED diskarna började lägga av en efter en efter ca 6 månader i drift. Som tur var användes de mest som backup och inte för produktion.

Uptime för en privatperson är ju inte av samma prioritet som för ett företag där man förlorar pengar när saker inte fungerar. När man sätter upp raid, än må vara skälet, bör man köpa diskar ur olika batcher eller annat fabrikat för att minimera riskerna för "plötslig död".

Har man vanlig sektorspeglande RAID så kan det ta god tid att synka upp igen och har problem om data och paritet pekar olika värden och ingen disk signalerar att den har läsproblem samtidigt... - händer inte så ofta på HW-RAID med batteribackuppad write-cache men mer ofta för köpeNAS med mdadm-RAID efter en eller flera strömavbrott kort efter varandra och inte all data har hunnits skriva lika mycket till alla diskarna och speciellt inte om diskar också har sin write-cache aktiv samtidigt (och de har dom alltid numera i köpeNAS som default för att få upp skrivprestandan...).

Att en resynkning också kan ta tid beror ofta på avsiktlig bandbredds-begränsning i syncprocessen och lågprioritet för att inte påverka för mycket på "nyttotrafiken" som sker samtidigt.

Har man filsystem som ZFS och BTRFS och de får rå om sina egna RAID-strukturer (och inte ligga på en mdadm eller lvm-RAID) så sker synkningen bara på data som har skrivits i volymerna och inte på ledig oanvänd utrymme och kör man inte lagringen toppfylld så kan man spara en del synkningstid den vägen - och båda filsystemen kan också lösa många av problem som beror på inkonsistenta diskskrivning mellan fysiska diskar efter tex. strömavbrott då de båda kör med transaktioner med jämna intervall där ny skrivning aldrig förstör den äldre skrivningen och på sätt och vis är journalförande som filsystem och kan backa i transaktioner vid olösbara fel samt att de i många fall kan lösa konflikter baserat på sina checksummor vilka av alternativen som är rätt när det finns tveksamheter.

Mycket felaktigheter ovan som behöver förklaras:

RAID10 är stripade mirrors, inte jbod, punkt. Normalt kör man två diskar i en mirror, i fallet med 6st diskar så har man 3st mirrors a 2 diskar och sedan stripas (tänk RAID0) över dessa 3 mirrors.

Det innebär att om en disk (vilken som) i varje mirror går sönder, dvs en disk från mirror1, mirror2 och mirror3 så är all data fortfarande intakt! Det är _bara_ om båda diskar i samma mirror går sönder som arrayen failar.

Det går inte heller att rakt av påstå att RAID6 är säkrare än RAID10. Jag har precis förklarat hur 3st diskar kan gå sönder utan dataloss i en RAID10…
Sen kan man inte heller bortse från belastningen som sker på diskarna när man ersatt en eller fler trasiga diskar i en RAID6. Det sker nämligen extremt mycket läsningar från samtliga diskar med RAID5/6, medans det för RAID10 bara sker läsningar från en enda disk (den disken som tappat sin spegling). Det innebär också att det går mycket snabbare att återskapa en RAID10-array än RAID5/6 med motsvarande diskstorlekar. Prestandan i arrayen under tiden för återskapning är dessutom mycket bättre för RAID10.

Det går helt enkelt både snabbare och är mindre riskfyllt i en RAID10-setup än RAID5/6.

Annat att tänka på är att i RAID5/6 kräver mer CPU-kraft (om man inte kör HW-RAID) i.o.m. paritetsberäkningar. Man bör också kolla upp skrivprestanda då den normalt sett inte skalar lika bra som RAID10. Den i mitt tycke enda nackdelen med RAID10 är att det kostar minst 50% lagringskapacitet. Jag kör själv 4x16TB samt 4x8TB i två RAID10-setuper; prestandan är kanon. Jag har även kört RAID5 tidigare och haft hårddiskhaveri; det är nervösa timmar vid resilvering (för ZFS då i mitt fall).

Således, kort sammanfattning. Raid kan aldrig ersätta backup. Raid är uptime och/eller hastighet, inget annat.

Nej. Samma som alla andra redundanta raidnivåer: Data skrivs till nya diskar som ersatt fallerade diskar.

Utan fler inparametrar är en sådan siffra värdelös.

Det beror på. Det normala för RAID5 är att den presterar som en RAID0 med N-1 diskar vid läsning - paritetskontroll görs endast om någon av diskarna returnerat ett läs- eller skrivfel och därigenom degraderat raidsetet. Skrivningar resulterar i fler operationer över fler diskar och skrivprestanda brukar landa någonstans kring N/4, jämfört med en ensam disk.

Ja det stämmer (brainfart, hade en gammal kommentar från ZFS-koden i bakhuvudet där i vissa fall writes även sker till fler diskar vid paritetsskrivning. Det verkar inte gälla längre). Dock är det fortfarande så att i fallet med RAID5/6 så stressas alla diskar av reads jämfört med enbart den speglade disken i RAID10.

Får kasta in en grävskopa salt istället för den nämnda nypan. Nej du har en bra poäng, det är bara dumt att kasta ut en siffra som kan misstolkas.

På ett ungefär indeed. Cache, ingen cache? Ser att jag inte fick med att det enbart gäller writes.

Tack för feedback, ska korrigera och förtydliga inlägget en smula.