Backups over SMB verstandig?

[F.West98]

Ik maak sinds kort image backups van mijn schijven via Macrium Reflect naar mn Synology NAS als target over SMB. Bij de grotere backups (~3-4TB) heb ik veel problemen met integrity checks (van de gebackupte data) die in eerste instantie failen, maar bij een tweede of derde poging wel gewoon passen. Tijdens mijn onderzoek naar een backuptool kwam ik bij Veeam overal mensen tegen die riepen hoe je nooit maar dan ook nooit SMB zou moeten gebruiken voor backups, maar bij Macrium Reflect kom ik dit nergens tegen - er zijn praktisch 0 zoekresultaten over deze issues behalve dan "je schijf zal wel kapot zijn" (maargoed de volgende pass gaat het wel gewoon goed).

Nou vind ik het sowieso al niet een heel fijn idee dat mijn files in één groot archief worden opgeslagen waarbij één omgevallen bit een complete loss of data lijkt te izjn, dus daar ga ik nog verder over denken, maar wat zou de oorzaak van deze bitflips kunnen zijn? Zou het inderdaad veroorzaakt kunnen worden door SMB issues? Kan ik - zoals ze bij Veeam aanraden - inderdaad beter naar iSCSI "overstappen"? Veeam is natuurlijk wel heel erg enterprise gericht, dus hoezeer is dit echt een probleem voor de "prosumer"?

[AndreStarTrek]

Dat is onzin, SMB heeft daar gewoon inclusief de gehele netwerk stack een integriteit check voor, zeg maar een soort ECC voor netwerk. Dit klinkt meer als corruptie van geheugen en dat kan zowel server als client zijn. Als je verder geen problemen onder vind met je normale pc dan zou ik zeggen dat het in de NAS gebeurd.

Geloof me als het SMB uberhaupt zou kunnen zijn dan weet ik het wel, ik verwerk soms wel meerdere TB per week over SMB. Heb in me hele leven nog nooit corruptie over het netwerk gehad.

Bitflip gebeurd in het geheugen/geheugen controller, niet binnen een protocol.

Verder iscsi is zo anders dat je dit niet kan vergelijken met elkaar. Als data voor meerder computers beschikbaar moet zijn dan heb je zoizo niks aan iscsi. Iscsi moet je zien als een sata aansluiting over het netwerk en die kan je ook niet aan meerder computers hangen. Buiten dat, gaat dit niet je probleem oplossen van je corrupte data.

Verder zou het ook nog een HDD kunnen zijn in je nas.

Kortom het kan tal van dingen zijn maar niet de SMB en zoals je aangeef je vind er niks over omdat er dus ook niks te vinden is

Hopelijk helpt het je verder.

[Voor 38% gewijzigd door AndreStarTrek op 17-02-2023 02:19]

[F.West98]

https://forums.veeam.com/...y-nas-as-repo-t77177.html

Topics als dit vind ik toch erg verwarrend; want ze doen hier toch alsof elke synology nas regelmatig issues heeft maar dat kan ik me toch ook weer moeilijk voorstellen. Maargoed. Ik weet ook wel dat iSCSI en SMB natuurlijk niet te vergelijken zijn, maar aangezien ik toch alleen 1 device heb die hier backups moet maken is het voor mij redelijk om het even.

Memory corruption is een lastigere... Mijn PC is vrij nieuw en had in het begin memory issues (Ryzen 7000 is nog wat moeilijk op hogere snelheden), maar nu op 4400Mhz is het toch al weken stabiel zonder enige issues terwijl ik op hogere snelheden elke paar minuten crashes had. Ook memtest kon na een flinke tijd geen issues meer vinden (en op hogere snelheden heel consistent bij bepaalde tests). Maargoed, who knows, misschien toch nog een bitflip ergens in al die TBs aan data... NAS vind ik lastig te analyseren.

HDD fouten in de NAS kan ook nog, maargoed dat draait wel de Synology software RAID (SHR) en alle smart data ziet er nog goed uit; één van de schijven is wel gloednieuw maar de rest draait toch al een tijd zonder enige issues. Dus die zou ik eigenlijk niet snel verdenken...

Maar dan de belangrijkere vraag: hoe groot is het probleem als het <eventually> wel verifieert? Dan is de data in de backup er wel lijkt me? Dat vind ik wel meer tricky aan het image-idee, ipv een file-based backup zoals windows dat met file history doet.

[ThinkPad]

