NAS filsystem + backup

Skulle väl säga att lösningen i sig ser rimlig ut.
Dock så är min fråga var EXT4 disken finns, rent fysiskt?

Om den är på samma fysiska plats som de andra 2 diskarna är så har du 0 redundans emot stöld/åska/brand etc.
Jag valde att hyra lagring online och synka dit, offsite backupen har även stöd för snapshot versioning så skulle ransomware osannolikt hitta hit så skall det gå att återställa en äldre version.

Heh, jag förstår exakt vad du menar, jag har bara det mest kritiska utanför nasen. Har ~660GB i cloud själv bara.
man kan väl räkna någonstans mellan 30-70kr/mån /TB för en sådan liten chunk beroende på vad man har för krav.

Finns t.ex hetzner storage box fås för 4€/TB eller så har t.ex alphavps en storage vps som du kan fulldisk encrypta för €5/TB

Sen finns ju aws, gcloud å liknande som man kan pressa mer på men det är jättarna jag vill undvika

Norska Jottacloud kanske?
ca 90 kr /mån (årsvis) för obegränsad lagring - men uppladdningshastigheten sjunker när du når över 5 TB.

https://www.jottacloud.com/sv/

Tillägg: https://docs.jottacloud.com/en/articles/3271114-reduced-uploa...

Hur mycket data ska du spara?
Alternativ skulle du kunna välja bort btrfs och köra vanliga Linux-RAID1 och ext4. Det går att skapa snapshot på filsystemnivå med programmet rsnapshot. Och andra sidan verkar BTRFS moget och jag tror det är ett bra val för en NAS idag.

Ja hela filsystem med inbyggt raid och snapshos gör det hela spännande men också mer komplicerat än vad det behöver vara. Det viktigaste är du har minst en backup av dina viktiga filer oavsett vilket filsystem du väljer.

Nu vet jag inte hur du vill använda nasen men min enkla server är en ren Backupstation. Nästan all data
finns också på min dator eller mobil om serven skulle implodera finns min data kvar där. Givetvis testar jag regelbundet att backup med filer fungerar som tänkt på serven.

Jag skulle köra på BTRFS och sedvanlig rsync-användning och med att göra subvolymer med snapshot innan var ny körning med rsync. det går också att skapa subvolumer med snapshot i skrivskyddad utförande med flagga -r om man vill ha barnsäkerhet på riktigt.

Så har jag kört länge och ser inte fördelen med att använda btrfs+snapshot send|receive då jag inte känner att jag har koll på hur den fungerar och det verkade diskintensivt, samt att det går utmärkt att använda rsync via ssh och likaså att skicka BTRFS-kommandon till en fjärrlagring med BTRFS via ssh när en snapshot skall göras - även från script.

Annars är rådet att prova olika - kanske köra flera metoder parallellt till någon som passar dig har utkristalliserats.

Det som fungerar bra för mig kanske inte passar dig.

Rsnapshot är ett programpaket/metod för filsystem som inte har några snapshot-möjligheter och gissar utan att ha kollat att den arbetar med hårda länkar - vilket många äldre backupprogram med versionshantering har gjort länge (inklusive Apples timemachine) - dvs. det är ingen atomär snapshot på sektornivå på samma sätt som tex. BTRFS och ZFS.

Andra paket som snapper kunde köra snapshot på ext4 via tunn provisionerad LVM men det ser ut som att den supporten läggs i träda allt mer och hellre kör på BTRFS. - snapshot via LVM/LVM2 är heller inte kända för att vara snabba och har samma problem som med windows VSS att när den får slut på reserverade utrymme för att lagra delta-data (den allt större skillnaden mellan snapshot och det som för närvarande används i filsystemet) så försvinner snapshoten eller ger andra problem och inte som i BTRFS att den är kvar tills den tas bort i och med att det är fullödig filsystem som kan modifieras och kan göras till original och inte en fryst avbild vid en viss tidpunkt och begränsad levnad.

Snapshot gjordes ursprungligen för att backupprogram skulle få tid att göra backup av filer utan att filen modifieras under tiden backupprogrammet läser filen och det blir inkonsistent - tänk typ databaser med konstant pågående transaktioner.

Gör man snapshot och backup på detta så motsvarar 'snittet' som en plötslig strömavbrott och de flesta moderna databasmotorer kan reparera från det tillståndet och köra vidare på samma sätt som efter en strömavbrott.

