Zálohování po pomalé lince

[Filip Jirsák]

Ja sem rsync taham jako priklad situace, kdy vznika problem s timestampy. Vysvetlovat, jak funguje rsync a jak dela kontrolni soucty a prenasi jen zmenene bloky, jste zacal vy. Cili jste zase neco nepochopil, tak nedelejte chytreho.

Tazatel se ptal na WebDAV od Microsoftu. Řešit u toho,jak se chová rsync mezi lokálními disky je dost mimo, nemyslíte? A když už to chcete řešit, tak to musíte explicitně napsat, jinak budou ostatní očekávat, že řešíte pořád alespoň něco příbuzného, tedy rsync přes síť.

[Reklama]

[crown]

Kdyz vim, ze jsem jediny, kdo soubory na vzdalenem disku modifikuje, tak nepotrebuju, aby pokazde probihala kontrola znovu. Stejne vrati ten samy vysledek jako minule. Stacilo by mi si zapamatovat vysledek kontroly jednou a pouze upravovat dilci data, kdyz se tam ode mne synchronizaci priadji nove nebo zmenene soubory.

Když víte, že jste jediný, kdo soubory modifikuje, nemusíte si u souborů pamatovat vůbec nic, protože datum modifikace souboru si pamatuje souborový systém. Takže si zapamatujete jenom datum a čas, kdy jste naposledy prováděl zálohu, a pak zkopírujete jenom novější soubory. Jediná nevýhoda je, že se takhle nebudou v záloze mazat lokálně smazané soubory. Pro nalezení změněných souborů použijte find -newer případně find -mmin.

Jde nejak presvedcit Unison/Rsync aby zkopiroval pouze tyto soubory?

Jestli nic takoveho neni, tak to beru a muzu si to napsat sam.

-----
pro vsechny lokalni soubory udelat
-- vzit soubor, spocitat CRC a zapsat do databaze spolu s atributy souboru, nazvem a cestou

pro vsechny zaznamy v databazi
-- pokud je neexistuje soubor drive nebo se zmenil CRC, zkopirovat do vzdaleneho disku
-- pokud soubor drive existoval a ted uz ne, smazat z vzdaleneho disku
-----

[Unknown]

Nemám po ruke windows, ale platí to aj pre FS FAT pod daným OS?

NTFS rozlisuje po 100 ns

Proc plkate jednou to a poruhe ono? Pre par posty jste psal ze Win rozlisuji cas po sekundach... Chcete se samoucelne vozit po 15let starem FS? To je dost ubohe...

Ja? To snáď nie. Zaujímal som sa len kôli tomu, že sa ten súborový syttém stále používa na kadejakých kartách do fotoaparátov, kamier a občas aj v prehrávačoch. Takže obsolete nie je. A zaokrúhlovanie času dosť spomaľuje zálohu z fat pomocou napríklad rsync.

Takže ako to je na 15 rokov obsolete FS ktorý stále žije, platí to aj na ňom?

Pardon, chybne jsem v noci quotoval....

Obsolete to samozrejme je. Ze nekdo stavi storage na 40 let starym FS vypovida spis o nem nez o tom FS ci o jeho tvurci.

[Filip Jirsák]

Jde nejak presvedcit Unison/Rsync aby zkopiroval pouze tyto soubory?

Jestli nic takoveho neni, tak to beru a muzu si to napsat sam.

-----
pro vsechny lokalni soubory udelat
-- vzit soubor, spocitat CRC a zapsat do databaze spolu s atributy souboru, nazvem a cestou

pro vsechny zaznamy v databazi
-- pokud je neexistuje soubor drive nebo se zmenil CRC, zkopirovat do vzdaleneho disku
-- pokud soubor drive existoval a ted uz ne, smazat z vzdaleneho disku
-----

Pokud je to vzdálené úložiště WebDAV, nepoužívejte nad tím žádný Unison nebo Rsync, tím to akorát komplikujete a zpomalujete. Použil bych následující postup:

• vytvořit časovou značku pro příště
• vytvořit seznam souborů pro příště
• přes find -newer najít soubory, které se od minulé časové značky změnily
• nalezené soubory přímo přes WebDAV zkopírovat na vzdálené úložiště
• vytvořit aktuální seznam souborů a porovnat jej s tím dříve uloženým – soubory, které na novějším seznamu oproti minulému chybí přes WebDAV ze vzdáleného úložiště smazat