Ik backup PC thuis ook via SMB, met Veeam (de gratis consumenten editie) en dat gaat prima. Dagelijks incremental en 1x per maand ofzo een full backup. Wel is het bij mij geen terabytes aan data, maar hooguit 40-50GB. M’n VMware server backup ik ook naar de Synology, dat doe ik niet via SMB, maar via NFS.

Nog wel belangrijke tip: gebruik een apart account op de NAS voor de SMB folder, zorg dat je andere accounts daar niet bij kunnen qua rechten en mount de schijf ook niet in je verkenner. Op die manier ben je nog iets beter beschermd tegen ransomware.

Een complete image backup doe ik eigenlijk sowieso al jaren niet meer (behalve voor de VMs). Ik backup de userdata en na een reinstall installeer ik met Chocolatey al m’n software weer.

[Voor 21% gewijzigd door ThinkPad op 17-02-2023 06:56]

[Ben(V)]

Grotere onzin dan dat smb niet voor backup geschikt zou zijn heb ik nog nooit gehoord.
Het is momenteel het beste protocol om op een lan te gebruiken.
Vermoedelijk gaan dat soort uitspraken over smb via het internet want daar is smb niet zo geschikt voor, het is een lan protocol.

En image backups zijn enkel nuttige voor een systeem disk terug gezet moet kunnen worden naar een nieuwe disk en dan ook bootable moet zijn.
Verder gebruik je incremental backups anders is het eigenlijk helemaal gaan backup.

[Voor 6% gewijzigd door Ben(V) op 17-02-2023 08:39]

[synoniem]

Ik gebruik al jaren verschillende versies van Aomei Backup om machines met smb naar een nas te backuppen. Één full per week en differentials de andere dagen, altijd met verificatie aan. De enige keer dat ik verificatie problemen heb gehad tot nu toe is met defect geheugen op de pc.

[SVMartin]

@F.West98 wat bedoel je precies met "image backups van mijn schijven"? Zijn deze fysiek, virtueel, heb je de fysieke schijven in 1 desktop? En om wat voor data gaat het, staat er een operating system op, applicaties die mischien in gebruik zijn, of alleen foto's en documenten?

Alternatieven zijn scp of rsync. Rsync werkt echt anders, deze synchroniseert bron met doel en kopieert alleen de wijzigingen.

Je kunt met software full en incremental backups maken en die opslaan op je nas. Je kunt ook een sync maken naar de nas en op de nas snapshots gebruiken.

[PageFault]

Ik heb SMB al decennia gebruikt voor backup, ook van serieus grote bestanden (>40 GB).

Waarom ze dat roepen heeft denk ik vooral te maken met dat SMB vaak gezien wordt als potentieel veiligheidslek, wat het overigens ook is. Maar zolang het of intern blijft of een beveiligde verbinding is, zie ik niet zoveel problemen.

[SVMartin]

Tsja, SMB heeft inderdaad wel wat schade opgelopen rondom beveiliging, maar welk protocol is nu wel schadevrij :-)

Een ander punt is dat de performance geen goed imago heeft. Ik herinner me nog een factor 2 verschil tussen NFS en SMB. Dat was wel decennia geleden.

Ik vond deze zojuist nog:

https://blog.ja-ke.tech/2...rmance-sshfs-nfs-smb.html

[Ben(V)]

Schade door smb is natuurlijk onzin.
En smb is net als nfs een lan protocol, gebouwd op betrouwbaarheid en efficiëntie en niet geschikt om beveiligd over het internet te werken.
Het ondersteund wel encryptie maar op een lan gebruik je dat nooit.

En het antieke nfs is zeker veel slechter dan smb ook qua performance.
Je moet geen verhalen uit de oude doos voor feiten houden.

En die joker van je link test de boel op een 1Gbps netwerk, waardoor dat de beperking is en niet het protocol.

[Metabool]

Geen onzin, backup over SMB laten lopen is absoluut niet aangeraden.

Voor het transport van de data werkt het wel, maar waar de schoen wringt is acties zoals merges van data en integriteitscontroles.

Koppelen van iSCSI target behaal je heel veel betere performance mee.

Backups over SMB als consument kan prima. Reden dat je o.a. bij Veeam steevast zal tegenkomen dat SMB afgeraden wordt is performance en betrouwbaarheid in grotere omgevingen.

Als je target een SMB share is, en je hebt daar een 2TB backup met wat incrementele backups dan moet Veeam alle data ophalen over SMB om forward incrementals te maken.