De tidigare modellerna av snapshot var också av naturen att man köade tex. disk-transaktioner upp till en viss storlek och sedan tvingades man släppa snapshot:en och därmed var en snapshot inte av 'evighetsmodell' även om det senare gjorts varianter på detta för längre hållbarhet och tex. emuleras av MS VSS-systemet i windows där man inte fördröjer skrivningarna av filsystemet medans snapshoten blev deltat som blev allt större med tiden ju mer som skrivs i filsystemet och till sist måste stängas för att frigöra diskutrymme.

Det behövs ingen meteroritnedslag, det räcker med rejält åsknedslag då det kan röja fint det också och med betydligt högre sannolikhet än meteornedslag (och orsaken till att backupdiskar på samma ort inte skall vara inkopplade online hela tiden utan urkopplade och undanlagda mellan backupsessionerna - slår blixten så ryker dom också via strömförsörjning och USB-kablar om de är inkopplade) - Har sett det på nära håll i en nyrenoverad kyrka mitt i Södertälje med indirekt blixtnedslag från rätt lång distans via strömförsörjningen som tog död på all elektronik från samtliga lysrörsarmaturer av lågenergityp inkl. styrdon, datorer i lokalen till skitdyra orgelstyrsystem och syntesizers med ljudanläggningar - det hade gjort rent hus bokstavligen - dock var de flesta inblandade glada att det inte också hade tänt på den nyrenoverade kyrkan...

BTRFS har ingen delta - utan snapshot av en subvolym är en komplett kopia av orginalet ned på fysisk sektornivå inklusive dess metadata till sista biten - och kopian använder sig av orginalets sektorer som det vore sina egna med en undantag - ny data och modifieringar ändrar inte det gamla datat utan skrivs på nya lediga sektorer i och med COW-principen, därav att det heller inte finns någon ordningsföljd som måste följas när man tar bort subvolymer igen, vilket man har i ZFS.

Givetvis har man läget om flera subvolymer (av tagna snapshot) med filer som pekar på samma fysiska uppkomna felaktiga sektor, så blir felen lika på samtliga subvolymer som har skapats från samma käll-subvolym eller kopierats med reflink eftersom alla dessa pekar på samma fysiska sektor - är det kinkiga filer så kanske man får spara dessa i två olika upplagor som inte är kopierade mellan varandra med reflink eller snapshot, använda sig av RAID vid flera diskar eller DUP om det är lokalt på en och samma disk.

- Även om BTRFS-filsystemet är designad att kunna ha blandade RAID-moder samtidigt (vilket den också har när den konverterar från en RAID-mode till en annan med balance) så finns inte verktygen ännu att allokera en viss fil till en önskad RAID-mode, som DUP som liknar RAID1 fast det är på en och samma fysiska disk. Däremot går det att sätta diskens data-del som DUP med balance på bekostnaden att halva diskens utrymme försvinner och var datasektor i filen blir utplacerade på 2 olika sektorer - har man 2 diskar i setet så väljer man RAID1, och då lägger sig även metadatat för BTRFS som RAID1 på varsin disk.

Metadatat i BTRFS brukar vara satta som DUP när filsystemet skapas på enkeldisk och datadelen som singel (man måste ha en flagga om det skall bara bli en single-metatadel som för tex. minska skrivlasten på SSD - själv byter jag hellre SSD lite mer ofta än att tulla på sådant..) .

Men det fina med BTRFS är att olika RAID-moder går att sätta och transformera i efterhand och utan att ta filsystemet ur drift - konverteringen görs med filsystemet online med 'balance' - det är inte hugget i sten om man valde fel i början som när man hanterar mdadm-RAID/LVM2-RAID eller ZFS och man får riva och bygga om från början för att ändra det.

Jag kan lova dig att det inte blir någon silent corruption, det är liksom en av finesserna med BTRFS, som tillsammans med ZFS är dom enda filsystemet som har koll på sin data och märker om de blir fel. Alla andra klassiska filsystem lever på hoppet att det blir rätt...

Det blir IO-error vid läsning av sektorn om den är korrumperad och inte kan rättas, och det enligt med den felhanteringsfilosofi som SATA/SAS och NVMe-diskar beter sig vid fel sedan ST506-tiden i mitten av 1980-talet - dvs. man ger inte ut felaktig data - man vägrar att leverera någon data alls och genererar IO-fel istället för den sektorn, och det kommer att gråta mycket röd text om problematiska sektorer i dmesg när det händer och det inte kan räddas med någon paritetsdata (måste vara i DUP eller RAID1/5/6 om paritetsdata skall finnas)...

