NAS - Vad ska man gå för?

Värt att nämna är att en hel del NAS-ar kan backa upp valda mappar automatiskt mot molnet dessa dagar. Så man kan skaffa ett konto på ex Amazon S3 eller Backblaze (eller onedrive/dropbox) för att få en extra katastrofkopia. På de förstnämnda betalar man bara för det man använder, och för S3 "glacier" är det ca 4,5 öre per GB i månaden. (så länge man inte behöver ha sina kopior direkt, samt är beredd att betala lite mer vid nedladdningen - katastroflagring dvs)

Har själv en Asustorlåda som jag växt ur, men jag gillade den i övrigt. Den har de relevanta apparna och är lätt att arbeta med. Men jag misstänker att det samma kan sägas om Synology och Qnap med. Skulle dock säga som ovan att 4:a diskplatser är att rekommendera, diskarna har en tendens att vilja ta slut (och det ger möjlighet att köra raid5 för lite redundans). Jag trodde att jag aldrig skulle växa ur 4x4TB, haha vad ung och naiv jag var...

Ingen fel ha en offsite-lagring (aka katastof-lagring) hos nämnda molntjänster - men ha också en lokal kopia på externa USB-diskar - om inte annat så går det väldigt mycket fortare att återställa från en extern usb-disk än om man skall tanka alltihop från en molntjänst där man får vara glad om det går fortare än 20 MBit i överföringshastighet (även på en 100Mbit-lina) då det trottlas hos molntjänsten eller på vägen mellan.

Jag har kört BTRFS rätt mycket och är typ 3 - 4 året utan oväntad incident (dock har jag framkalla incidenter för att tex se hur BTRFS recovery-program kan få fram filer igen ur en havererad filsystem - till skillnad från NTFS så har den ett antal magic word och andra markörer samt kännedom hur B-tree i BTRFS fungerar i detalj som gör att det mesta datat går att återvinna i felfri form, med korrekt path, rättighter, tidsstämpar etc., dessutom om man vill kan man ha dubbel/RAID-uppsättning av metadatat och den andre är kvar om de första blir sönderskriven av någon orsak tex vid en diskstängning/avmontering (det var så jag förlorade data i NTFS när jag gjorde rätt enligt konsten alla regler i windows, hade jag bara ryckt ut USB-sladden utan avmontering före så hade det klarat sig...)) och tycker nog att BTRFS får ibland oförskämt mycket skit, med ibland med hänvisning i dag rätt gamla saker och många av dem redan fixade då det åtminstone med min användarmönster har fungerat alldeles utmärkt och är väldigt resilient och ger alltid en filsystem som går att använda på tex. backupdiskar trots att man klantat sig med både kraftförsörjningar och glappa USB3-kontakter mitt under skrivningar med hög datamängd , inklusive på disksets med mer än en drive tills samma filsystem då man lätt utökar när förra disken blir full.

Det är sant att BTRFS kanske inte når upp till ZFS när det gäller datasäkerhet, men å andra sidan så är det mycket mer flexibelt och det är känt att det finns några corner cases som den ännu inte hanterar så bra (som tex. en plötslig strömavbrott och en diskhaveri samtidigt, men å andra sidan så har jag folk i bekantskapskretsen som fått havererad ZFS också, sökt hjälp och pratat med de som verkligen kan zfs på närmast nördnivå så att saker och ting i dom lägen görs i exakt rätt ordning för att det hela inte skall haverera ohjälpligt) - men ändå är det hela skyhögt mycket bättre än tex.backuplagring på NTFS, det är på NTFS jag förlorat svidande mängder med data trots alla tänkbara räddningsförsök efter händelsen - tror jag provat alla linux ext-versioner mm. och inte ens varit i närheten i dataförluster (dvs. mer än enstaka filer) som NTFS åsamkade mig...

På de flesta köpeNAS som hanterar mer än 16 TB och/eller erbjuder snapshot för generationsbackupper så körs en BTRFS på en mdadm-RAID, och skiter sig mdadm-RAID så skiter sig också BTRFS ovan på denna då BTRFS inte själv rår om diskarna i den här konfigurationen och det finns flera situationer där man kan haverera en mdadm-RAID som tex plötslig strömavbrott under skrivning.

När man hör folk, både privata och på företag där en köpeNAS havererat efter en strömavbrott - så är det nästa alltid en mdmadm-RAID haveri i botten där RAID har hamnat i en situation där det konstaterar olikhet mellan samma sektornummer på RAID1 eller pariteten inte stämmer med datat som skapade pariteten när det börja läsa in filer, men likt åsna mellan hötappar inte kan avgöra vilket som är rätt data och det hela stallat - då spelar det ingen roll vilken filsystem som är ovanpå RAID då det aldrig kommer ens så långt att det frågar...