Forward incremental houdt in dat je begint met alle data X, en dan incrementals 1,2,3 enz
Als het gewenste aantal incrementals (retentie) is bereikt dan zal Veeam de oudste incremental (1) mergen naar data X. Hiervoor moet dan als je SMB gebruikt het hele bestand X worden opgehaald over SMB, kan dan worden aangepast en weer teruggeschreven over SMB. Dat gaat tergend langzaam.

Gebruik je een NAS dan werkt iSCSI in die situaties heel veel optimaler dan SMB (en NFS zal ook beter werken). Nog beter is een target gebruiken waar lokaal software op draait, in geval van Veeam houdt dat in een Windows machine die je als repository toewijst. Dan kan Veeam de gewenste taken doorgeven aan de software op je client en hoeft er helemaal geen data over het netwerk uitgewisseld te worden omdat je target de werkzaamheden kan uitvoeren. Dit is voor thuisgebruik natuurlijk helemaal niet aan de orde.

[Ben(V)]

Je moet de beperkingen van veenman incrementel backup niet op smb schuiven.
Goede backup software houd voor incremental backups z'n eigen administratie bij en hoeft daar niet alles op de target voor terug te lezen.
En op iscsi zal dat echt niets beter gaan.

En uiteraard werkt een cliënt server backup altijd beter, maar dat heeft niets met het netwerk protocol te maken.

[Voor 18% gewijzigd door Ben(V) op 17-02-2023 23:50]

[jeroen3]

Metabool schreef op vrijdag 17 februari 2023 @ 20:53:
Forward incremental houdt in dat je begint met alle data X, en dan incrementals 1,2,3 enz
Als het gewenste aantal incrementals (retentie) is bereikt dan zal Veeam de oudste incremental (1) mergen naar data X. Hiervoor moet dan als je SMB gebruikt het hele bestand X worden opgehaald over SMB, kan dan worden aangepast en weer teruggeschreven over SMB. Dat gaat tergend langzaam.

Doet veam dat allemaal in 1 file? Want dan zie ik dat nog wel mis gaan met concurrency enzo.
Macrium doet dat niet, alles krijgt een nieuwe file.


Maargoed, als macrium corrupte data detecteert. Dat kan jij dat ook.
Maak een grote file en berekend een checksum. (bv: Get-FileHash in powershell)
Kopieer die file naar de synology en bereken via SMB een aantal keer die file hash.
Zou hetzelfde moeten zijn. Als dat niet zo is, dan is er iets mis met je pc of de synology

[Voor 5% gewijzigd door jeroen3 op 18-02-2023 00:15]

[Q]

F.West98 schreef op vrijdag 17 februari 2023 @ 02:02:
Ik maak sinds kort image backups van mijn schijven via Macrium Reflect naar mn Synology NAS als target over SMB. Bij de grotere backups (~3-4TB) heb ik veel problemen met integrity checks (van de gebackupte data) die in eerste instantie failen, maar bij een tweede of derde poging wel gewoon passen.

1. Probeer andere software
2. Test je pc memory met memtest86
3. Kopieer handmatig over smb 100GB+ aan data - gaat dat goed?

[Mijzelf]

Ik heb in het verleden verschillende keren gelezen over data corruptie over Samba bij goedkope NASjes. In alle gevallen leek het erop dat Samba (of misschien de netwerk stack) was overtweaked om maximale thoughput te krijgen. Bij bijvoorbeeld de Medion STG112 kon je vrij eenvoudig corrupte files krijgen door een media file en een andere tegelijk te uploaden. De media file werd on the fly gescand door de ingebouwde media player, en raakte daarbij corrupt.
Dit was te voorkomen door de media player te disabelen, of door een een samba server van optware te gebruiken. Daarmee halveerde dan wel je schrijfsnelheid, wat doet vermoeden dat Medion (of eigenlijk hun leverancier) wat shortcuts in samba had toegepast ten koste van de stabiliteit.
Soortgelijke verhalen heb ik gelezen over een bepaald type ZyXEL NAS (de NAS326) en nog andere, waarbij ik me het merk en type niet meer kan herinneren. (Die fora zijn er niet meer, helaas)
Het zou kunnen dat de Veeam berichten waar de OP over praat in dit soort dingen hun grond vinden.

[eheijnen]

Welke versie/variant van Macrium Reflect gebruik je eigenlijk?
Welke client OS gebruik je?

