Frågor om NAS, backup och BTFRS från Synology

Permalänk

Har 2 synology Nasar, den ädre en 2-bays har tickat på i över 5 år och den nyare DS916+ med 8GB minne har gått över 2 år. Båda kör brfs utan några problem alls, inga dataförluster. Smidiga att använda och gillar att Synology fortsätter att uppdatera även för äldre modeller. Till DS916+ har jag även en expansionsenhet med plats för ytterligare 5 hårddiskar.

Permalänk
Medlem
Skrivet av DocStargazer:

Har 2 synology Nasar, den ädre en 2-bays har tickat på i över 5 år och den nyare DS916+ med 8GB minne har gått över 2 år. Båda kör brfs utan några problem alls, inga dataförluster. Smidiga att använda och gillar att Synology fortsätter att uppdatera även för äldre modeller. Till DS916+ har jag även en expansionsenhet med plats för ytterligare 5 hårddiskar.

Tack!

Vad vet du om andras erfarenhet om Synology? Mitt intryck var att deras produkter har en gemensam röd linje genom hela sortimentet, som gör att, när man har flera av deras produkter eller/och om man migrerar från en modell till en annan blir det enhetligt och väldigt lätt!

Jag kom fram att jag ska köra en blandning av NAS:ar (2 st för dagens kopia, den som jag ska jobba med, och gårdagens kopia som blir som första backup). Därefter köra med minst 2 olika backup på olika lösa HDD (efter en roterande schema) som ger mig möjligheten att kunna återställa allt till en tidigare tidpunkt på ett lättare sätt! Får se vilket filsys ska jag köra på dessa lösa HDD. Troligtvis BtrFS.

Visa signatur

CDan

Permalänk
Medlem
Skrivet av nick-li:

@CDan: Dock så använder inte Synology BTRFS inbyggda raid funktion och använder BTRFS mera som ett vanligt filsystem.
...som sagts tidigare i tråden

Tack för svaret!

Vi båda två säger samma sak!

