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.