NAS-tips, dags att få tummen ur!

Som redan föreslagit DS420+ och för lite mer pengar DS920+

köpeNAS har i stort sett alltid använt intern filsystem baserat på ext3/ext4 och senare tid på de lite mer resursstarka NAS BTRFS då nästan alla köpenas sedan +10 år tillbaka _är_ baserad på Linux som operativsystem. Qsnap har också variant med ZFS men det är på premiumsidan prismässigt.

Detta påverkar inte med vad för OS du kör på din klientdator då överföring av filer sker via en nätverksprotokoll (SMB i windows-världen) - men filsystemen som används internt i en NAS är inget som Windows kan förstå sig på om du tar ut disk(arna) och tex. läser av dem via en diskdocka (medans troligen ubuntu förstår sig på dem)

BTRFS är en stor förbättring gentemot ext3/ext4 när det gäller hanterbarhet[1] och typiskt för nya generationens filsystem (som ZFS) också har checksummor på alla datasektorer utöver metadatat och filsystemet i sig - och det är för att i framtiden kunna täcka in väldigt stora volymer där fel rent statistikt kommer då och då när det är hundratal TB och PB-storlek, och det gäller att upptäcka dem när de kommer så att åtgärd kan göras och inte bli 'silent error' (det är inte nödvändigtvis disken som gör fel utan felen kan uppträda i transporter av data och påverkas av störningar både i chip och på ledningar).

Och det jag uppskattar allra mest med BTRFS är 'snapshot' [3] som i tex NAS möjliggör generationsbackup[2] av datat på dina utdelade nätverksenheter utan att det tar upp någon extra plats på disken (nåja 50 kbyte kanske upptas extra per backup för en nytt subvolymshuvud) - ja förutom de filer du lägger till och tar bort (som inte försvinner förrän sista snapshot som har filerna försvinner)

Tex. om du lade upp en massa kamerabilder på en utdelad nätverksenhet på NAS:en i förgår men någon annan i hushållet raderade dem idag - så finns det en 'shadow' kopia av gårdagens och förgårdagen på den utdelade nätverksenhetens data hur den såg ut då och man kan plocka tillbaka filer eller göra en rollback igen.

Eller om det härjar någon ransomware på någon (och snart flera) klientdatorer och även krypterar upp det som finns på utdelade lagring så är dessa tidigare 'shadow' backupper något som kan rädda dagen då dessa dels är dolda (om man inte gör dem synliga) och är skrivskyddade och inget i dem kan ändas.

Kruxet med er nya NAS är att ni faktiskt slår på funktionen i samband när ni skapar utdelningen och går i valen och klickar i för generationsbackup/snapshot/dataskydd eller vad det kallas då de i flesta fallen är avstängda default.

Det fins trådar här där användaren tagit bort filer ur sin NAS av misstag och efteråt försöker 'datarädda' fram filerna igen (vilket nästan inte går i många fall) och under processen upptäcker vi andra att denne använde en DSx20+ som _har_ BTRFS men inte slagit på denna funktion på sin utdelade share/nätverksenhet. Hade denne slagit på detta så hade det sparat enormt med jobb och bekymmer för personen i fråga.

Filer förlorar man inte bara för att saker går sönder oväntat - risken är minst lika stor pga. användarmisstag, ja nästan större.

Slutligen - NAS är ingen backup - NAS måste också ha backup med data av sina utdelade nätverksenheters data uppbackad på tex externa USB-diskar (som kopplas ur och läggs undan mellan backupsessionerna) då allt som är 'online' också kan påverkas av elaka program samtidigt - om man vill kan också en 3' backup göras mot en molntjänst också finns ofta färdiga Appar i NAS:en för resp molntjänst - dock med TB-mängder med data så kan det bli rätt dyrt månadsmässigt samt överföringen kan ta veckor/månader och lika lång tid vid eventuell dataräddning efter en haveri. Därför alltid backupdiskar lokalt också.

