Återskapa Netgear X-RAID

I teorin borde det gå, du kan använda dd i linux för att skapa en kopia av disken.
Hur många lediga SATA-portar har du? Det kanske är lättare att köpa npgra SATA till USB, eller ett extra SATA kort och koppla alla diskarna på en gång?

Du kan förmodligen inte lösa det på annat sätt än genom Linux och förmodligen en bunt CLI-commandon mot mdadm-RAID. Vill du inte själv sätta dig in i detta får du leta fram någon annan som känner sig lockad av jobbet - och att det görs på diskimage av de riktiga diskarna och med 'losetup' kan du skapa en bunt virtuella diskar som hanteras som egna enheter fast diskimagen ligger på samma fysiska disk.

dvs. om det är ursprungligen 6 st 2TB-disk så kan du ha alla 6 diskimagen på en 14TB disk och större när man skall börja försöka rädda data ut arrayen

---

Det är förmodligen i grunden en mdadm-RAID - X-RAID är bara namntrix i hur man hanterar diskarna och RAID-build när man tex. utökar RAID-volymen med nya och/eller större diskar och sedan utökar filsystemet - hade man kunna loggat processen så hade det varit en rad olika CLI-kommandon till mdadm för RAID:en i olika steg, att sedan göra partitionerna större och sedan en bunt kommandon för att förstora ext4-filsystemet...

När detta väl är färdigt så kommer troligen mdadmRAID kunna monteras i vilken Linux-dist som helst - kanske tom. automagiskt som med en ubuntu om den inte är markerat skadad och då måste monteringen hanteras manuellt.

Har du inte SATA-bussar i tillräcklig mängd så kan du använda USB-diskdocka eller USB-adapter för SATA-diskarna som är kvar - linux-kärnan bryr sig inte om vilken väg som datat blir synligt och det går att montera en RAID av SATA-anslutna diskar blandat med USB-anslutna diskar.

Eller så gör du en diskimage med 'dd' eller 'ddrescue' (sistnämnda mer barnsäker mot misstag) en diskimage för var disk på en stor snurrdisk som rymmer allihopa rent storleksmässigt - idag finns både 14, 16, 18, 20 och 22TB diskar som alla kan rymma 6 * 2 diskimagefiler.

använder du sparse-flaggan kan det spara en del plats om det fins stora oanvända (0-fyllda) utrymmen (för att det inte fyllts på någon data sedan tidigare på dina diskar) och lägger du diskimagen på en komprimerande filsystem som BTRFS i en mapp med kompressionsflaggan satt (genom 'chattr +c mappnamn') så minskar det en del ytterligare i platsupptagande på diskarna - att det är komprimerat kommer inte att märkas på annat sätt än att det möjligen går lite mer långsamt. och tex. losetup och senare mdadm kommer inte märka att de olika diskimagen är komprimerad och/eller sparse-form.

---

Ditt problem är nog snarare att du har skadad filsystem, förmodligen skedde efter den första avbrottet och det hela hade börjat med resync pågående när nästa strömavbrott skedde och 64 - 256 MByte data som väntade på skrivning per disk i diskarnas writecache förlorades och det blev en jädra röra rent intrigitetsmässigt, särskilt när diskarnas writechache har multisegment och olika segment skrivs i olika ordning beroende läshuvudets rörelse och datat som matas in i disken skrivs inte linjär ordning som det matades in. Inte ens BTRFS överlever om det är för stora bita data och metadata i många MBytestorlekar som det blir oreda i pga. annan skrivordningeller inte skrivits alls vid av strömavbrott avbruten RAID-synkning från andra avbrottet och fler strömavbrott. har man inte writecache aktiv på diskarna så är det typ bara en 4k-sektor per disk i RAID:en som det blir oreda på och det klarar de flesta filsystemen att hantera - men inte när många MB med data som det blir korruption på samtidigt.

Alla mer seriösa lagringar i RAID-form använder diskarna med skriv-cache avstängd och det hanteras antingen av en kontroller med egen batteribackupad skriv-cache eller att Linux-kärnan skriver mot diskarna i den ordning den tycker bäst och det får gå så fort eller långsamt det går mot diskarna (därför är det bra med mycket RAM-minne i en NAS/server) då när ext4 används så skrivs också en journal och därmed vet vilken punkt som skrevs sist ifall det bryts plötsligt under skrivningen (BTRFS har transaktioner som också bestämmer punkter där allt som är äldre än den punkten är korrekt skrivet och har checksummor som också kollar hela intervallet mellan transaktionspunkter ifall disken har slarvat bort datat pga. strömavbrott mitt under skrivning och gör rollback så många steg som nödvändigt till man når punkten som är korrekt hela vägen).

