zalohovani zmenenych + novych souboru
Dan Lukes
dan at obluda.cz
Mon Mar 18 02:40:09 CET 2019
On 16.3.2019 23:16, Miroslav Lachman wrote:
> potreboval zmenit zpusob zalohovani jednoho stroje...
> Duvod: je tam asi 4TB dat v souborech o velikostech od desitek kB do
> jednotek MB v pomerne kosate strukture adresaru.
> V soucasnosti se zalohuje rsyncem (uz asi 10 let)
Jo, rsync je celkem dobrej - zvlada ACL, rozsirene atributy, sparse
soubory, hardlinky ...
> problem, jak je souboru vic a vic, tak strasne dlouho trva, nez se
> zjisti, kde vsude se zmenily soubory, nebo nekdo nahral nejaky novy,
> pripadne stary soubor nekdo smazal. Predpokladam, ze rsync prave
> projizdi celou adresarovou strukturu a hleda zmeny mtime / ctime na
> zdrojove a cilove strane. Denne se takhle synchronizuje sotva 1GB dat,
> ale trva to asi 6-8 hodin, podle vytizeni disku... a to je ten problem,
> ze to ovlivnuje produkcni provoz.
Pokud to ovlivnuje produkcni provoz, tak to nejspis je diskovou
aktivitou. Je mi ale trochu divne, ze to z vetsi casti nepokryji diskove
cache. Mozna by stalo zato zjistit jak presne to rsync dela, a jestli to
nahodou nelze nejak zefektivnit (i za cenu zvysenych naroku na pamet).
> Existuje nejake reseni, ktere by dokazalo bezet na pozadi, z kernelu
> dostavat informaci o tom, ktere soubory se zmenily a pak je jednou za
> den je synchronizovat na zalohovaci stroj?
Existuje kqueue, ale pokud vim, tak kazdy monitorovany soubor (tady by
asi stacil kazdy adresar) musis mit otevreny. Coz pri velkem poctu
sledovanych veci muze zadat enormni pocet otevrenych deskriptoru.
> Takze jak se da tohle rozumne resit?
Blbe. Dokonce i teoreticky (jako, ze nejen, ze neznam hotovy reseni, ale
ani jak ho udelat).
Nebyl by problem "lacino" monitorovat zmenu kazdeho inode na fs - tohle
je jednoduchy. Ale drahy je zjistit k jakym jmenum ten inode patri -
kdyz chces monitorovat jen nejaky podstrom FS. V podstate bys musel
exhaustivne prohledat adresare (I/O narocna operace), nebo mit tyhle
data nacacheovany a monitorovat i zmeny adresaru (MEMORY narocna operace).
Dan
More information about the Users-l
mailing list