Sedan har vi nyligen också ett exempel på det som inte får hända som med Qsnaps NAS, ändå hände - Själva NAS:en blev hackad och man lät OS i själva nasen kryptera upp alla filer till 7-zip filer med kryptering och kräver förstås lösen för passordet till filerna. Därför kan man inte ha en extern USB-disk som backup vara inkopplad hela tiden med automatisk backup, utan denna _måste_ kopplas ut och läggas undan FYSISKT mellan varje _manuell initierad_ backupsession - annars blir den disken också krypterad... de flesta molnlagringstjänster har ingen generationshantering av filer (inte utan extra kostnad i alla fall - står det inget så finns det inte) - har NAS:en efter angreppet varit ifred innan det upptäcks, också hunnit synka dessa krypterade filer och tagit bort de gamla från molntjänsten, så är det sorry på riktigt...

[1]
ext3/ext4 är fortfarande bland de snabbaste filsystem man kan välja om det är skrivintensiva operationer - men alla filsystem som designades på 80 och 90-talet delar en gemensam last - de blir att de allt mer datamässigt osäkrare och risk för läsfel, hanteringsfel som inte upptäcks förrän det är försent ju större diskarna är i storlek och i en del fall också blir långsammare ju större disken är och ju mer välfylld den är med data (i familjen hör NTFS, ext3, ext4 - alla FAT-baserade filsystem, olika applefilsystem (kan inte namnen på dessa) i ext3/ext4 fick man i alla fall in checkvärden (CRC32C) på sin metadata och filsystemstruktur som upptäcker oönskade förändringar/läsfel men tex. NTFS har ingen sådan skydd alls)