En kijk hier eens naar, een oplossing van Synology zelf:
https://kb.synology.com/e...upbusinessagent?version=7
https://www.synology.com/...active-backup-business/pc

Synology heeft dus een eigen client/server backup oplossing.

[Voor 86% gewijzigd door eheijnen op 18-02-2023 09:55]

[Ben(V)]

Mijzelf schreef op zaterdag 18 februari 2023 @ 09:01:
Ik heb in het verleden verschillende keren gelezen over data corruptie over Samba bij goedkope NASjes. In alle gevallen leek het erop dat Samba (of misschien de netwerk stack) was overtweaked om maximale thoughput te krijgen. Bij bijvoorbeeld de Medion STG112 kon je vrij eenvoudig corrupte files krijgen door een media file en een andere tegelijk te uploaden. De media file werd on the fly gescand door de ingebouwde media player, en raakte daarbij corrupt.
Dit was te voorkomen door de media player te disabelen, of door een een samba server van optware te gebruiken. Daarmee halveerde dan wel je schrijfsnelheid, wat doet vermoeden dat Medion (of eigenlijk hun leverancier) wat shortcuts in samba had toegepast ten koste van de stabiliteit.
Soortgelijke verhalen heb ik gelezen over een bepaald type ZyXEL NAS (de NAS326) en nog andere, waarbij ik me het merk en type niet meer kan herinneren. (Die fora zijn er niet meer, helaas)
Het zou kunnen dat de Veeam berichten waar de OP over praat in dit soort dingen hun grond vinden.

Waarschijnlijk broodje aap verhalen van mensen die de verkeerde conclusies trekken.
Een mediaplayer leest enkel files, dus daar kan dus nooit iets door corrupt raken.

En je gaat toch geen redelijk professioneel product als Veenam vergelijken met cheap ass Nasjes uit de oude doos?

[Mijzelf]

Ben(V) schreef op zaterdag 18 februari 2023 @ 11:01:
[...]


Waarschijnlijk broodje aap verhalen van mensen die de verkeerde conclusies trekken.
Een mediaplayer leest enkel files, dus daar kan dus nooit iets door corrupt raken.

Zoals gezegd kan ik je niet meer naar de thread verwijzen. Een slimme jongen had uitgezocht wat er precies gebeurde, en het kwam neer op het volgende:
De media speler maakte een een of ander index bestand aan (met fileoffset tegen tijd, geloof ik) terwijl de media file binnenkwam, en lockte daarbij de media file voor korte momenten. Wanneer samba wilde schrijven terwijl de file gelockt was, ging hij bufferen in geheugen. Dat was de gewenste actie. Maar omdat er ondertussen een 2e file binnenkwam, en die niet direct kon worden weggeschreven doordat de schijf gewoon niet genoeg IOPS had, moest die ook bufferen. Door een verkeerde optimalisatie werd de buffer dubbel gebruikt. en kwamen er dus stukjes '2e file' in de media file terecht.
Dat was terug te vinden in de aanpassingen van samba in de GPL sources die Medion beschikbaar stelde, ten opzichte van de sources van die (oude) versie van Samba.org.
En ja, ik heb die verschillen zelf gezien, zij het dat ik niet heb uitgezocht wat de implicaties zijn. Het was al verrassend genoeg dat de Medion GPL source van Samba x.y.z verschillend was van die van Samba.org, en duidelijk in een andere stijl was ge-edit.

En je gaat toch geen redelijk professioneel product als Veenam vergelijken met cheap ass Nasjes uit de oude doos?

Tja, de OP schrijft

Tijdens mijn onderzoek naar een backuptool kwam ik bij Veeam overal mensen tegen die riepen hoe je nooit maar dan ook nooit SMB zou moeten gebruiken voor backups

Dat klinkt niet naar een officiële statement van Veeam, maar meer naar onderbuik gevoelens van forum gebruikers.

[Ben(V)]

Om zoiets voor elkaar te krijgen zou medion de sources van Samba moeten aanpassen.
Lijkt me heel erg onwaarschijnlijk en heeft uiteraard niets hier mee te maken.
Synology gebruikt enkel de standaard Samba implementatie.

Het verhaal van TS is zo wie zo wat vreemd.
Hij heeft het er over dat de "integrity test fails" en vervolgens roept hij dat het na een paar keer proberen wel past.
Een integrity test wordt pas gedaan als de backup gereed is en de data als op de target staat dus wat zou er dan nog moeten passen?

