Panik: varning för lite helium vad göra för att rädda disken?

Permalänk
Medlem

Panik: varning för lite helium vad göra för att rädda disken?

Fick en varningsmail från min server som är en proximox

The following warning/error was logged by the smartd daemon:

Device: /dev/sda [SAT], Failed SMART usage Attribute: 22 Helium_Level.”

Jag stängde av den Remote direkt är på semester och har ingen möjlighet att göra något förens om 1 vecka.

Det är en disk bara och kör ingen raid

Vad bör jag göra för att rädda allt som går att fixa.

Kan beställa en ny 8gb disk så jag har den hemma.

Är formaterad med btrfs

Permalänk
Medlem

Risken finns att den läker även om den är avstängd, så har du värdefull data du absolut inte kan bli av med så hade jag lämnat in disken till en firma.
De kan säker "fylla på" med helium, iaf tillfälligt och rädda datan.
Är den inte så värdefull att du hade betalat för det så är de bara att försöka kopiera så mycket som möjligt till en ny disk.
Blir troligen billigare att lämna in den innan den gått sönder, så jag skulle inte försöka först för att lämna in senare om det inte går att fixa själv.
Du kan ju höra vad de skulle kosta. Kan tyvärr inga företag som gör det.

Berätta gärna hur de gick oavsett hur du gör.

Permalänk
Medlem

Är data mycket viktigt - diskräddningsfirma, men räkna med att det blir dyrt på riktigt..

tittade på forum som hddguru och hddoracle

Där är det olika bud - en del säger att de fortfarande fungerar 'dataräddningsbart' med luft, andra säger att det inte vill ens starta om inte heliumhalten är rätt, tredje med provad heliumåterfyllning men slåss med att då den hela tiden adapterar långsamt att steget när man fyller med helium blir så stort skillnad att adapteringen inte klarar steget att det inte längre fungerar.

nu har jag inte scannat igenom alla case där eller vad som skrivs om heliumfyllda diskar från nutid - mycket av det som skrivs är mjukvaruproblem eller man skall hacka sig förbi passords-stängda diskar för att de skall bli användbara eller för dataräddning...

Mycket av folket på dessa forum jobbar yrkesmässigt med diskräddning - somliga med mer resurser inklusive lasersvetsar och CNC-maskiner i renrum och tydligen är det rätt besvärligt med he-diskar när det gått förbi nivån när det inte vill starta eller att huvudena stötts ur och fastnat på skivan.

Diskarna är byggda som konventionella diskar men har en lager aluminiumfolie modell CC-burktjocklek som är lasersvetsat efter kanten utanpå som lager utanför där man normalt har etikettsidan.

---

Om det inte är så värdefull att du är beredd att lägga flera tiotusentals kronor i räddningen så skulle jag i det läget starta upp disken igen och fort som fasen göra en diskimage-kopia av disken med ddrescue...

när man fått upp den andra disken, allt fungerar och ytterligare gjord backup, så skulle jag bara för nyfikenhetens skull lägga den här disken (med wipade startsektorer för BTRFS ) och låta den bli en disk 2 i en native BTRFS RAID1, veckovis scrub och sedan se hur länge den håller utan för mycket skriv och läsfel nu efter den börja ge varning för helium-nivå.

---

Slutligen - blir man nervös när en disk börja visa feltecken så är det verkligen dags att titta över sin redundans och backupstrategi - en möjlig diskhaveri skall inte resultera i dålig nattsömn - har man det så finns jobb att göra för att förbättra det hela.

Permalänk
Medlem

Om det är WD/HGST-diskar så har de ingen egentlig specifik heliummätare av mems-typ i sig utan mätningen görs av en termistor som värms upp och och ser hur mycket ström som behövs för att hålla ett visst antal grader varmare än omgivningen och bygger på att helium leder värme typ 6 ggr mer än luft.

När för mycket helium ersatts med luft så kyler det inte lika mycket så får man den här typen av varning och det beror på flera orsaker som gängningar har gått lite för långt, pressgjutna chassin med porer i materialet mm. - tekniskt sett byggs en heliumfyld disk inte för att klara sig längre än för 5 år innan felutfallen börja öka och rekommendationen är att aldrig köra heliumfyllda diskar för data som det inte finns redundans eller backup på - diskarna är tänkt för datacenter från början och där har man så mycket redundans att man inte bryr sig - men det blir problem när det går över till privatanvändare och tex externa USB-diskar där data faktiskt inte ligger på mer än en disk, extra viktigt när de som håller på med diskräddning har stora bekymmer med dem - ännu.

nedan ger en viss indikation att he-diskar har en chans att fortfarande fungera med mycket låg kvarvarande värde på heliumet men blir betydligt hetare