Jediné zbytečné kopírování, které v tomhle režimu může nastat, je v případě, kdy se soubor změní mezi vytvořením časové značky a vlastním kopírováním – v takovém případě se příště bude kopírovat zbytečně znovu. Předpokládám, že zálohu budete stejně dělat v době, kdy je pravděpodobnost změny souboru nízká, takže bych to neřešil. (Z tohohle důvodu je potřeba dělat časovou značku před začátkem kopírování – kdybyste ji dělal až na konci, nebudete mít v žádné záloze změny, ke kterým došlo během zálohování).

[JanS]

ad rychlost linky, prenos atributu atd.: Mam vyzkouseno, ze jen seznam souboru muze mit treba 50MB (a to je bez timestampu). A kdyz se zmeni jen par set kB, tak napr. po 1MBit UPC upload lince to je dost podstatny rozdil.

[Reklama]

[Filip Jirsák]

ad rychlost linky, prenos atributu atd.: Mam vyzkouseno, ze jen seznam souboru muze mit treba 50MB (a to je bez timestampu). A kdyz se zmeni jen par set kB, tak napr. po 1MBit UPC upload lince to je dost podstatny rozdil.

Přičemž v tom postupu, který jsem popsal, se žádný seznam souborů nepřenáší.

[dustin]

Unison si udržuje lokální DB s hashy souborů, ví, co se na obou stranách změnilo bez nutnosti porovnávání seznamů.

[Ondrej Nemecek]

Ještě nikdo nenavrhl použít nějaký verzovací systém Teprve pak bude tento thread kompletní :-)

[peter]

Ja sem rsync taham jako priklad situace, kdy vznika problem s timestampy. Vysvetlovat, jak funguje rsync a jak dela kontrolni soucty a prenasi jen zmenene bloky, jste zacal vy. Cili jste zase neco nepochopil, tak nedelejte chytreho.

Tazatel se ptal na WebDAV od Microsoftu. Řešit u toho,jak se chová rsync mezi lokálními disky je dost mimo, nemyslíte? A když už to chcete řešit, tak to musíte explicitně napsat, jinak budou ostatní očekávat, že řešíte pořád alespoň něco příbuzného, tedy rsync přes síť.

Ono je to trochu zložitejšie. Po roku tu niekto vytiahol mrtvolku a opýtal sa na komerčný produkt firmy microsoft. Prečo nevyužil ich podporu, alebo aspoň dokumentáciu je vedľajšie.

[crown]

Ja sem rsync taham jako priklad situace, kdy vznika problem s timestampy. Vysvetlovat, jak funguje rsync a jak dela kontrolni soucty a prenasi jen zmenene bloky, jste zacal vy. Cili jste zase neco nepochopil, tak nedelejte chytreho.

Tazatel se ptal na WebDAV od Microsoftu. Řešit u toho,jak se chová rsync mezi lokálními disky je dost mimo, nemyslíte? A když už to chcete řešit, tak to musíte explicitně napsat, jinak budou ostatní očekávat, že řešíte pořád alespoň něco příbuzného, tedy rsync přes síť.

Ono je to trochu zložitejšie. Po roku tu niekto vytiahol mrtvolku a opýtal sa na komerčný produkt firmy microsoft. Prečo nevyužil ich podporu, alebo aspoň dokumentáciu je vedľajšie.

Mrtvolku jsem vytahl, ale na komercni produkt MS jsem se neptal. To byl priklad pouziti (i kdyz zrovna ted pro me aktualni).
Zkusim si udelat vlastni a kdyz bude k necemu, tak nabidnu ostatnim.

.

[JanS]

ad rychlost linky, prenos atributu atd.: Mam vyzkouseno, ze jen seznam souboru muze mit treba 50MB (a to je bez timestampu). A kdyz se zmeni jen par set kB, tak napr. po 1MBit UPC upload lince to je dost podstatny rozdil.

Přičemž v tom postupu, který jsem popsal, se žádný seznam souborů nepřenáší.

To nerozporuju, jen jsem chtel ilustrovat problem.

[Peter]

Ja sem rsync taham jako priklad situace, kdy vznika problem s timestampy. Vysvetlovat, jak funguje rsync a jak dela kontrolni soucty a prenasi jen zmenene bloky, jste zacal vy. Cili jste zase neco nepochopil, tak nedelejte chytreho.