Problemet är att tidigare netgear NAS-OS (och även andra NAS-fabrikat) kunde man välja om man ville ha skrivcache av eller påslagen och en massa varningstext och säger att NAS:en måste kopplas till UPS när man slog på skrivcache - men sedan försvann det eller blev allt mer svårhittad och man körde med writecache påslagen mot diskarna som default... - varför så misstänkts för att prestandan blir lidande när writecache på diskarna är avstängda och det ser inte så bra ut i olika oberoende tester som senare görs på NAS-märket då ingen undersöker sådana saker som om diskarna skrivcache är påslagen eller avslagen vid testerna och att man behöver gå in och ändra saker innan full prestanda uppnås anses som en nackdel vid 'out of box-tester' - därav att writecache är påslagen default...

Beroende på vilket OS den har kört då kan det både vara lvm eller mdadm-baserat, det finns ett gäng guider på nätet om det (även hos Netgear själva) men du kommer garanterat behöva använda CLI för att få fram något om det ens går.

Detta program verkar kunna montera en avbildning så att Windows ser det som en fysisk disk:
https://www.osforensics.com/tools/mount-disk-images.html

Programmet "FTK Imager" påstås kunna göra båda två (skapa + montera avbildningar), men sidan jag hittade verkade halvtrasig. Folk säger att det går att fylla i formuläret och ladda hem.
Om inte annat så finns dd för Windows också, och så hemskt är det inte att använda ändå. Det finns säkerligen något med GUI också men jag har ingen erfarenhet av något då jag också är en av de som skulle köra dd i såna här lägen.

Vet inte riktigt varför ni gör det så omständigt, kör ddrescue på vardera disk, följ någon av lvm eller mdadm-guiderna så ser man ju vad som fungerar. Tvivlar starkt på att något program kommer lista ut alla lager korrekt själv.

Men herregud - när man datarräddar så köper man en (eller två) USB3-disk(ar) enkom för jobbet och i ditt fall typ 14 TB stor disk och där lägger man alla sina diskavbilder som man sedan jobbar vidare på, är det viktig data så lagrar man diskimage på den ena disken som backup/orginal och från denna kopierar ut filerna till den andra disken som man sedan arbetar på och gäller framförallt om orginaldiskarna har havererat under utläsningen av diskimagen då i somliga fall har man en enda försök på sig...

Och man gör det alltid på samma dator som man läser dina NAS-diskar via USB3-diskdocka och skriver till din USB3-diskdriver för diskimagen för att få upp hastigheten och klarar programmet (som 'dd') att läsa och skriva till diskarna parallellt så bör det vara klart inom ca 4 timmar för 2 TB och läser och skriver det efter varandra i block (som 'ddrescue') så bör det vara klart inom 8-9 timmar för 2 TB om diskarna är felfria - har man diskar som är tveksamma så använder man 'ddrescue' med 3 filargument då den är specialgjort för att hantera krassliga diskar med olika lässtrategier och envishet.

Sedan är det bra att kolla innan om den tänkta programmet du använder verkligen ger 'RAW' diskimage redan från början och inte egna specialformat som sedan måste konverteras...

Varför inte använder program som clonezilla eller liknande som startas upp från en USB-sticka då dessa är specifikt gjorda för uppgiften och utan krusiduller. Tänk på att det är 'RAW-filer' du skall ha ut som diskimage - inte komprimerade specialformat som bara programmet du använder kan hantera.

Att köra över kedjan SATA-USB-WLAN-NAS är ju totalt vansinnigt med så här stora datamängder om det skall vara klart inom det här året och dessutom kommer Wlan fungera dålig för alla inom nätet då den är hela tiden fullastad... använd åtminstone fysiska ethernetkablar mellan enheterna när du gör den här typen av dataskyfflingar om det skall transporteras mellan olika burkar, och normalt gör man det inom samma dator och mellan inkopplade diskar på datorn av just hastighetsskäl

Det gör man grafiskt med diskar nu mera i Linux Mint Cinnamon. Bara att välja disk och spara som avbild.

diskar har jag ingen aning om vad det är för något, ett separat program eller ingår det i filhanteraren (nautilus?) Finns det med även i live-imagen?

"Det gör man nu mera grafiskt" är aningen trångsynt och elitistiskt. Man använder väl det verktyg man är mest bekväm med som får jobbet gjort?

Diskar är Gnome-disks ingår i Linux Mint Cinnamon, även deras Live-ISO.

Andra valet i den högra menyn i bilden skapar en diskavbild (*.img) som är exakt samma struktur när du använder dd på hela disken (sda). Högerklickar du på en partition så får du en avbild av bara den dvs sda1.

dd har sina poäng. Men för enkla saker som att bara avbilda en disk eller partition så skulle jag säga att detta är bekvämare.

Som flera föreslagit redan, boota en live-image av Ubuntu, lyckas du koppla in alla diskar på en gång så kan den nog montera automatiskt, har du avbildningar av diskarna så får du trixa lite med losetup kanske.