[2]
och timeline-rensning av gamla backupper enligt plan (så att man inte får för många av dem över tiden - blir annars jobbigt med 365 backupper efter 1 år

[3]
BTRFS har snapshot utan generationsberoende, ZFS har inte samma frihet utan är ordningsföljdberoende inom dataseten, i BTRFS kan man radera vilken snapshot som helst i vilken ordning som helst - vilket gör att utglesning enligt plan/mönster (timeline) är lätt att implementera medans i ZFS är enorm jobbigt att utföra samma sak då man inte kan ta bort en snapshot i en tids-linje av snapshot för en data-set utan kopieringar och påslagen deduplicering (för att det skall få plats på disken under operationerna)

- Den dagen (open) ZFS någon gång implementerade "reflink" (som senare kommersiell och stängd ZFS har) så skulle det underlätta väldigt mycket för den här typen av backuputglesning, utan att man måste ha deduplicering påslagen (och gör filsystemet långsam och väldigt RAM-hungrig) och massiva datakopieringar för var generation, men just "reflink" har gurglat i open-ZFS i +10 år och ingen kommit till skott... vill man läsa hur 'jobbigt' det är att implementera timeline-backuputglesning av snapshot i ZFS, kan läsa om alla steg som måste företas i ZFS i manualen för 'Urbackup' samt man behöver en stor server för att orka med detta.

Betrakta NAS-hårddiskar från WD, Toshiba, Seagate med samma ögon - dvs. en disk kan gå sönder efter 14 dar oavsett märke och du hanterar det. Det som kan avgöra om man är större användare med större servrerpark är hur smidig returhanteringen är av diskarna.

är det butik-köpt så är det vanlig konsument-garanti.

dock är det lite skillnad mellan fabrikaten ändå.

WD har sabbat anseendet av WD-RED rejält när man blandade in SMR-diskar med PMR-diskar i de mindre storlekarna och trodde att det skulle klara sig ändå och sedan lurar man med varvtal på diskar etc. för de som ville ha långsamtsnurrande disk för tystnad men fick ändå en 7200 RPM-disk mätt akustiskt i handen fast i SMART säger 5400 RPM... och alla diskar som köps från WD är numera HGST-diskar - det är inget fel i det, HGST hade mycket bra diskar, bättre än någon annan tillverkare faktiskt, men som WD blandar korten under bordet så har man hamnat i ett läge att du beställer en viss disk men du får något annat...

Toshiba har fungerat bra för mig men har tydligen haft en sväng med diskar som fallerar tidigt men är förmodligen övergående batch, råkar man ut för dem får man använda sig av garantin - Toshiba-diskar har en gång i tiden varit HGST-fabrik så kvaliten i grunden bör fortfarande vara i HGST-klass, men alla disktillverkare har dåliga serie då och då

Seagate har för närvarande de sista åren fått minst 'skit' på sig och de har gjort en kvalitetsresa att närma sig HGST i felutfall för deras stordiskar nu när tandon-tillverkade WD-diskar (tidigare WD-RED mfl. innan de ersattes med hgst-diskar) nu försvann helt från WD:s repertoar. - tidigare låg Seagate och WD ganska jämt där och HGST lyst som en stjärna med halva felutfallstakten.

Om det inte är ljud som knack vid sökningar och annat som kan höras mer vid snabba diskar så skulle jag gå på Seagate eller Toshibas NAS-diskar (ta den billigaste du hittar för tillfället) då båda av dem är snabbare än WD-diskar i regel.

WD om man jagar tysta diskar (och därmed långsammare) men med reservationen för risken att du tror att du köper en långsammare 5400 RPM-disk men får en 7200RPM-disk i handen ändå... _om_ du skall köpa WD-RED så måste det vara WD-RED plus-diskar för diskar under 8 TB - annars får du SMR-diskar, och det vill du inte ha!

Vi som föredrar gamla Prisjakt
https://classic.prisjakt.nu/produkt.php?pu=3795752

Dom har ett verktyg så man kan se var kapaciteten hamnar.
SHR är rätt bra på att ta till vara på utrymme om man kör med olika diskar.
https://www.synology.com/en-global/support/RAID_calculator

med så många NAS borde du också veta att även NAS behöver backup...

netgear mfl använder inte BTRFS inbyggda RAID-funktion utan var en singelvolym liggande på en mdadm-RAID som skötte RAID-hanteringen - så svär inte om att man nyttjade oprövade funktioner, för det gjorde man inte.

Men fel fanns ändå och Netgear (och även andra NAS-tillverkare) spärrade inte att volumerna får vara max 16TB stora om det är 32-bitars ARM i burken - generellt har man denna rekommendation för alla 32-bitars OS om man läser lite då man inte lyckats debugga alla libbar från 32-bitars gräns och wrap-over risk (ger 16 TB med 4096 bytes sektorer)

Det du förmodligen råkat på är att lite över 16 TB-fyllnad så började det att skriva på början av partitionen igen pga. 32-bitars wrap-over och buggiga diskdrivrutiner och det upptäckte BTRFS väldigt snabbt då checksummor plötsligt inte stämde och gick i readonly-mode - på en ext4 hade det förmodligen skrivit sönder mycket mer på disken innan det upptäckte att något var galet vid samma typ av bug...

I det läget skall man absolut inte stänga av nasen utan man gör backup på allt på diskarna då det som finns i RAM-minnet för filsystemet fortfarande är korrekt i NAS:en, det är när man startar om och all data i RAM har försvunnit som man får sin förlorade volym då överskrivning - även om den inte hann så mycket ändå skrev sönder viktiga filsystem-sektorer i BTRFS och bootprocessen hitta ingen när volymen skulle monteras.

Dock har jag för mig med lite olika prov att man kunde få tillbaka > 99% av datat med 'btrfs restore' - det fungerade för mig när jag hade hamnat i ovanstående situation och analyserade vad som hänt och konstaterade att det var en 32-bitars wrap-over-problem - nu hade jag backup på precis allt men provade ändå och jämförde fil för fil med rmlint och det var inga filer som var korruperade och nästan alla filer fanns utom just de sista som inte skrivits färdigt när det krashade, det jag missade på var att skicka med flaggor för tidsstämplar och rättigheter vid btrfs restore och iddes inte köra om allt igen då det tar en stund att hantera dryga 16 TB.

Vid den tiden var 8 TB-diskar väldigt nytt och NAS-tillverkarna hade inte hängt med i svängarna att folk faktiskt kunde skapa 16 och 20 TB-volymer på en 4-disk NAS med 32-bitars- ARM-propp (mycket mindre debuggad än intel-propp) och riskera 32-bitars wrap-over bug och dessvärre heller inte prova det själva och det blev användarna som blev försökskaniner.

Senare versioner av OS klarar volymer > 16 TB utan missöden men det tog ett tag då NAS-tillverkarna som vanligt väntar på varandra att någon annan skulle göra jobbet och leech:a på detta och inte bidra med något själva (det var samma historia med ext4 på tidigare modeller - att det blev tvärstopp när man fyllde diskarna en bit över 80% fyllnad och det tog flera år innan det fixades och alla samtidigt när det skedde och samma dag i stort sett på samtliga NAS-tillverkare - vilket de som bytte NAS-tillverkare i affekt snabbt upptäckte att det var samma skit på buffalo och Qsnap samt Synologys billigare modeller där också - för att alla använde samma Linux-OS generation med samma buggar i sig!!! i det här fallet att hantera journalen men knappt har någon RAM-minne alls för att göra jobbet)

OK, det var inte meningen att riva i gamla svidande dataförlust-sår där man lär sig att backup är viktigt den hårda vägen, utan mer indikera en väg att det kanske finns en chans för att rädda ut filer ur BTRFS-volymen om du råkat på samma bekymmer som jag råkade ut för i inledningen när BTRFS var nytt och oprövat med just stora volymer över 16 TB på 32-bitars ARM-proppar (och netgear var inte ensamt då alla som försökte på det i ARM-miljö hade samma fel då det i grunden berodde på använda linux-kärna som också var lika hos alla NAS-tillverkare).

Och problemet med 32-bitars 'wrap over' vid den tiden gäller inte för hela disken utan gäller för data inom partitionen/volymen över 16 TB storlek som innehöll BTRFS, därför var den inledande 4 GB-partitionen och swap-partitionen oskadad - om felet skapades av själva mdadm-RAID eller av BTRFS själv vet jag inte, och det fixades också senare - det jag vet av Netgears enheter (då jag har sådana själv) inte nyttjade någon av BTRFS egna olika RAID-moder utan det var en enkelvolym liggande på en RAID och man lät mdadm-RAID sköta själva RAID-delen, och så är det än idag för det flesta köpeNAS med eller utan BTRFS som filsystem. (Synology använder numera LVM istället för mdadm-RAID för sin RAID-byggade vilket knappast gör det enklare vid en RAID-haveri)

---

Du skrev nu att det var hantverkare som bröt strömmen hela tiden till NAS och mdadm-RAID (som singelvolym BTRFS ligger ovanpå), som används av nära alla köpe-NAS, är inte tålig mot strömavbrott medans det skriver data och har man diskarna med write cache aktiv (vilket numera är default och tom. svårt att hitta var man stänger av den och drabbar diskprestandan _mycket_) så blir skadorna än värre.

KöpeNAS idag skall idag alltid köras via en UPS och kontrollerad nedtagning när batteriet i UPS tar slut bl.a just för att man har diskarnas skrivcache aktiva.

Har mdadm-RAID:en dessutom varit i synkning när nästa strömavbrott kommer så har troligen skadorna blivit ännu värre då det läser och skriver sektorer hela tiden och därmed massa uppdaterad data i diskarnas write-cache som inte hinner ut på diskytan när nästa strömavbrott kommer och det ökar på inkonsistensen på RAID:en och slår igenom som datakorruption på den ovanförliggande filsystemet och beroende hur långt det hunnit i resynkningen sedan förra avbrottet och håller det på upprepande så kan det hacka sönder hela volymen fullständigt - och det är mdadm-RAID som hackar sönder just för att resynkningen hela tiden startar igen var gång NAS:en startar - inte filsystemet ovanpå oavsett om det är ext4 eller BTRFS!!!

Jag skulle säga att majoriteten av alla köpeNAS RAID-haverier är i grunden beroende av att man använder mdadm-RAID för att bygga sina volymer och sedan utsatts för strömavbrott medans det skriver, och mycket dåligt med verktyg att sedan försöka reparera den och läsa ut det som är oskadat i efterhand tyvärr. Kort sagt är det mer eller mindre dumförklaring när man läser kommandon för mdadm och när man försöker rädda data ur en mdadm-RAID med minimalt/icke existerande metod att få ut loggar eller debugg-kod (skrivs inte ens något vettigt i dmesg) på vad som felar när man inte får ihop sin RAID...

- man rödflaggade BTRFS RAID5/6 för att den ibland inte klarade strömavbrott och att disk havererar samtidigt och tycker det är skandalöst - med samma kriterium så skulle jag sätta minst 3 stora vajande rödflaggor för mdadm-RAID då det haverera ofta även när diskarna är friska efter strömavbrottet! men det får man ju inte prata högt om då mdadm-RAID är sååå respekterat trots att det smäller här och där i olika NAS och ofta i samband med just oplanerade strömavbrott.

I ditt fall om du har image kvar av diskarna så är grundproblemet troligen att din mdadm-RAID har kraschat av strömavbrotten - inte BTRFS (dock kan fått skador av det som konsekvens av skador i den underliggande RAID:en).

Kan du få ihop denna till en läsbar volym igen med att bråka med mdadm-RAID verktygen så att på mdadm-RAID liggande BTRFS-volymen går att läsa ut som en stor fil (brukar vara /dev/md127 om man fått ihop mdadm-RAID) - så finns det en chans att kunna rädda ut data - kanske direkt med att montera den (om du kopierar ut BTRFS-filsystemet direkt i RAW från första sektorn mot en tom och tillräckligt stor extern USB-disk) eller med btrfs restore-funktionen extrahera ut filerna. Gör det på en modern linuxdist då verkygen för att hantera och läsa BTRFS-filsystem också förbättrats med tiden.

Själva BTRFS är relativt tålig mot plötsliga strömavbrott även mitt under skrivning av anledningen att den är transaktionshanterande och heller inte skriver över redan skrivna sektorer som är valida inom filsystemet (COW-funktionen) - det gäller också metadatat. Transaktionernas mellanrum brukar vara var 30 sekund och tätare vid mycket skrivning - så, ja man kan missa de sista 30 sekunderna skrivning vid plötslig strömavbrott, men inte mer än så.

Därmed kan den göra en rollback i samband med montering efter strömavbrottet till senaste valida fullt skrivna transaktion i fallen där skrivningen avbröts av tex strömavbrott (eller glapp eller ur-ryck av i USB-sladd som allt för ofta sker med externa USB-lagring) och checksummorna på sektorerna har koll om skrivningen är valid eller inte. I de fallen kan monteringen ta lite mer tid än normalt men man skall inte ge upp hoppet och få panik även om det kanske tar minuter, då det alltid hittar ut med en monterad disk och alla filer åtkomliga.

Jag använder BTRFS (och med dubbel metadata) för alla mina backupper idag på extern media av den anledningen och hittills aldrig någonsin råkat ut för att en extern disk med BTRFS-filsystem inte är monterbar eller att det inte går att läsa filer ur den - det kan jag inte säga om NTFS och på den filsystemet haft mycket svidande dataförluster som inte ens R-studio lyckades plocka fram något vettigt i kvalitet utöver ren datascrape - och detta bara för att bara 2 sektorer blev överskrivna med slumpvärden (USB-SATA-chippet i den externa USB-disken av WD gjorde det när avstängningskommandot för enheten kom för tätt på efter sista sektorerna skulle skrivas - första sektorn i $MFT och $MFT_mirr... de två viktigaste sektorerna i hela NTFS-filsystemet som alltid skrivs om sist när filsystemet stängs och läses först när filsystemet monteras och är grundbulten där allt rasar utan dem!!!)

Det stämmer att BTRFS är en "Linux-grej". Å andra sidan är nästan alla NAS Unix/Linux i botten. Det här syns dock inte eftersom datorn ser din NAS som en hårddisk som är ansluten via nätverket.

Sedan vill du garanterat köra BTRFS då det är ett modernt filsystem som har inbyggd felhantering, journalföring, rättigheter på användarnivå samt inbyggd checksumma på filer.

Just journalföringen är intressant då den kan rulla tillbaka en ändring av en fil, alternativt köra den en gång till. Vilket skyddar vid strömavbrott. Däremot är en UPS ändå ett bra skydd eftersom den skyddar mot mer än bara strömavbrott och ger en renare el (beror mycket på märke / kvalité dock).

Journalföringen fungerar kort förklarat som att ändringen i en fil skrivs till en journal, journalen verifieras. Sedan görs ändringen i filen. Filen verifieras. Journalen tas bort/markeras som slutförd.

Om ett strömavbrott inträffar så kan man göra om dessa steg. Skulle filen inte verifieras så kan man göra om hela processen. Skulle felet inträffa tidigt i journalen så anses ändringen inte finnas som om filen aldrig sparats. Med andra ord får man aldrig en fil som är någonstans mitt emellan.

I princip körs allt sådant här automatiskt så inget man behöver oroa sig för. Senast jag behöver göra något sådant manuellt var när jag hade en disk som var fysiskt trasig, för över åtta år sedan.