Dotaz: rsync na USB disk (backup), ale s binárním ověřením

[palardd]

Ahoj,

používám rsync, kterým z RAID1 zálohuji na externí disky a nyní bych to rád rozšířil o kontrolu, zda to zapsané na externím disku je skutečně to, co je na originále.

(rsync a filesystému věřím, že má své postupy a hlídá se to, ale ta data jsou pro mě důležitá)

Babrám se s tím už dlouho, ale nedaří se mi vygooglit smysluplný příkazový řádek... (ano, počítám s tím, že to bude trvat fakt dlouho = mám 6 TB dat (fotografie))

---

---

Odpovědi

[palardd]

má být BAJTOVÝM ověřením, omlouvám se

[PetebLazar]

Nemůže takový postup narazit na vliv cache, jelikož se při kontrole následně po kopírování (např. kontrolním součtem souborů na ext.storage) bude výpočtem kontrolovat co se mělo zapsat (stále nacachovaný obsah) a ne co na externím storage opravdu leží?

[jiwopene]

6 TB dat v cachi už asi nebude.

[PetebLazar]

Pozn. Tím "následně po kopírování" jsem měl na mysli po jednotlivých souborech.

[lertimir]

No záleží, jak si to představuješ? můžeš použít bindiff a projít přes všechno přes find exec, nebo jen ve find mít selekci na čas takže se budou porovnávat jen ty které jsou novější než. nebo mít napočítané hashe pro původní data a po přenosu spočítat nové hashe.

Jinak tě chápu, Mám svých fotek sice jen 1TB, ale také mi na nich hodně záleží. Mám je uložené tak, že primární data jsou na btrfs RAID1 (kontrola checksumu, týdenní scrub), zálohy jsou jednou na jeden jiný disk uvnitř stejného kompu také btrfs (týdenní scrub), jednou na RAID5 na serveru jinde v bytě a jednou na NASu v práci s RAID1, když by nastala totální katastrofa v bytě. synchronizuji rsyncem a vzdáleně přes unison. Jedou za čas (3 měsíce) projedu bindiff kopie.

[Jendа]

Spočítal bych SHA256 hashe všech souborů (find | exec sha256sum), setřídil (protože z findu to leze v náhodném pořadí) a diffnul. U malinkých (pár kB) souborů by to mělo moc velkou režii, ale u fotek to bude v pohodě.

Pokud je dat podstatně víc než je velikost RAM, tak cache nebude mít vliv, ale pokud si chceš být jistý, tak na začátku echo 3 > /proc/sys/vm/drop_caches. Případně nejlepší bude ten disk fyzicky odpojit a připojit.

[Peter Golis]

Ahoj. Program rsync robí binárne porovnanie pri synchronizovaní dát, takže pri lokálne pripojenom USB by si to mal mať zaručené.

Problémom je to, že takáto vec ťa neochráni pred "silent data corruption", teda tichou stratou dát. Od toho ťa uchráni len redundantné uloženie dát, použitie súborového systému s checksummingom na dáta a pravidelnou kontrolou (scrub) ktorá by odhalila chyby v predstihu. Síce niesom zástanca BTRFS, ale pre jeden disk by som použil BTRFS s profilom DUP. Neochráni to na 100%, ale oddiali to stratu dát.

PS: USB disk čo má udržať dáta o veľkosti 6T, veľa zdaru s nahrávaním na SMR platne.

[Jendа]

Program rsync robí binárne porovnanie pri synchronizovaní dát, takže pri lokálne pripojenom USB by si to mal mať zaručené.

Ne, defaultně ne, pokud souhlasí datum modifikace a velikost.

DUP nepotřebuje, stačí mu to detekovat a při detekci přepsat z originálu/jiné zálohy (případně dotyčný disk vyhodit jakožto nespolehlivý).

[Peter Golis]

Ne, defaultně ne, pokud souhlasí datum modifikace a velikost.

To bolo východzie chovanie pri vzdialenom prístupe. Kedy to prosím zmenili?