- jag har provat oönskat med RAM-fel som sabbade transporten av data i någon tillfälligt allokerad RAM-diskbuffer i den trasiga RAM-området mellan när checksumman beräknades och datat skrevs på disken och upptäcktes senare när man försökte läsa dem igen - fel som inte upptäcks om man skriver mot ext4 eller NTFS (har provat båda) och felen verifierade med compare mot orginalfilerna som fanns på backup (det var via NTFS/ext4 jag kunde simulera felet på bitnivå då den inte spärra läsning av felaktig skriven data medans på BTRFS så saknades en 4K-block som vägras att läsas ut pga att checksumma och data inte hänger ihop...

Det var så jag upptäckte RAM-fel i datorn tillsammans med att borgbackup började protestera på checksummefel vid check av repositoriet och felen fann senare med memtest86 där en bit på en viss adress är konstant låg. Om man hamnade i det området eller inte beror helt på hur MMU allokerar RAM-segment till OS och är ett fel som kan sväva och studsa runt helt slumpmässigt på olika ställen... - det var detta som fick mig att plötsligt längta efter en laptop med ECC-minne...

Att komma ihåg att data-rot beror inte bara på att någon lagring börja göra fel - andra fel i hårdvara kan också böja stänka runt fel av icke reparerbart sort. Även om jag hade haft DUP/RAID så är det tveksamt att datat hade kunnat läsas ut rätt då det beror helt och hållet på om och var den felaktiga 4K blocket med RAM sitter i pipeline mellan när program skriver data och när det slutligen landar på diskytan. Är felet redan i början av kedjan så tror alla steg efter att det är korrekt, men när felet inträffar mellan när checksumma beräknas och skrivningen till disk så högg BTRFS felet när datat senare lästes. Varken ext4 eller NTFS gör något sådant alls och den här typen av smygfel kunde ha legat latent mycket längre innan upptäckt med sådana filsystem.

Snapshot ger en full kopia som subvolym av orginalet i och med att de pekar på samma fysiska sektorer ända in i metadatat. - det är också därför det går väldigt snabbt att göra en snapshot då det handlar 'bara' om att skapa en ny rot för den nya subvolymen som pekar på samma metadata och data som den gamla och man behöver inte räkna om några inoder eller kopiera någon data som tar upp lika mycket plats som originalet, utöver tiden det också tar. - 'diffen' bildas när man börja modifiera orginalet eller kopian eller båda samtidigt efteråt.

Detta bygger förstås på att filsystemet har genuint COW-beteende att alla förändringar och ny data skrivs på nya sektorer och aldrig modifiera existerande innan de är helt avrefererade.

Nu förstår jag din tänkta nämnda delta i samband med send/receive och då stämmer det förstås.

Jag har inte läst igenom tråden helt men som filserver så brukar jag rekommendera Truenas Core med ZFS. Oslagbart i alla meningar.

nbyggda funktioner för bit-rot protection (scrub)
- Det finns, du ställer själv in hur ofta, standard är 30 dagar.

Disk failure protection via Raid1
- Valfri "raid" 1-6, 10,50.

Native support för snapshots, så man kan skydda mot human error
- japps finns också.

Flexibelt för att addera extra diskar i framtiden (även om det givetvis bör göras genomtänkt)
- Japps, du behöver dock lägga till zvols dvs du stoppar i x antal (minst 2 diskar) och utökar utrymmet med valfri "raid".

Jag har funderat rätt mycket på det här med backuper fram och tillbaka jag också. Jag har inget att tillägga på de tekniska områden som har diskuterats i tråden egentligen. Jag kör själv en server med (med ZFS, fast principen är den samma).

Paritet och checksums skyddar mot bitrot. Snapshots internt skyddar mot användarfel ("whoops, den filen skulle jag ha haft kvar"). Rsync/rclone till cloud varje natt skyddar mot åska/brand/stöld. Extern HDD som förvaras i annan fastighet ej inkopplad som extra skydd (backuper mer sällan här, eftersom det är omständigt att hämta hem den).

Men jag skulle vilja lägga till en morbid fundering som man gärna duckar för: Vad händer om DU dör samtidigt som din NAS gör det? Du brinner inne tillsammans med hårdvaran så att säga...

Vet din familj/partner/barn hur man kommer åt bildarkivet och dess backuper? Detta är något jag själv har lite ångest för sedan jag blev förälder för några år sedan.

Truenas scale och Core är inte samma sak. Core använder du för filserver, scale är precis som det låter, om du vill installera containers/vms skala upp din lösning etc.

4 GB i Ram är lite klent kanske beroende på hur mycket data du tänkt ha på den. Men den använder ramet pga det finns ram att ta av, den cachar massor för att snabba upp saker å ting. Jag har 32GB i min och den cachar 28 GB just nu, bara för den kan.

Bara man väljer nått som fungerar och passar en så är det ju det viktigaste.

Det var bara ett förslag. Huvudsaken är att hittar något som passar för dig.