Silent data corruption při přenosu

Silent data corruption při přenosu
« kdy: 22. 01. 2025, 19:26:41 »
Zdravím,

Měl bych dotaz.
Data uložená na NAS (2disky, raid1,LVM) se budou kopírovat přes smb do VM běžící v Proxmoxu (2disky raid1,LVM, ECC paměť).
Může po cestě nebo při zápisu dat dojít k poškození dat, aniž bych se o tom dozvěděl, tzn. bez nějaké chybové hlášky?
Co jsem googlil, tak snad u zápisu s ECC paměti by to mělo být ok, ale nedohledal jsem jestli na zdroji a po cestě přes smb probíhá nějaké ověření.


jjrsk

  • *****
  • 654
    • Zobrazit profil
Re:Silent data corruption
« Odpověď #1 kdy: 22. 01. 2025, 19:44:18 »
ECC ti na to nijak nepomuzou, normalne se to dela tak ze se data po preneseni overi. Treba tak ze si na zdroji spocitas hash a na cily ho overis.

CPU

  • *****
  • 947
    • Zobrazit profil
    • E-mail
Re:Silent data corruption
« Odpověď #2 kdy: 22. 01. 2025, 19:54:10 »

Na straně serveru:
- po cestě (Ethernet) se ti data nejspíš nepočubčí, jsou tam kontrolní součty
- v paměti taky ne (pokud jsou ECC)
- CPU/L2 cache má ECC by default
(Tohle máš ošetřené lépe nebo hůře, teoreticky při několika stovkách ZB k chybě může dojít, prakticky spíš ee.)

No a jaký to je NAS?

Třeba na Synology je potřeba zapnout ochranu SiletDataCoruption.

https://kb.synology.com/cs-cz/DSM/tutorial/How_to_enable_file_self_healing_on_DSM

Re:Silent data corruption
« Odpověď #3 kdy: 22. 01. 2025, 20:14:39 »
Dalo by se tedy zjednodušeně říct, že přenos přes smb a následný zápis by měl být relativně ok, a riziko je spíše, že data by už byla poškozena na zdrojovém NASu?

Je to starší qnap, v nastavení je tam možno pustit “integrity check” ale nevím jak moc tomu lze věřit

CPU

  • *****
  • 947
    • Zobrazit profil
    • E-mail
Re:Silent data corruption
« Odpověď #4 kdy: 22. 01. 2025, 20:23:45 »

No potřebuješ používat takové prostředky, abys byl v pohodě:

QNAP umí ZFS a řešit i SDC.
https://www.qnap.com/en/how-to/tutorial/article/how-to-prevent-silent-data-corruption-by-using-data-scrubbing-schedule

Jak si usteleš, tak si lehneš  8)



Re:Silent data corruption při přenosu
« Odpověď #5 kdy: 22. 01. 2025, 20:59:40 »
Ty BTRFS fíčury (checksumy, selfhealing při čtení a scrub) v DSM bych sem teď asi nemíchal. Ne že by to v určitých situacích nebylo užitečné, ale dává mi to smysl řešit hlavě při nastavování NASu, případně jako třeba to scrubování jako nějakou periodickou úlohu.
Nicméně s QNAPem je to stejně jedno, protože nepoužívá BTRFS. Ekvivalentní funkce je jenom na novějších QNAPech se systémem QUTS Hero, které mají ZFSko. Na starších modelech je EXT4 nad MD raidem.

Jestli jsem to správně pochopil, tak chcete udělat jednorázovou migraci dat, co tam už jsou, a něco přelít z NASu na virtuál? Pokud tam není zmíněný systém se ZFS, tak už s uloženými daty stejně nic neprovedete.
Jak už bylo zmíněno, pokud máte obavy o integritu dat během přenosu nebo prvotním uložení na novém NASu, oveřte si checksumy všech souborů.

Je tam víc možností jak to udělat.
Nejjednodušší je například dvojím spuštěním rsyncu. Prvním sesynchronizujete adresáře, a při druhém přidáte parametr -c (--checksum). Pokud napodruhé nepřenese žádný soubor, tak sedí kontrolní součty.
Nevýhoda je, že se dvakrát čtou soubory přes síť, což může být docela na dlouho.

Další varianta je v duchu toho, to co jsem zmiňoval. Teď si z hlavy nevybavím, co je v systému u každé konkrétní varianty QNAPu, ale měl by stačit příkazy find, xargs a md5.
Z kořenové složky toho adresáře, co se kopíruje bych spustil něco jako:

find . -type f -print0 | xargs -0 md5sum > /nekam/overovaci-soucty.md5

Tím se udělají kontrolní součty lokálně, což bývá typicky rychlejší než po síti. Pak se zkopírují data + overovaci-soucty.md5, a na novém serveru z cílového adreáře můžu spustit lokální ověření.

md5sum --quiet -c /tmp/overovaci-soucty.md5
Což vypíše jakýkoliv soubor u kterého případně součty nebudou sedět.

Také rclone to také v nějaké formě umí (asi by se musela stáhnout binárka do systému toho QNAPu pro lokální ověřování). Podobně pokud byste to kopíroval po síti přes další stroj např. z Windows, tak se dá využít například program FastCopy, kde je vestavěná verifikace (samozřejmě se stejnou nevýhodou jako u toho rsyncu). Atd.

Re:Silent data corruption při přenosu
« Odpověď #6 kdy: 22. 01. 2025, 23:03:26 »
SMB nevím, ale mám relativně časté (častější, než bych chtěl) zkušenosti se špatnými přenosy souborů přes ssh. Tam jsem musel kontrolu aplikovat (používám cksum). Zmiňuji to jen do počtu jako okrajově tématické. Pokud mi někdo potvrdí, že u [scp a/nebo sftp] je toto normální (za předpokladu třeba vady nějakého hardwaru, který se ale jinak tváří, že mu nic není), budu rád, neb mi to krapet vrtá hlavou.

Re:Silent data corruption při přenosu
« Odpověď #7 kdy: 22. 01. 2025, 23:46:18 »
SMB nevím, ale mám relativně časté (častější, než bych chtěl) zkušenosti se špatnými přenosy souborů přes ssh. Tam jsem musel kontrolu aplikovat (používám cksum). Zmiňuji to jen do počtu jako okrajově tématické. Pokud mi někdo potvrdí, že u [scp a/nebo sftp] je toto normální (za předpokladu třeba vady nějakého hardwaru, který se ale jinak tváří, že mu nic není), budu rád, neb mi to krapet vrtá hlavou.

scp i sftp používám docela intenzivně na různých platformách i spojeních, byť se nejedná úplně o nějaké terabajtové přenosy nebo miliony souborů. A v zásadě jsem na žádný principiální problém s poškozováním při přenosech nenarazil.
Jasně někdy třeba může vypadnout spojení, ale ani po případném navázání nemívám problémy s integritou souborů.
Server je klasicky nějaká verze OpenSSH (Dropbear mám jen v nějakých routerech) od Linuxů, Maců, Raspberry i Windows 10 s portem OpenSSH. Klienti pak různé podle toho, odkud dělám. Nejčastěji OpenSSH klient z terminálu, občas WinSCP, co používá v podstatě Putty, někdy batch přenosy s lftp nebo Rclone, nárazově i GIO/GVFS klient z GNOME.
Jediné, co nepoužívám a s čím mám špatné zkušenosti, jsou takové ty virt. filesystémy přes FUSE - sshfs, kdy so to pak tváří jako namountovaná složka.

r223

Re:Silent data corruption při přenosu
« Odpověď #8 kdy: 23. 01. 2025, 08:10:20 »
A co rsync @ ssh? Ten funguje na urovni hasho inherentne.


Re:Silent data corruption při přenosu
« Odpověď #9 kdy: 23. 01. 2025, 10:50:08 »
A co rsync @ ssh? Ten funguje na urovni hasho inherentne.

To je trochu složitější.
rsync přes SSH funguje tak, že se na cílové straně spustí druhá instance rsyncu a SSH se použije jako zabezpečený komunikační kanál.
SSH zajistí, že se po cestě nezmění data pomocí MAC (message authentication code). Zjednodušeně řečeno pro každý paket se vytvoří kód podle jeho obsahu, sekvenčního čísla a klíče. Totéž pak spočítá druhá strana po přijetí, když se to shoduje, paket se bere. Jestliže se neshoduje, tak se typicky spojení rozpadne (protože bezpečnost - tampering, man-in-the middle atp).
Mimo to jsou tam samozřejmě i další mechanismy u síťových vrstev pod tím. Např. u TCP musí přijímací strana potvrzovat přijetí každého paketu, pokud nepotvrdí, posílá se znovu (retransmission).