Tazatel se ptal na WebDAV od Microsoftu. Řešit u toho,jak se chová rsync mezi lokálními disky je dost mimo, nemyslíte? A když už to chcete řešit, tak to musíte explicitně napsat, jinak budou ostatní očekávat, že řešíte pořád alespoň něco příbuzného, tedy rsync přes síť.

Ono je to trochu zložitejšie. Po roku tu niekto vytiahol mrtvolku a opýtal sa na komerčný produkt firmy microsoft. Prečo nevyužil ich podporu, alebo aspoň dokumentáciu je vedľajšie.

Mrtvolku jsem vytahl, ale na komercni produkt MS jsem se neptal. To byl priklad pouziti (i kdyz zrovna ted pro me aktualni).
Zkusim si udelat vlastni a kdyz bude k necemu, tak nabidnu ostatnim.

.

Pokiaľ si pletieš webDav a SMB disk, tak nechcem vidieť riešenie ktoré vyprodukuješ.

To však nič nemení na tom, že implementácia WebDAV je oveľa pomalšia ako je pri použití rôznych iných sieťových súborových systémov. Preto podobné cloud storrage poskytujú vlastného klienta čo si sám rieši sledovanie zmien súborov a upload ich verzií do cloudu. Vybral si si zle, a pýtaš sa na zlom fóre. Toto naozaj nie je technická podpora MS. I keď nekomentujem na čo sa tu zvrhla celá diskusia.

[crown]

Z meho pohledu je uplne jedno, jestli je to webDav nebo samba share. Proste je to namapovane bud jako disk s pismenkem ve Windows nebo jako adresar ve filesystemu v Linuxu. Pro zalohovaci aplikaci je to transparentni - proste zalohuje z jednoho adresare (rychleho) do druheho (pomaleho).

Reseni, ktere si vyprodukuju jsem tu uz napsal:
-----
pro vsechny lokalni soubory udelat
-- vzit soubor, spocitat CRC a zapsat do databaze spolu s atributy souboru, nazvem a cestou

pro vsechny zaznamy v databazi
-- pokud je neexistuje soubor drive nebo se zmenil CRC, zkopirovat do vzdaleneho disku
-- pokud soubor drive existoval a ted uz ne, smazat z vzdaleneho disku
-----

Sitovou komunikaci resit nepotrebuju, pro aplikaci to jsou jen dva adresare. Zaroven mi to bude fungovat nezavisle na tom, jake vzdalene uloziste si namapuju do filesystemu.

To prece neni tak slozite pochopit, ne?

[Filip Jirsák]

Z meho pohledu je uplne jedno, jestli je to webDav nebo samba share. Proste je to namapovane bud jako disk s pismenkem ve Windows nebo jako adresar ve filesystemu v Linuxu. Pro zalohovaci aplikaci je to transparentni - proste zalohuje z jednoho adresare (rychleho) do druheho (pomaleho).

Předpokládám, že SMB umožňuje zapisovat i do části souboru – že můžete na server poslat příkaz „přepiš bajty 10–20 tímhle: …“. To u WebDAVu nejde, tam musíte vždy zapsat celý nový soubor. To je z hlediska zálohování dost podstatný rozdíl, a dost podstatně to ovlivňuje i tu síťovou komunikaci, která se bude dít pod tím namapovaným diskem.

Sitovou komunikaci resit nepotrebuju, pro aplikaci to jsou jen dva adresare. Zaroven mi to bude fungovat nezavisle na tom, jake vzdalene uloziste si namapuju do filesystemu.

S tímhle přístupem ale riskujete, že budete mít síťové přenosy násobně větší, než kdybyste se síťovou komunikací zabýval. Zvlášť pokud mapujete WebDAV jako klasický disk, hrozí, že se ty soubory budou opakovaně přenášet sem a tam, přestože by stačilo nahrát na server novou verzi nebo dokonce data souboru vůbec nepřenášet.

Použít takové řešení samozřejmě můžete, ale není to řešení vhodné pro pomalou linku, naopak je to řešení pro případ „nebudu nic vymýšlet, na optice je spousta volného pásma“.

[dustin]

Reseni, ktere si vyprodukuju jsem tu uz napsal:

Tak to budeš psát přesně ten unison, akorát ten navíc finálně synchronizuje algoritmy rsyncu.