Hade BTRFS (och ZFS...) själv rått om diskarna så kanske det var enstaka filer som gick paj om det inte fans nog redundans att reparera och då hade man fått reda på det - inte att hela NAS:ens filer blev inslåsta och inte kommer åt en enda fil...

Skall få bättre strömavbrotts-resilens på en mdadm-RAID så måste man allokera utrymme och aktivera skrivcache (som skrivs fysiskt på disken hela tiden vid diskaktiviteter) och förstås prestandaförlust med detta, och i praktiken inte är påslaget av den orsaken. Man kan förvisso förbättra strömavbrottsresilensen på andra vägar med separat SSD som agerar disk-skrivcache mm. men är lite av lapptäcke än tex. med ZFS.

---

Det finns inget alls som hindrar att man kör ZFS på sin NAS (såvida att det finns tillräckligt med propp och minne för det) och sedan använder BTRFS på sina backupdiskar då det är så otroligt enkelt med snapshot att göra generationsbackupper med BTRFS så att man inte sopar bort sin förra backups original när man med nästa backup skriver över med ransomware-krypterade filer - det enda man ser om det händer och man får ner en oönskad krypterad filsets är att diskutrymme försvinner... - och i situation när disken är full så kopplar man en disk till till sin backupvolym med en 'btrfs dev add /dev/xxxx /mount_backup_fs' och sedan fortsätter man med sin backup som nyss inte fick plats.

Har haft ett par disk-set på det sättet (ovanpå en lucksCrypt på varje disk, och i Ubuntu får man snällt en passordförfrågan för varje disk och när alla är upplåsta för diskseten så monteras BTRFS automagiskt) och det har aldrig hittills misslyckats att montera de två diskarna till en och samma BTRFS-volym och volymen fullt användbar trots 'olyckor' som att man ryckte strömsladden till den ena disken under full backup, det mer än en gång...

Jag personligen gör ingen jämförelse med ZFS då jag helt enkelt inte kört den eller lärt mig vad den kan - då BTRFS helt enkelt har fungerat för bra för min typ av användande att jag inte känt behov att leta vidare i avseende 'bättre' filsystem.

Som redan sagt - kan inte speciellt mycket om ZFS och vad den kan, men det jag vet med egna prov och praktisk användande över längre tid är att BTRFS är väldigt resilient i att överleva klanterier med strömförsörjningar och glappa USB-kablar på lagring till externa USB-diskar - både ensamma och i olika raid-konstellationer, enkelt att göra snapshot inför ny backup, utöka med valfri storlek av disk när det blir trångt, ta bort den igen när det är gott om plats igen.

ZFS är vad jag förstår mer stelbent och kräver lite planering när det gäller volymer och kan _inte_ krympa sina filsystem igen om de har utökats en gång, vare sig online eller offline.

Hur mycket har du provat med olika störningar (dvs strömavbrott, glapp i kablar, dumheter som görs USB/SATA-chippen i USB-dockor etc. ) under backuppens körning - hur bra hanterar det efter en sådan incident - upprepande gånger...

För mig är det jätteviktigt att den bevisar sin resiliens (sv. återhämtningsförmåga) i den typen av användning - det skall aldrig hamna i ett läge där filsystemet inte är läsbart längre eller inte gå att rädda ut data med fulla namn/path och korrekt filkropp med hjälp av räddningsprogram (det har räddningsförsök med NTFS lärt mig hur noga det är med sådant när $MFT är skadad eller överskriven och resten av disken är fragmenterad). Detta betyder inte att BTRFS är skottsäker i alla lägen men jag har under mina tester inte lyckats träffat någon okänd corner case, och för mig är det bra nog, speciellt när jag också väljer att köra med dubbel metadata - dvs. 2 upplagor på olika ställen på disken av det som visar och hantera hur filerna ligger på disken.

Har aldrig fått BTRFS att kracha utom i en situation (32-bitars OS på ARM-propp som hanterar logiska volymer fylld med data en bit över 16 TB i en NAS av en viss tillverkare) - och då kraschar den stenhårt då LBA-adresseringen loopar till 0 igen och skriver över fel saker pga. 32-bits ordlängd fast systemet tror att det skriver vidare uppåt, men samma sker också med ext4... - det jag dock vet är att BTRFS räddningsprogram kan få ut filerna igen av en sådan krasch - det tar tid men det går med alla namn, path och rättigheter samt datadel intakta - gjorde byte-compare av alla filer från det som räddats gentemot referensen-filseten för att vara _helt_ säker på det!, jo jag kollade nasen ifråga noga med nya 8TB diskar och var väldigt misstänksam angående 16 TB gränsen - som visade sig korrekt att vara orolig över... - detta är dock inget att vara bekymrad över om OS är 64-bit)

