Fórum Root.cz
Hlavní témata => Software => Téma založeno: mkusyn2 18. 02. 2022, 19:20:40
-
Zdravím všechny,
prosím o radu. Vytvořil jsem si domácí NAS ze zbylého PC a dvou 3TB disků. Puštěno bude občas jen pro příjem dat přes síť. Z toho důvodu jsem upustil od Raid1. Na fóru openmediavault to moc lidí nedoporučuje, pokud se pouští takto občas.
Jdu tedy rsync cestou na druhý disk, s tím, že po nějaké době inaktivity NAS, se pustí rync a NAS se vypne.
Nicméně pokud pustím rsync -ahv tak se dost dlouho skenuje disk. Nevím jak přesně hledá změny, ale trvá to klidně i 2 minuty a i když se nic nenajde. Běhěm toho pracuje hlasitě disk. Tomu bych se chtěl vyhnout, abych po každém puštění projížděl celý disk. Kde je chyba ? V parametrech jsem nic nenašel. Může být tím, že fs je NTSF , z původních windows ?
Díky za radu.
-
Není to žádná chyba, rsync takhle pracuje (a nemůže pracovat jinak). Když chcete synchronizovat dva disky, rsync musí projít všechny soubory, zjistit, které jsou na druhé straně starší nebo tam chybí, a ty na druhou stranu přenést. Standardně rsync neprochází obsah všech souborů, jenom ty, kde se liší velikost nebo čas, ale projít všechny soubory na disku musí. OS neposkytuje (ani neukládá) žádné informace o tom, které soubory se změnily od nějaké doby.
-
k tomu co napsal Filip navic:
- proc tam mas NTFS pokud ten NAS bezi na GNU/Linuxu tak je to nesmysl, minimalne z toho duvodu ze po naboreni filesystemu nemas zadnej nastroj na jeho opravu...
- ze RAID1 nekdo nedoporucuje "kdyz se to pousti obcas" je take blbost, obzvlast pokud ten "RAID1" delas pak rucne pres rsync ;-) i kdyz jeden duvod by asi byl, pokud bys to poustel 1x mesic, tak by se pokazde "zrovna" delal check pole, ale vypnout casovace ktere to delaji (mdcheck_start.timer a mdcheck_continue.timer) je porad jednodusi nez to resit pres rsync ;-)
-
Není to žádná chyba, rsync takhle pracuje (a nemůže pracovat jinak).
Pomohlo by, kdyby FS uměl při změně souboru nastavit rekurzivně flag "změněno" (resp. čas změny) nadřazeným adresářům až po /. Pak by rsync nemusel skenovat všechny soubory, ale vyhazoval podstromy, co se nezměnily. Znamenalo by to nějaké zpomalení při zápisu, ale třeba Apple se chlubil, že něco podobného dělá (APFS fast directory sizing).
-
Pokud jsou ty disky ve stejném stroji a ne, nějakým způsobem oddělené, tak je to opravdu úkol pro RAID.
Zajímalo by mě, z čeho v tom openmediavault vycházeli.
RAID vás samozřejmě primárně chrání před chcípnutím jednoho z disků. Zato vás nechrání před spoustou jiných případů ztráty dat.
Pokud ne RAID, tak pak uvažovat o jiných způsobech zálohování, které sice budou náročnější na zprovoznění, ale nabídnou možnosti, které vám RAID nedá. Mohou to být metody založené na plné a rozdílových zálohách, nebo na využítí možností speciálnějších souborových systémů a snapshotů, nebo distribuované ukládání používané v HAL systémech (https://cloud.netapp.com/blog/cvo-blg-high-availability-cluster-concepts-and-architecture).
Optimální řešení záleží na mnoha faktorech, objem a charakter zálohovaných dat (hromada malých souborů / velké soubory, stabilní data + drobné přírůstky, masivní přepisování velkých objemů {editace videí}, ... ), zda je záloha na NASu až sekundární kopie dat v PC, nebo primární, možnosti mít ty disky geograficky odděleny, vzácnost těch dat a o jak velký časový úsek je možné přijít, způsob připojení těch dat mezi NASem a PC (FTP / SAMBA / NFS / ...), ...
-
Tak moznost by bola
find -mtime odporucam find -- help to ale bude zrejme fungovat na fs ktory si uklada cas zmeny suboru, ako na tom ntfs neviem.
I ked preco, ked prirodzenejsie je pouzit raid. To kopirovanie vas proti nechcenym zmenam neochrani - zmeny sa skopiruju. Naproti tomu raid ochrani proti zlyhaniu disku spolahlivejsie. Ak budete kopirovat z poskodeneho disku, tak si velmi lahko ponicite data aj na tom zdravom cielovom disku...
-
Tak moznost by bola find -mtime odporucam find -- help to ale bude zrejme fungovat na fs ktory si uklada cas zmeny suboru, ako na tom ntfs neviem.
Takže místo aby rsync procházel všechny soubory na disku a zjišťoval, jestli se změnil jejich čas změny, tak by find procházel všechny soubory na disku a zjišťoval, jestli se změnil čas změny… Hm, jak by to asi mohlo pomoci?
Jediný rozdíl je v tom, že rsync to porovnává proti času modifikace souboru na protějším disku, takže ho také musí načíst. Ale pokud není cílový disk pomalejší, než zdrojový, nemělo by to mít na přenos podstatný vliv.
NTFS čas změny souboru ukládá.
Nicméně pokud vím, NTFS ukládá čas změny s nižší přesností, než Linux, což by znamenalo, že i stejné soubory musí rsync porovnat podle obsahu. rsync by měl ve výchozím nastavení porovnávat čas modifikace s přesností na sekundy, ale teoreticky může být někde výchozí nastavení jiné. Některé verze rsync mají přepínač --modify-window, kterým je možné nastavit, jak různé časy modifikace souboru má rsync ještě považovat ze stejné.
-
Když říkáš že se jedná o NTFS filesystém, nešel by použít příznak A tj. archive?
Tady píšou že i v Linuxu se s ním dá pracovat: How do I set the archive Bit of a file shared with samba (https://serverfault.com/questions/993228/how-do-i-set-the-archive-bit-of-a-file-shared-with-samba).
Tj. vybrat seznam souborů který ho mají nastaven => nakopírovat na druhý disk a pak atribut shodit. A jednou za čas provést kompletní sync pro jistotu.
-
Jediný rozdíl je v tom, že rsync to porovnává proti času modifikace souboru na protějším disku, takže ho také musí načíst. Ale pokud není cílový disk pomalejší, než zdrojový, nemělo by to mít na přenos podstatný vliv.
Tak si skuste cez time porovnat find a rsync so zapnutym dry run, nech ten rsync len porovnava. Potom si mozete pogooglit preco je tam rozdiel. Bude to uzitocnejsie, nez tie troliace eseje...
-
Rsync byl primárně navržen tak, aby synchronizoval obsah obou disků. Proto porovnává velikost souborů. Pokud chcete jen dělat zálohu (víte, že data na zálohovacím disku žádný proces změnit nemůže), zálohujte jen data modifikovaná po poslední záloze. Dá se použít již zmiňovaný find v kombinaci s cpio nebo tar. Hotová řešení možná na internetu budou. Jinak je to skript na pár řádek.
-
je hezke jak tu vymejslite moznosti, ale to se vazne skoro nikdo nepozastavita nad zbytecnosti rucne delat sync 2 lokalnich disku misto pouziti raid1? ;-)
-
je hezke jak tu vymejslite moznosti, ale to se vazne skoro nikdo nepozastavita nad zbytecnosti rucne delat sync 2 lokalnich disku misto pouziti raid1? ;-)
Jj, ja som tam k tomu pripisal ze je spravne pouzit raid, ak zmrsi data uzivatel tak v oboch pripadoch bude vysledok rovnaky, ak mu rachne prvy disk, tak rsync alebo copy bude kopirovat len nez sa vyskytne chyba, kdezto raid tomu predide...
-
je hezke jak tu vymejslite moznosti, ale to se vazne skoro nikdo nepozastavita nad zbytecnosti rucne delat sync 2 lokalnich disku misto pouziti raid1? ;-)
Jj, ja som tam k tomu pripisal ze je spravne pouzit raid, ak zmrsi data uzivatel tak v oboch pripadoch bude vysledok rovnaky, ak mu rachne prvy disk, tak rsync alebo copy bude kopirovat len nez sa vyskytne chyba, kdezto raid tomu predide...
No tak co muze nastat.
1. Crypto - na to je RAID naprd.
2. Fail disku tak, ze neni v systemu videt - rsync nic nesynchronuzuje. Pokud slozka/disk neni vubec pristupna, tak pochybuju, ze smaze druhy mirror. Nezkousel jsem, slo by overit vypnutim disku a pustenim rsync.
3. Fail disku tak, ze je filesystem, ale pres vadne sektory neprectu nektere soubory. Opet tezko testovatelne, ale pokud se soubor neprecte, asi ho nesmaze na mirroru.
Existuje lsyncd, ktery monitoruje zmeny v adresarich a potom dela jen pres rsync kopie. Pokud nezmenim soubor, tak se na prvnim disku muze stat cokoliv, druhy disk je stale ok.
Na foru OMV je plno threadu o degradade RAIDu, za mne je to pro muj ucel zbytene. Pak se k souborum nedostanu. Lsyncd je celkem dobre reseni. Druha varaianta, pokud nechci uplne live zalohy, tak rsync pustit jednou za cas.
-
3. Fail disku tak, ze je filesystem, ale pres vadne sektory neprectu nektere soubory. Opet tezko testovatelne, ale pokud se soubor neprecte, asi ho nesmaze na mirroru.
No, rsync pouziva delta-transfer na vzdialene fs, na lokalne pouziva copy. Takze ak budete mat nastavene aby sa riadil podla mtime a nie podla obsahu(vyrazne pomalsie) tak v zalohe budete mat len to co sa mu podarilo precitat, minus to co pri chybe neflusne z buffferu.
Ale ono je to asi jedno, kedze zalohujete na disk, tak to zrejme nebude nic dolezite...
-
Ale napada ma este ina alternativa, pomocou
inotifywait -e modify si mozete vytvorit subor s cestami k zmenenym suborom a nim vymedzit co ma rsync synchronizovat. Aka je podpora inotify na ntfs, neviem najdete na webe...
-
Ještě mě napadá elegantní synchronizace, kdyby tam nebylo NTFS, ale Btrfs: přes btrfs send/receive. Ideálně v kombinaci se snapshotem: Uděláš read-only snapshot (aby se syncoval jakž takž konzistentní stav), na zdrojovém disku rsync send, na cílovém rsync receive, přenesou se jen změny od posledního syncu, smažeš snapshot.
Ale jak říkají už předešlí, je to blbost to dělat, když přesně na to tu máme RAID1.
-
Ještě mě napadá elegantní synchronizace, kdyby tam nebylo NTFS, ale Btrfs: přes btrfs send/receive. Ideálně v kombinaci se snapshotem: Uděláš read-only snapshot (aby se syncoval jakž takž konzistentní stav), na zdrojovém disku rsync send, na cílovém rsync receive, přenesou se jen změny od posledního syncu, smažeš snapshot.
Ale jak říkají už předešlí, je to blbost to dělat, když přesně na to tu máme RAID1.
Ano, kdyby se ta data měla synchronizovat „jednou za čas“ (ne přes RAID 1), je podle mne btrfs a send/recive ideální řešení – pokud v tom NASu může btrfs použít.
Jinak pokud budou oba disky v NASu neustále, je podle mne RAID1 nejlepší řešení. Postará se o to přímo NAS, nehrozí, že nějaké vaše skripty selžou. Stejně byste tou občasnou synchronizací nic neušetřil – stejně NAS nastartuje oba disky.
Pokud je ten záložní disk externí a chcete ho připojovat jenom občas (abyste minimalizoval riziko, že třeba nějaký elektrický výboj odpálí oba disky najednou), pak dává smysl použít tu synchronizaci. A pak bych volil to btrfs send/receive, pokud je to možné – tím se přenesou opravdu jenom ty bloky, které byly změněné. Takže se třeba nebudou kopírovat ani přejmenované soubory (jen se změní jejich název) nebo části souborů, které se nezměnily.
Obecně rsync je vhodný hlavně na přenos dat po síti (když je síť výrazně pomalejší, než disky). Při lokálním přenosu toho rsync nedokáže ušetřit zdaleka tolik, protože stejně musí zjistit, co se vlastně změnilo, a to nezjistí bez přečtení alespoň metadat.