Nu weet ik niet wat voor Nas hij heeft, maar een integrity test vraagt wat van zo'n Nas en het kan zomaar zijn dat veenam timeouts krijgt tijdens zo'n test.
Veenam is geoptimaliseerd voor grote enterprise omgevingen en persoonlijk zou ik niet aanraden dat met een kleine Nas te gebruiken.

[Voor 4% gewijzigd door Ben(V) op 18-02-2023 13:31]

[F.West98]

Goed ik heb nogal wat losgemaakt Bedankt voor alle input!

Ik was in eerste instantie niet van plan dit een breder "backupstrategie" topic te maken, maar inmiddels lijkt dat bijna wel nodig om alle vragen goed te beantwoorden. Dus een zo kort mogelijk overzicht van de situatie:

Ik wil belangrijke bestanden backuppen bij zowel mn ouders als bij mij. Op beide locaties staat een Synology NAS (bij mij een 918+ met 4 + 4 + 8 + 18TB schijven in SHR met 16TB usable, bij mn ouders een 218+ met één 12TB schijf in SHR met dus 12TB usable), deze maken backups naar elkaar toe als "off-site backup". Daarnaast maakte ik ook nog een cloud-provider backup (hubiC), maar deze is er helaas mee gestopt en moet ik nog vervangen voor een nieuwe provider om zo mn volledige 3-2-1 strategie weer in ere te herstellen.

De hoeveelheid data van mn ouders is in totaal ongeveer 1.3TB, voornamelijk foto's van één PC. Ik heb zelf meer data, onderverdeeld in:
- 2TB boot drive (nvme ssd) met:
~300GB Windows + programma's

- 2TB data drive (nvme ssd) met:
~200GB Documenten (staan allemaal ook in OneDrive)
~300GB Development spul (staat waar mogelijk in Git repositories op GitHub/Lab)

- 16TB data drive (hdd) met:
~4TB Foto's
~500GB overig kleiner spul

Ik maak al jarenlang backups met default Windows File History, en dat werkte op zich al die tijd wel prima. Helaas is afgelopen december een schijf van mij gesneuveld in mn oude PC, en ook al had ik een backup van al mn belangrijke bestanden, ik was alsnog enkele dagen bezig met alle andere dingen terugzetten. Dit was een heel gedoe. Daarnaast heb ik in januari een nieuwe PC gebouwd, en merkte ik hoe het opnieuw installeren en instellen van Windows voor mij al snel meer dan een week duurt (ik heb custom config in zo ongeveer elk programma dat ik gebruik).

Ik bedacht me toen dat ik niet bij een kapotte SSD zomaar ineens een week kwijt wil/kan zijn aan kutten met Windows, en het mij best wat geld waard zou zijn om gewoon een recente image direct te kunnen restoren en binnen enkele uren verder te kunnen. Datzelfde geldt eigenlijk ook voor mn ouders. Daarnaast voel ik me niet heel senang bij het idee om nog lang af te hangen van Windows File History, aangezien het sinds Windows 11 ineens erg weggestopt is en niet meer actief onderhouden lijkt te worden.

Dus toen ben ik op zoek gegaan naar alternatieve oplossingen, en qua featureset bij Macrium Reflect uitgekomen. Goede support voor incremental en differential backups, backup integrity checks, en fine-grained scheduling en jobs waren voor mij belangrijke features, en dingen als viBoot zijn leuk meegenomen om eenvoudig ook een "restore" te kunnen testen.

Eerste backups liepen allemaal zonder problemen. Ik heb mijn data gesplitst in meerdere backup jobs met verschillende frequenties en redundancy afhankelijk van frequency of change, datagrootte, en "belangrijkheid" van de data. Ook de grootste job met al mn foto's ging prima, inclusief de verificatie na afloop (verificatie van de geschreven bytes, waarbij Macrium dus al die 4TB weer downloadt van de NAS om te verifiëren ).

Maar toen ik daarna voor de zekerheid nog eens een "verify" draaide (waarbij de data dus nogmaals in zn geheel van de NAS wordt gehaald om te integrity te checken adhv allerhande checksums) kreeg ik ineens een random integrity fail. Deze integrity check ging de derde keer wél weer gewoon goed met een full pass, maar ik werd suspicious (mede door de - kennelijk - spookverhalen over hoe SMB unreliable zou zijn). Ik heb toen ook mn C disk images opnieuw geverifieerd, en ook die verificatie gaat soms ineens random fout maar meestal wel goed. Voor de duidelijkheid: ik krijg dus geen foutmeldingen tijdens het backuppen, maar alleen maar tijdens de verificatie afterwards. Omdat die verificatie uiteindelijk wel passt ga ik ervan uit dat de data allemaal veilig op mn NAS staat, maar de random nature van de foutmeldingen baart me wel zorgen: vandaar dit topic dus.