DUP nepotřebuje, stačí mu to detekovat a při detekci přepsat z originálu/jiné zálohy (případně dotyčný disk vyhodit jakožto nespolehlivý).

To by ale človek musel pravidelne kontrolovať všetky inštancie cenných dát. A čo čert nechce, ...

No, cena za diskový priestor je naozaj minimálna. Ale, baviť sa o investícii do bezpečnosti majetku, to zaváňa neformálnou komunikáciou. Skutočne neformálnou, slušne povedané.

[Jendа]

Tak jednak podle popisu to má tazatel nejspíš připojené jako blokové zařízení někam, a jednak ne, ani při vzdáleném kopírování se soubory nečtou, a to minimálně od 2011 kdy to používám.

To by ale človek musel pravidelne kontrolovať všetky inštancie cenných dát.

Tak předpokládám, že ty zálohy stejně občas aktualizuje (dohrává tam nové fotky).

A když má DUP, tak bude potřebovat větší disky. A má toho 6 TB, takže by potřeboval 12TB disk, což dneska není běžné. Takže má lepší když si koupí 2x víc 6TB disků a kromě silent data corruption je chráněn i před selháním HW.

[Peter Golis]

Ja som bol v tom že rsync stále porovnáva obsah súborov ak pracuje s lokálne pripojenými diskami. Teraz som si to po rokoch skúsil, a pochopil som prečo tam medzičasom pridali parameter --ignore-times . Pravda je, že som to už veľmi dlhú dobu na takéto niečo nepoužil. Riešil som to inak. A že to porovnávanie bolo vo východzom stave vypnuté pri vzdialenej synchronizácii viem.

A ohľadne zálohovania 6T na disky, tak ono je vôbec otázne či sa oplatí používať tak veľké disky keďže 6T bude v dnešnej dobe určite SMR. A výkon bude pri presypaní fotiek dosť žalostný, keďže jedna dávka bude určite väčšia ako cache na takom disku.

[lertimir]

Proč by měl být žalostný. je to seriový zápis velkého množství dat, SMR je žálostné při náhodném zápisu, kdy se i při malém zápisu musí přečíst a znovu zapsat celý SMR segment. Ale na druhou stranu znovu platí to, co jsem psal před cca 9 lety k SSD diskům. Proč disky nereportují skutečnou infomaci, jak zápis skutečně probíhá??? Pak by design filesystému mohl reálný zápis podporovat. Dokýžu si jednoduše představit, že by třeba zápis do SMR bloku byl podobný logově orientováno filesystemu NILFS, a při uvolňování a mazání z bloku by se provedl "garbage collection" celý blok by se přečetl uvolnil a to co by bylo třeba nechat by se zapsalo jinam. Nebo by se tímto způsobem přizpusobil CoW FS jako btrfs, ale to že na úrovní FS se neví co se v reálu skutečně děje znamená že se provádějí chybná rozhodnutí a s důsledky pro rychlost.

[Peter Golis]

Ten zápis sa spomalí po včerpaní cache, nielen pri náhodnom prepise dát. Podľa objemu fotografií ktoré chce zálohovať používa (aj) RAW formát, a jedna séria takýchto fotiek je určite väčšia ako cache na SMR disku. Takže sa mu to fajnovučko spomalí. Ktori to tu pred pár dňami rozoberal, že jak sa mu to rovno zastavilo, a predpokladaný dojazd kopírovania bol cez týždeň.

Na druhú stranu, mňa zaujímalo už pred cca dvoma desaťročiami (v čase keď sa začala vo veľkom používať LBA na HDD), že prečo disky nereportujú reálnu geometriu. To si naozaj ľudia myslia že disky majú doteraz geometriu vyžadovanú MS DOS, teda veľkosť sektoru 512b, 16 hláv a 63 sektorov na track, a to aj pri SSD ktoré žiadne platne a ani hlavy nemá? Už len ten checksumming pre tak malý sektor dokáže zožrať značnú časť kapacity disku. Že v takejto sprostosti pokračuje aj SSD (zle reportovaná geometria, nereportovaná opotrebovanosť pam. buniek) je už len zatajovanie potrebných informácií pred špecifickým zákazníkom. Disky v bežnom segmente morálne zastarávajú skôr ako sa opotrebujú. A pre Enterprise segment, kde sú tieto informácie potrebné, sú určené iné disky so špeciálne upraveným FW.