http://www.hddoracle.com/viewtopic.php?f=21&t=2549&p=20626&hi... (lite mer hardcore HD-folk som hackar i hd-firmware mm. än i forumet hddguru - men de hänvisar till varandra hela tiden så det är i stort sett samma klientel)

Eftersom du fick larmet nu så har du förmodligen en kortare tid att göra kopia av disken till en diskimagen innan det gått så långt att det blivit ett ohanterbart problem. Av tonen på forumet så verkar man inte vilja ta sig an diskräddningsuppdrag på just He-diskar just för att chansen att lyckas är så lågt.

---

en annan sak man sprang på så här efter SMR/CMR- debaclet - en del av WD 5400 rpm-diskar är tydligen inte 5400 RPM.... (mätt deduktivt baserade på söktid och akustisk analys)

http://www.hddoracle.com/viewtopic.php?f=7&t=2768&p=20989&hil...

http://www.hddoracle.com/viewtopic.php?f=21&t=2549&p=20655&hi...

Om man tex kör hd-tune så om bandet av punkter för söktider är 8.33 ms brett mellan högsta/lästa inom smalt område så är det 7200 RPM-disk medans är den 11 ms brett så är det en 5400 rpm-disk - sedan kan man använda mobil eller mick och spela in, gärna med huvudet parkerad och när den sedan läser och sedan gör man FFT-analys (spektrum-analys) i lämpligt ljudprogram och ser var högsta spetsarna ligger - är det 120 Hz så är det 7200 RPM medans är det 90 Hz så är det 5400, är det 98.33 Hz så är det 5900 RPM

Permalänk
Medlem

Nu har jag beställt en ny disk exakt lika ( möjligtvis nyare version) det är en WD RED 8TB.

Så vad är det bästa nu att boota server med och göra en kopia från ena till andra så snabbt som möjligt och utan att jag råkar göra från fel disk?

Permalänk
Medlem

@jan-banan:
Som de sades tidigare, har du råd med total dataförlust. Fortsätt själv, är datan kritisk? Vänd dig till experter som IBAS.

Vill du göra det själv så sätt upp en egen miljö först, där du bootar direkt in i ett program för att klona disken eller kopiera data. Testa systemet med två andra diskar först. Och när du har ett system för att snabbt och effektivt föra över/klona datan i ett kör, inte förrns då kopplar du i helium disken och gör det fort i en redan förberedd miljö.

Men risken är att läshuvudena kommer repa ytan och förstöra sig själva. Heliumet behövs.

Permalänk
Medlem
Skrivet av jan-banan:

Nu har jag beställt en ny disk exakt lika ( möjligtvis nyare version) det är en WD RED 8TB.

Så vad är det bästa nu att boota server med och göra en kopia från ena till andra så snabbt som möjligt och utan att jag råkar göra från fel disk?