Finns sådan räddningsverktyg för ZFS, dvs. ta hand om och extrahera ut filer ur Raid-setet när det som inte skall hända ändå sker ??? - om inte, då är det en dealbreaker om det skall vara för fristående backupmedia men acceptabelt om det är en filserverfilsystem, då det ändå skall göras regelbundna backupper på innehållet till annan media.

Har råkat ut för sådan på tapestreamer med buggiga program och därför är räddningsmöjligheterna när det skiter sig av prio om formatet skall fungera som backup-filsystem/format eller inte - tex. TAR-format är ok och stora delar av innehållet räddningsbart även om det extraheras ut i stora bitar och ingen filhuvud, men inte som zip-akiv där datakroppen blir värdelös om början av filen klipps bort eller går korrupt, egna proprietära strukturer med egna CRC-summor som inte är standard och egenmodifierad ZIP-komprimering (antagligen för att komma runt patent på den tiden) - tack för att du lärde mig detta, colorado backup... (hp:s tapestreamer-division på den tiden)

Det blir aldrig fel med en Synology för det du beskriver. Bästa OS:et för OEM-NAS på konsumentmarknaden i min mening. Out-of-the-box appar för allt du kan tänka dig samt appar till mobil (jag strömmar musik till stereo och laddar hem torrents via mobilen för att nämna något).
OS:et uppdateras regelbundet för att komma tillrätta med buggar och implementerar hela tiden nya funktioner. Larm och rapporter via mejl om man vill. Överlägsen support med fjärråtkomst. Inga kända "skandaler" med [crypto] bakdörrar som QNAP m.fl.

Har kört min NAS i snart 8 år med 4st 2TB WD RED i RAID5 och ext4 filsystem. Bytt disk vid tre tillfällen med några års mellanrum. Låter den stå på vinden (skitkallt på vintern, stekhett på sommaren). Den har också överlevt otaliga strömavbrott (frisk kopplat du vet ) ännu utan att förlora data...

Om det är en första NAS så är en Synology eller motsvarande (4-bay som minst) och som klarar mer än 16 TB logisk volymstorlek ganska bra att starta med för att lära sig konceptet med NAS och att dessa inte är samma sak som en extern disk - utan i praktiken en mindre filserver.

Nästa NAS när man tycker behov finns behöver inte alls vara en köpe-NAS utan något man bygger själv med tex. freeNAS då man är mer varm i kläderna hur det hela fungerar och kanske också har mer önskemål som att köra VM (och då kräver mer RAM-minne), GPU för realtidsomkodning av mediaströmmar mm.

Om dina data försvinner pga. filsystemshaveri oavsett sort så har du fel backupstrategi. Man kan inte överlåta sina data till en enda filsystem eller en enda exemplar oavsett hur 'säker' filsystemet marknadsför sig som - HW-fel gör override på alltihop ändå... och jag vet de de som fått ZFS att haverera (oftast av minnesfel) att man är väldigt svårt läge då det inte finns bra räddningsprogram att gräva ut datat igen.

Att JAG använder BTRFS är efter mina _egna_ utvärderingar och olika prov ansett det tillräckligt bra, och känner jag mogen för zfs så skulle de köras på samma sätt - inklusive hur det klarar när filsystemet havererar och är i läge att rädda ut data.

Jag har en bakgrund där sådant visade sig var viktigt - alltså hur man gräver ut data när det väl har skitigt sig och alla sk. backuprutiner mm. inte har fungerat trots alla fagra tal innan hos de ansvariga som skulle har skött detta eller upphandlade leverantören inte gör det dom skulle göra för att man hade missat det i upphandlingen eller gjort egna avvikelser (som tex. att explicit inte göra backup på alla användares email-boxar i jobbdatorer fast det stod så i avtalet - och när man påpekade så var kommentaren - 'men det blir ju så mycket data!!...' )

Det är ändå till slut var och ens egna beslut och filosofi i vilket man väljer, och också få vara beredd ta konsekvensen om det blev fel.

körde också Jbod och förstås backupper - men så dummade jag mig och råkade skriva sönder ena disken och JBOD havererade.

Av läxan av detta så är filosofin aldrig mindre än RAID5 eftersom det tar helvetes tid att få tillbaka 12 TB data över nätverk att en extra disk för redudans för att klara klanteri eller en diskhaveri är klart värt dom extra pengarna - kräver förstås att det fins lediga diskplatser i sin NAS - därav aldrig köpa två-bay nas utan minst 4 bay