[lertimir]

V roce 12 jsem psal přesně totéž.

[Peter Golis]

Na druhú stranu, ani by som sa nedivil keby tí výrobcovia HDD naozaj používali 512b sektory, a vypli checksumming. Dosť prípadov Silent Data Corruption mi vrátilo binárne nuly namiesto chyby ak sa daný sektor nedal prečítať.

A v takýchto prípadoch je pochopiteľné ak výrobcovia zatajujú dôležité informácie. Ale nie je to žiadúce pre zákazníka. Jedná sa o účelové zatajenie skutkovej podstaty.

[PetebLazar]

Pochybuji, že si někdo dovolí vypnout checksumming potřebují ho minimálně pro potvrzení že data se načetla OK. Samozřejmě je otázkou jakou dobu (ERC/TLER/CCTL) věnují dopočtu při detekci chyby, u serverových HDD to bude asi velmi málo (ať se stará vyšší level .. RAID), u desktopových to bývaly jednotky sekund.

Zmiňuje se, že za 512B sektorem je na HDD ještě 50B ECC (sync/gap/address_mark před sektorem vydají za 15B), u 4KB bloku má být ECC dlouhé 100B (proti 512B úspora na samotném ECC 300B/4K).

Někdy mi ty konspirační teorie okolo HDD připomínají chemtrails, Flat Earth atd. Přitom to nejsou žádná tajemství, jen klasická honba za mamonem ve střetu s obecnou snahou levně nakoupit.

[lertimir]

Nezkoumal jsem to ted, ale mám dojem že síla ECC pro recovery je na 4k blocích větší než na 512B i když je procentuelně menší redundance. Se zmenšováním rozměru bitu roste chybovost a proto potřebujeme lepši ECC.

[PetebLazar]

Je to možné, všechny zdroje na které jsem zatím narazil a zmiňují délku ECC u 4K zmiňují 100B. Efektivita použitého algoritmu prý údajně roste s délkou dat, tak proto možná stačí (pokud tedy těch 100B odpovídá skutečnosti) pouze dvojnásobek (proti 50B ECC u 512B sektorů). Jde údajně o teoretické minimum zajišťující shodnou spolehlivost jako u 512B/50B_ECC, výrobci si to samozřejmě mohou implementovat po svém a asi tak i činí (prakticky se na toto téma nevyjadřují, může jít o jejich konkurenční výhodu).

[Josef Kufner]

rsync -c ... zdroj cíl

Při běžném pouzití se dělá porovnání jen podle metadat, ale -c vynutí kompletní kontrolu. Pokud máš malý objem kritických dat, můžeš to používat při běžné záloze. Na 6TB se to moc nehodí, na běžné použití to bude trvat velmi dlouho.

Pro konzistenci fotografií bych udělal lokální soubory s sha1 každého souboru v každém adresáři.

Tedy v každém adresáři spustit: sha1sum *.jpg > checksum.sha1

Jinými slovy: find -type d -execdir sh -c 'sha1sum *.jpg > checksum.sha1' \;

Pak bude stačit porovnat ty vygenerované soubory v originále a v záloze, třeba pomocí diff, nebo znovu pomocí find -name checksum.sha1 -exec sha1sum '{}' \+ (a pak diff jen těch výsledných souborů). Výhodou je, že později můžeš znovu ověřit konzistenci bez použití jiné kopie zálohy, neboť to už budeš vědět, že checksumy jsou správné.

(Uvedené příkazy jsem netestoval – použij vlastní hlavu než je spustíš.)