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...