Som redan sagt - prova med andra diskar till du känner dig säker på momenten - ddrescue - har barnskydd i form att den inte kan skriva direkt mot blockdevice (utan flaggan -f) utan bara till fil så att du inte skriver till den imagen som du skulle försöka rädda bara för att du tog fel på dev/sdc och /dev sdd tex. - medans 'dd' (nicknamnad till 'disk destroyer' så kan man bli blodig om man inte håller tungan rädd i munnen...

Om du kikar på de andra diskarna med helium - var är det satt för treshold-tröskevärde på pos 22 - somliga modeller men inte alla vägrar att starta disken om heliumnivå är för lågt - antagligen för att en del får direkt mediaskador om man försöker starta disken med för låg heliumhalt medans andra som startar utan någon spärr för låg helium kvar kanske klarar det ändå med stor andel luft men inte optimalt (dvs går väldigt varmt) - typ att de håller för en diskimagekopia och lite till. ...

En heliumdisk som tappar helium och gasmängdesn ersätts med luft så kan det gå upp till 40% tyngre vid ren luft av högre viskösa förluster än med ren helium i kabinettet - vilket gör att den kommer att gå varmare ju mer helium som försvunnit gentemot diskar som har kvar heliumet - detta kan ge indikation om hur långt förlusten av helium är gången och därmed om man vågar att starta disken igen.

du tog händelsevis inte smartctr-värdena på alla dina diskar i din server strax innan du stängde av servern - det hade varit ganska behändigt nu i bedömningen om den skadade disken vågas att startas eller inte eller skall gå direkt mot diskräddningsfirma.

Permalänk
Medlem

Vem är jag skyldig en bira?

Lyckades klona disken med clonzilla

Permalänk
Medlem

Smart 22 uses fly height to calculate He levels. So it could trigger from fly height changes in the drive due to lube buildup or just head loading. If you don't see damage around the Helium seal, it's likely not a true leak. Either way you may still want to RMA the drive as it has tripped SMART as it's an early fail warning.

Permalänk
Medlem

Härligt att det löste sig!
Alltid kul när man får redan på hur det gick (många trådar som bara dör ut).

Permalänk
Medlem

vad bra att gick bra - gissar att det är slutkört med Jbod/RAID0 utan backup eller redundans efter detta - ibland behövs lite näradödenupplevelse inom lagring innan man tar tag i detta.

Permalänk
Medlem

Jag har i och för sig inte testat alla filer så ska väl inte ta ut allt i förskott men snabb koll och fick inget ettor i clonzilla.

Jag står men köpknappen på en synology + Ett gäng diskar. bara för ha något säkert och köra backup på någon backuptjänst.

Precis ibland behövs en sådan här upplevelse men jag har velat köpa en synology länge men har väntat på att de skulle ha 10gbe som standard i deras system men nu skiter jag i det och slår till.

Permalänk
Medlem

Du hade fått läsfel - I/O-fel om disken inte hade kunnat läsa sektorer - nu vet jag inte hur clonezilla agerar i fellägen men annars är ddrescue valet när man börja med diskar som visar I/O-fel...

felkollen av sektorer i en snurr/ssd-lagring är väldigt stark - starkare än dataskyddet på SATA-bussen när det gäller oupptäckta bitfel (ligger runt 1*10^-21 för misskorrektion för en disk med 1*10^-14 i BER i avseende för risken ej rättningsbara och oläsbara sektorer) - så oupptäckta bitfel när man läser ur disken är i stort sett inget som händer - antingen läses korrekta data ut eller så har man I/O-fel.

---

Om du monterar BTRFS-filen eller imagen (readonly) med med losetup och gör scrub så bör du kunna få reda på om det finns integritetsproblem på filerna. - ha koll på dmesg under processen då det är där det börja spotta felmeddelande vid intrigitetsfel.

Med btrfs och zfs har man ju chansen att kolla det medans ext4/NTFS har man ingen aning om filkroppen på en fil är komplett eller inte eller att veta vilken fil som skadats om man börja få IO-fel under skapande av diskimagen då sådant inte syns i senare steg när man läser från diskimagen i och med att diskimagen inte ger IO-fel.

Permalänk
Medlem

Då du redan har BTRFS så är det inget svårt att omvandla en singeldisk till en RAID1-motsvarighet

det görs med "btrfs dev add /dev/sdx_nya_disken /path/btrfs_filsystemet".

med det steget har man bara ökat filsystemets storlek med en extra disk.

det viktiga är steget senare (och som ZFS inte har någon motsvarighet för och lider svårt av avsaknaden för en del brukare)

"btrfs balance start -dconvert=raid1 -mconvert=raid1 -sconvert=raid1 /path/btrfs_filsystemet"

efter något dygn eller så så har hela diskens filer konverterats så att varje fysisk fil finns i 2 exemplar på två fysiska diskar, samma sak med metadata och systemdata. - obs det är inte RAID1 på klassisk sätt med sektorspegling utan samma fil kan vara utplacerade på olika fysiska platser för resp. disk.

detta gör att synkningen inte speglar hela diskar utan speglar bara mängden filer vilket gör att balance/synkning går fortare om diskarna bara är till en del fyllda.

sätter man en ytterligare disk till filsystemet och gör balance så är det fortfarande RAID1 och tål bara en disk bortfall men datat fördelas så att varje fil läggs alltid på två fysiska enheter och man kan ha diskar med olika storlek så pusslas det så att gemensamma utrymmet där en fil kan lägga på två fysiska diskar utnyttjas så mycket som möjligt.

---

man kan också med balance och minst 3 diskar med hyfsat samma storlek på samma sätt som innan istället med RAID1 istället ange argumentet 'raid5' för att skapa RAID-5 diskarray.

Även om det skrivs (och numera rätt gammal info som inte uppdateras...) att BTRFS RAID5 och RAID6 anses har ha corner cases de inte hanterar och därmed rödflaggas, så har jag personligen haft mer problem med mdadm-RAID med delvis förlorade filer (gav IO-error - även läst i nivån under filsystemet dvs. direkt på dess virtuella image ) på oförklarligt sätt och det var inte beroende av underliggande diskars fel (i vart fall i avseende IO-fel) eller kan kopplas till strömavbrott - men inte sett motsvarande 'haveri' med BTRFS RAID5 ännu trots mer än enstaka plötliga strömavbrott.

Har kört på prov i ett par lek-servrar med BTRFS i RAID5 med många 300GB diskar i säkert nu över 3 år varav den ena fick utslängda diskar kort efter varandra (P400-SAS-kortet som kickade ut dem) och där hade inte BTRFS något problem att överleva eller ge några filförluster.