Jinak porovnání souborů k synchronizaci u rsync samotného funguje stejně, ať už je puštěný lokálně, přes ssh nebo přes nativní server.
Při první synchronizaci (cílový adresář je prázdný) zjistí, že tam nejsou žádné soubory a kopíruje všechno od začátku do konce, žádné kontrolní součty se nepoužívají. Při druhém spuštění se stejným zdrojem a cílem se zjišťuje, jestli je stejná délka každého souboru a čas změny. Pokud ano, tak se přeskakuje. Když se liší, tak se počítají kont. součty pro bloky ve zdrojovém a cílovém souboru, porovnávají se a následně se přenesou jen změněné bloky (nebo celé soubory, záleží na nastavení).
Tohle výchozí chování se dá změnit různými direktivami. Když použijete -c (resp. --checksum) při druhém spuštění, jak jsem zmiňoval, tak se vynutí, aby rsync vždycky porovnával všechny soubory. Takže se to dá použít právě i na ověření úspěšného přenosu.

Takže opravdu záleží, co všechno chcete kontrolovat, resp. jak moc jste paranoidní :)
Pokud vám jde jen o to minimalizovat rizika změny dat při přenosu po síti (reálně se to opravdu moc neděje, zvlášť v LAN), tak ten SSH tunel tomu může pomoct (nebo něco s podobným mechanisme, např. SMB 3.1 má také podepisování, NFS 4.1 může mít TLS).

Jestli chcete ale otestovat kompletní kopírování dat (tzn. čtení, přenos po síti, zápis, jakékoliv další chyby v procesu), tak to musíte udělat jako další krok až potom, co se kompletně zapíší.


Re:Silent data corruption při přenosu
« Odpověď #10 kdy: 23. 01. 2025, 11:47:02 »
Já si doma provozuji TrueNAS a disky sdílám přes NFS. Měl jsem špatně nastavený mount options na klientu, které mi způsobili, že když jsem kopíroval např. 400 MB soubory, tak se mi ne všechny ukládali v původní velikosti. Někdy to bylo 400 MB, někdy 230 MB a někdy 388 MB. Konkrétně za to mohla option "mountproto=udp", kterou jsem zapomněl smazat (částečně jsem se inspiroval na Internetu, jaká jsou doporučená mount options pro NFS). V logách jsem nikde nenašel problém s kopírováním (protože UDP). Třeba Ti to pomůže ... a třeba ne.

RDa

  • *****
  • 2 833
    • Zobrazit profil
    • E-mail
Re:Silent data corruption při přenosu
« Odpověď #11 kdy: 23. 01. 2025, 13:45:46 »
Data se muzou rozpadnout vzdy - klidne na urovni SATA rozhrani, nebo kvuli logicke chybe (jako ukazoval pan s nfs/udp).

Nedavno se me zacali treba objevovat na torrentu chyby, ze nesedi checksum nejakeho bloku.. celkem wtf, ale taky bylo cilem NFS a nasel jsem pak nejaky bug report ze se to stat muze. Takze dobry wtf.

Pokud jde o offline prenos, tak jdi na to skrze checksumy - vytvor si je na vysilaci strane, zkopiruj vse, nech overit checksumy. Radeji si pockam 1+1+1 den na tyhle operace nad 80TB daty, nez to mit zkopirovane za 1 den a pak v budoucnu resit podivne problemy, ze se nejaky bit flipnul. Ty 2 dny navic jsou zanedbatelna rezie z pohledu doby zivota takovych dat.

A ne, zalohy na tento problem opravdu nepomuzou (nikdo typicky nekontroluje aktualni stav vuci zaloham z pohledu samotnych dat).

JmJ

  • ****
  • 327
    • Zobrazit profil
Re:Silent data corruption při přenosu
« Odpověď #12 kdy: 23. 01. 2025, 15:17:35 »
Ja jsem zazil situaci, kdy pri prenosu souboru o velikosti jednotek GB pres rsync doslo k chybe kontrolniho souctu preneseneho souboru. V PC sem vymenil vse od sw pres hw krome vice jak 10 let stareho CPU a desky, ale nepomohlo to. Tak sem vzal o neco mladsi srot bylo po problemu.

Pokud chci mit jistotu, ze se vse zkopirovalo dobre, pak je opravdu nutne udelat kontrolni soucty.