Enligt det som står på deras sida ( https://www.synology.com/sv-se/dsm/Btrfs ) skriver dem:

"När en felmatchning upptäcks (tyst datakorruption) kan filsystemet Btrfs automatiskt upptäcka korrupta filer (tyst datakorruption) med speglade metadata och återställa trasiga data med de RAID-volymer som har stöd, inklusive RAID 1, RAID 5, RAID 6, RAID 10, F1 och SHR"
och
"Btrfs är ett modernt filsystem som har utvecklats av flera aktörer och som numera stöds av vissa Synology NAS-modeller. Btrfs skapades för att bemöta problem som ofta uppstår i lagringssystemet hos företag. Till exempel feltoleranser, hantering och dataskydd".

Alltså det är ett filsystem som funkar för att återställa korrupt data även i RAID! Att man kör RAID eller inte är upp till användaren. Det är filsystemet som ser till att data är korrekt!

Visa signatur

CDan

Permalänk
Medlem

Men i grunden är det inte BTRFS som hanterar RAID-funktionen - det är en mdadm-RAID som BTRFS sedan ligger ovanpå.

BTRF har dock checksumma på alla sina sektorer och skulle det blir fel i den underliggande RAID-hanterande och fel data skulle levereras tillbaka så kommer BTRFS att reagera på detta - dock inte kunna rätta det då den inte har kontroll på de underliggande diskarna och dess paritet.

Hade BTRFS själv skött om sin RAID så hade den kunna provat de olika alternativen som erbjuds från de olika diskarna och välja den första som levererar rätt data som stämmer med checkumman (lagrad på annan plats på disken) och sedan rätta den disken som hade fel data.

RAID1 ala mdadm har lägen som den inte kan reda ut - tex. i fallet med en strömavbrott och den ena disken har blivit uppdaterad men inte den andra disken och när strömmen slås på igen så kommer RAID-systemet att se två diskar, ingen ger läsfel men datat skiljer sig när samma LBA-nummer läses - detta är en situation som mdadm-RAID inte kan lösa då inget indikerar vilket av dessa två är den korrekta och raid-systemet stallar. Detta kallas för 'write hole' i RAID-sammanhang och är också detta som gör att man inte säger att BTRFS RAID5 och 6 är lämplig att ha i skarp drift för att man kan nå den situationen vid strömavbrott under skrivning och en disk går sönder samtidigt[1] - och sanningen är att mdadm också har den situationen (och utan att någon disk behöver gå sönder) men det verkar alla blunda för och inte låtsas om, då om man skulle applicera samma regler som man gör på BTRFS RAID 5 och 6 så skulle mdadm också bli rödflaggad - och det är den för väletablerad för att någon skulle våga ta det steget...

Det finns möjlighet att slå på mdadm i journalförade mode (är dock ganska mycket beta) men innebär rejäla prestandanedsättning då data skall skrivas två gånger så därför är det normalt sett inte påslaget.

ZFS har motsvarande men där man dedikerat en hel disk eller SSD för rollen (SLOG) för att just hantera situationer med plötslig strömavbrott mitt under skrivoperationer.

Till det har man ytterligare delen att datat som är kvar i RAM och inte synkas till diskarna ännu - försvinner vid strömavbrott och har man en server med 64 GB RAM och mycket aktiviteter så kan det vara ganska mycket som aldrig hinns ned till diskarna...

Kort sagt plötslig strömavbrott är inte bra oavsett och det är bra med UPS som också signalerar till servern att strömmen har gått efter kortare tid så att det hela kan stängas ned på kontrollerat sätt.

---

Hur påverkas det i praktiken med mdadm:s tillkortakommande och olycklig strömavbrott? förmodligen väldigt lite, BTRFS är transaktionshanterande vilket innebär att ingen fil är offentligt skriven förrän transaktionen är genomförd och det sker ofta och kanske som längst 1 ggr per minut om något finns att skriva till disk ur RAM-minnena - har det hunnit halvvägs med en skrivning och bryts mitt i av tex strömavbrott - så backar BTRFS till transaktionen innan och det som skrevs efter denna punkt finns inte (och med stor sannolikhet finns eventuell skillnad i skrivningarna mellan RAID-diskar nu är i den datadelen som övergetts och ingen kommer att titta i den delen och där upptäcka eventuella datafel där - då när det skrivs på nytt så är det med ny data igen och problemet borta.)

[1] det är inte bara det, Jag provat BTRFS i RAID5 i en testrigg med som det visade sig två bråkande diskar samtidigt som krånglade i olika omgångar och en blev utkastad, en disk var redan känd med många reallokerade block och därför användes för att stressa RAID5 lite - den andre var en överraskning och visade sig först vid synkning - trots att jag nog gjorde alla fel som gick, så tappade jag ingen data och tom. dubbelkollade med binär-jämförelser med backup - men det som talar emot fortsatt användning i skarp drift ännu, var att man inte fick systemet 'clean' med reparationer och städning efteråt - fast detta var vid användning helt stabilt så fortsatte dmesg att kräkas felmeddelande som man inte kunde bli kvitt i trots att man kört balance, check och scrub mm. och man tycker det borde ha försvunnit.

Mao. det fungerar jättefint - när disk bråkar så fungerar det fortfarande, även vid dubbeldisk-fel fungerade och data blandades inte ihop, så länge att just datadelen som söktes inte var trasigt på båda diskarna samtidigt, när ny disk sätts in fungerar det fortfarande, MEN - man blir inte av med alla (oväsentliga/falska positiv?) felmeddelanden som hela tiden produceras i dmesg efter en diskbytar-händelse. Till detta så är inte BTRFS diskhantering automatisk när man byter disk på samma sätt som mdadm-RAID utan kräver kommandon skrivs för momenten. Med andra ord finns en del kvar att städa i BTRFS RAID5/6 men inget uppenbart av naturen att det orsakat att man förlorat filer - tvärt om, filerna verkar vara synnerligen resilenta trots att RAID-systemet var allt annat än stabil pga. i omgångar dubbla bråkande diskar i en RAID5, så även om det skiter sig ganska rejält så är räddningspotentialet av felfria filer ur en havererad BTRFS 5/6 mycket hög - normala havererade RAID brukar vara rätt hopplösa i det läget...

Permalänk
Medlem
Skrivet av xxargs:

Men i grunden är det inte BTRFS som hanterar RAID-funktionen - det är en mdadm-RAID som BTRFS sedan ligger ovanpå.

BTRF har dock checksumma på alla sina sektorer och skulle det blir fel i den underliggande RAID-hanterande och fel data skulle levereras tillbaka så kommer BTRFS att reagera på detta - dock inte kunna rätta det då den inte har kontroll på de underliggande diskarna och dess paritet.

Hade BTRFS själv skött om sin RAID så hade den kunna provat de olika alternativen som erbjuds från de olika diskarna och välja den första som levererar rätt data som stämmer med checkumman (lagrad på annan plats på disken) och sedan rätta den disken som hade fel data.

RAID1 ala mdadm har lägen som den inte kan reda ut - tex. i fallet med en strömavbrott och den ena disken har blivit uppdaterad men inte den andra disken och när strömmen slås på igen så kommer RAID-systemet att se två diskar, ingen ger läsfel men datat skiljer sig när samma LBA-nummer läses - detta är en situation som mdadm-RAID inte kan lösa då inget indikerar vilket av dessa två är den korrekta och raid-systemet stallar. Detta kallas för 'write hole' i RAID-sammanhang och är också detta som gör att man inte säger att BTRFS RAID5 och 6 är lämplig att ha i skarp drift för att man kan nå den situationen vid strömavbrott under skrivning och en disk går sönder samtidigt[1] - och sanningen är att mdadm också har den situationen (och utan att någon disk behöver gå sönder) men det verkar alla blunda för och inte låtsas om, då om man skulle applicera samma regler som man gör på BTRFS RAID 5 och 6 så skulle mdadm också bli rödflaggad - och det är den för väletablerad för att någon skulle våga ta det steget...

Det finns möjlighet att slå på mdadm i journalförade mode (är dock ganska mycket beta) men innebär rejäla prestandanedsättning då data skall skrivas två gånger så därför är det normalt sett inte påslaget.

ZFS har motsvarande men där man dedikerat en hel disk eller SSD för rollen (SLOG) för att just hantera situationer med plötslig strömavbrott mitt under skrivoperationer.

Till det har man ytterligare delen att datat som är kvar i RAM och inte synkas till diskarna ännu - försvinner vid strömavbrott och har man en server med 64 GB RAM och mycket aktiviteter så kan det vara ganska mycket som aldrig hinns ned till diskarna...

Kort sagt plötslig strömavbrott är inte bra oavsett och det är bra med UPS som också signalerar till servern att strömmen har gått efter kortare tid så att det hela kan stängas ned på kontrollerat sätt.

---

Hur påverkas det i praktiken med mdadm:s tillkortakommande och olycklig strömavbrott? förmodligen väldigt lite, BTRFS är transaktionshanterande vilket innebär att ingen fil är offentligt skriven förrän transaktionen är genomförd och det sker ofta och kanske som längst 1 ggr per minut om något finns att skriva till disk ur RAM-minnena - har det hunnit halvvägs med en skrivning och bryts mitt i av tex strömavbrott - så backar BTRFS till transaktionen innan och det som skrevs efter denna punkt finns inte (och med stor sannolikhet finns eventuell skillnad i skrivningarna mellan RAID-diskar nu är i den datadelen som övergetts och ingen kommer att titta i den delen och där upptäcka eventuella datafel där - då när det skrivs på nytt så är det med ny data igen och problemet borta.)

[1] det är inte bara det, Jag provat BTRFS i RAID5 i en testrigg med som det visade sig två bråkande diskar samtidigt som krånglade i olika omgångar och en blev utkastad, en disk var redan känd med många reallokerade block och därför användes för att stressa RAID5 lite - den andre var en överraskning och visade sig först vid synkning - trots att jag nog gjorde alla fel som gick, så tappade jag ingen data och tom. dubbelkollade med binär-jämförelser med backup - men det som talar emot fortsatt användning i skarp drift ännu, var att man inte fick systemet 'clean' med reparationer och städning efteråt - fast detta var vid användning helt stabilt så fortsatte dmesg att kräkas felmeddelande som man inte kunde bli kvitt i trots att man kört balance, check och scrub mm. och man tycker det borde ha försvunnit.

Mao. det fungerar jättefint - när disk bråkar så fungerar det fortfarande, även vid dubbeldisk-fel fungerade och data blandades inte ihop, så länge att just datadelen som söktes inte var trasigt på båda diskarna samtidigt, när ny disk sätts in fungerar det fortfarande, MEN - man blir inte av med alla (oväsentliga/falska positiv?) felmeddelanden som hela tiden produceras i dmesg efter en diskbytar-händelse. Till detta så är inte BTRFS diskhantering automatisk när man byter disk på samma sätt som mdadm-RAID utan kräver kommandon skrivs för momenten. Med andra ord finns en del kvar att städa i BTRFS RAID5/6 men inget uppenbart av naturen att det orsakat att man förlorat filer - tvärt om, filerna verkar vara synnerligen resilenta trots att RAID-systemet var allt annat än stabil pga. i omgångar dubbla bråkande diskar i en RAID5, så även om det skiter sig ganska rejält så är räddningspotentialet av felfria filer ur en havererad BTRFS 5/6 mycket hög - normala havererade RAID brukar vara rätt hopplösa i det läget...

Ok, nu fattar jag vad du menade. Men att gardera sig mot sådan scenario blir det inte lätt eller billigt, för en vanlig konsument. Det krävs mycket kunnande och kanske mycket pengar oxå.

Jag planerar ha 2-3 kopior ganska tätt intill varandra tidsmässigt. Alltså en arbetskopia, och som namnet säger, jobbar man med. En till kopia som är kanske 1-2 dagar gammal, och en till som är kanske 1-2 veckor gammal. Jag har mest bilder och vanliga dokument. Musiken finns även i form av CD/DVD eller LP. Alltså allt jag har ändras inte så jätte mycket på 1-2 veckors tid. Det som jag jobbar med för stunden finns på minst 2 olika platser: dator, usb-minne och huvud:NASen. Får jag strömavbrott har jag möjligheten att återskapa det mesta av allt jag har.

Men, om man kör på Synology NAS, hur kan man göra för att få data integrity på sina diskar? Utöver att man kör med UPS!

Med BtrFS är det RAID1 eller RAID6 att föredra? Eller ingen RAID alls och inkrementell kopiering en gång om dagen till den andra disken (den som skulle ha ingått i RAID1)?

Finns det nåt att göra som inte är så dyrt? Nåt som inte är så tidskrävande och så jätte avancerat?

Visa signatur

CDan

Permalänk
Medlem

Kan man höja data integrity om man kör RAID6 på 5 diskar istället för 4 st på en Synolgy NAS med BtrFS? Jag tycker att om man sprider data på flera diskar blir det lättare att upprätthålla data integrity!

Visa signatur

CDan

Permalänk
Medlem

Även om det fördelas på flera diskar så är det fortfarande en enda filsystem. RAID på en NAS är bara för att se till att inte blir stopp i NAS när en disk havererar. En backup kan ersätta diskinnehållet i hela NAS:en om denna blivit förstörd av olika saker.

jobba på att du klarar av fallet att åskan slog ut din NAS och att med dina backupper inte förlorat mer filen än det som lagts in i NAS efter förra backuppen - det är upp till dig att se till med ofta tagna backupper att det inte är så många filer som förloras om åskan slår ned...

kom också ihåg att backupmedian inte skall vara anslutna utan ligger undanlagda så fort de inte är under backup, åter igen för att åskan inte skall ta dem och det går en massa spänning i kablarna och via nätaggregaten och grilla diskarna.

---

Jag kör minimum RAID 5 efter att ena disken i en Jbod på 16 TB nästan full, skrevs över av misstag (gäller att hålla reda på sina ssh-terminaler och jobba på rätt enhet när man diskmekar - att det skramlar och blinkar på annat ställen än den man tänkte sig var inte välkommet...)

Med andra ord alla fel beror inte på disk-ras utan kan vara skit bakom spakarna...

Man kan säga så här - den tiden det tog att tanka tillbaka allt ifrån backupperna var inte värt besparingen i att inte ha en extra disk för en RAID med paritet... inga data saknade men det var väldigt irriterande...

Med andar ord minst RAID5 om du frågar mig (kräver nas med minst 3 diskplatser) - och om man tycker sig ha råd och plats i NAS:en - RAID1 och oavsett RAID-typ ofta tagna backupper eller efter är man det att det har ändrats mycket på NAS:en - helst på två olika diskset, men viktigaste är att ha minst _en_ disk-set med full upplaga av alla filer i NAS:en och ofta hålls uppdaterad.

Hur ofta du gör backup beror på hur viktiga filer du har - är det jätteviktigt så ser du till att ha dessa på minst två olika media så fort det går (en på din persondator och en på tex. Nasen - och innan det tas bort från datorn så har du verifierat att det finns en nytagen backup av nasen och att viktiga filen också finns på backuppen, kanske tom. kolla med hash-summa på var och en och se att de är lika innan filen på persondatorn tas bort ... dvs. man låter aldrig den viktiga filen reduceras till en enda exemplar (och därmed blir orginalet) under hanteringen.

är det dessutom jätte, jätte viktig så bränner du en DVD-skiva på filen också - än så länge är det inga ransomware som kan kryptera en fil redan bränd på optisk disk...

Permalänk
Medlem

Hur bra funkar BTRFS idag?

Väcker denna tråden och lånar den.

Ska sätta upp en ny NAS (ds412+) och undrar hur bra BTRFS funkar idag?
Funderar på om man ska köra BTRFS istället för ext4 filsystem.

Jag har inget behov av backup utav vill bara lagra data, så min tanke är att köra var disk för sig så att man får ut så mycket utrymme som möjligt, så vilket filsystem borde jag satsa på?

Visa signatur

Desktop|Intel i5 12600|Asus Prime B760 Plus|Nvidia RTX 3070|Corsair DDR5 2x16GB|1TB M.2/1TB SSD
Mouse|Sensei Ten|Keyboard|Xtrfy K4|Monitor|Asus PG279QZ|Dell u2415
Laptop|HP ProBook 4320s I3|525GB SSD|4GB DDR3|NAS|Synology 412+ 30TB
Phone|iPhone 13 128GB|Tab|Mi Pad 4 64GB|HTPC|Google TV|Server|Intel Nuc

Permalänk
Medlem

Jag skulle köra på BTRS - har gjort det i flera år på nära alla mina externa USB-diskar utan någon minsta knirk när det gäller krångel och datasäkerhet.

Det där att kunna göra snapshot på subvolymer (och dessutom i RO-mode om man vill) är kraftigt beroendeframkallande när man vill ha versioner/generationer av sina backuper - typ snapshot_datum av subvolymen för backuppen - sedan rsynca mot NAS/server, nästa gång gör man samma igen - först snapshot:ny datum och sedan rsync:a - man kan ha hundratal subvolymer av snapshot och man radera dem i fri oberoende ordning - dvs. ingen hierarkisk koppling/ordningsförljd på samma sätt som man har på dataseten i ZFS

Är det inom NAS och som har BTRFS i sin filsystem - se till att slå på den automatiska backuppen (snapshot) för den volymen du skapar i din NAS - går dock bara på NAS med BTRFS som filsystem.

I regel så snurrar 'snapper' i bakgrunden (som gör grovjobbet) vilket gör att dina volymer och utdelade enheter med detta påslaget får en 'shadow' snapshot helt osynligt var dag (och det är automatisk tidslinje-radering typisk av snapshot av dagliga backupper till andra veckan, veckovisa backupper från andra vecka till 2 månader, därefter månadsbackupper och sedan kanske halvårsbackupper typ, så att det inte blir för många snapshot över tiden)

i NAS med bara ext4 finns typiskt inte några automatiska snapshot att välja även om det teoretiskt går att få till med snapper även där, men förutsätter att ext4-volymerna skapas och körs på LVM (man använder så LVM-snapshotmekanism för snapshot men är inte alls lika flexibel som snapshot med BTRFS)