---

Goed, nu wat specifieker reageren op jullie suggesties en reacties:

ThinkPad schreef op vrijdag 17 februari 2023 @ 06:52:
Nog wel belangrijke tip: gebruik een apart account op de NAS voor de SMB folder, zorg dat je andere accounts daar niet bij kunnen qua rechten en mount de schijf ook niet in je verkenner. Op die manier ben je nog iets beter beschermd tegen ransomware.

Staat zeker op de todo lijst om in te stellen zodra ik mijn definitieve backup strategy heb bepaald!

SVMartin schreef op vrijdag 17 februari 2023 @ 08:51:
@F.West98 wat bedoel je precies met "image backups van mijn schijven"? Zijn deze fysiek, virtueel, heb je de fysieke schijven in 1 desktop? En om wat voor data gaat het, staat er een operating system op, applicaties die mischien in gebruik zijn, of alleen foto's en documenten?

Zoals hierboven genoemd: 3 fysieke schijven; van 2 schijven maak ik image backups en van de derde maak ik file-based backups omdat ik niet alles wil/hoef te backuppen, en ook niet alles met dezelfde frequentie.

eheijnen schreef op zaterdag 18 februari 2023 @ 09:28:
Welke versie/variant van Macrium Reflect gebruik je eigenlijk?
Welke client OS gebruik je?

En kijk hier eens naar, een oplossing van Synology zelf:
https://kb.synology.com/e...upbusinessagent?version=7
https://www.synology.com/...active-backup-business/pc

Synology heeft dus een eigen client/server backup oplossing.

Nieuwste versie van alles; dus Windows 11 22H2 met Macrium Reflect v8.1.7378
Bedankt voor de link naar deze backup solution! Ik zal daar ook eens naar kijken. Ik weet nog niet of ik me zo wil lock-in naar Synology, maar ik zal er beter naar kijken.

---

Na alles gelezen te hebben vermoed/vrees ik toch dat mijn PC memory (nog steeds) de culprit is. Zoals eerder genoemd had ik initially wel stability issues met mijn RAM op hogere snelheden, maar nu is het op zich al weken rock solid en ook een memtest destijds had na ruim een nacht ook niets meer gevonden. Ik zal iig de komende dagen het volgende gaan proberen:

- Nogmaals memtest draaien op mijn PC
- De backups proberen te verifiëren vanaf mijn laptop als mn PC in memtest wel stabiel is
- Ook eens kijken of ik vanuit mn NAS wat meer informatie kan vinden als mn laptop ook integrity issues meldt.

[F.West98]

Korte update: ik heb voor ongeveer 22 uur memtest gedraaid op mijn PC zonder errors, en tijdens het proberen van een "verificatie" op mijn laptop kreeg ik helaas ook een failure (maar wederom bij een tweede poging ging het wél goed). Nu ga ik me toch afvragen of er niet iets in mn NAS misgaat, dus dat is het volgende dat ik ga onderzoeken.

[F.West98]

Na een boel verder testen snap ik nog steeds niet waarom de verificatie van bestaande backups soms faalt. De verificatie faalt dus af en toe zowel op mn PC als op mn laptop, maar memtest op zowel mn PC als laptop, en de Synology memory test laten alle drie geen issues zien na lang draaien... Hebben jullie hier nog enig idee waar dit door zou kunnen komen?

[SVMartin]

https://kb.synology.com/e..._Windows_SMB_CIFS_is_slow

Onder file sharing gaat het over smb signing. Dat is een integriteits functie die hier wordt uitgezet om de performance te verhogen. Hoe staat dit bij jou geconfigureerd?

[F.West98]

Goede suggestie! Die staat bij mij inderdaad uitgeschakeld... Ik denk dat ik maar eens een nieuwe share aanmaak met die integrity enabled, dan volledig nieuwe backups maak, en kijken of het probleem blijft.

[F.West98]

Helaas ook op de nieuwe share mét integrity weer vreemde intermittent fouten... At this point ga ik toch maar eens contact opnemen met de diverse betrokken bedrijven om te kijken wat er aan de hand is.

Screenshot for reference: