Re: Offsite backup
On Sat, Nov 28, 2009 at 10:07:32PM +0100, Moczik Gabor wrote: Már nézegettem régebben, a hardlinkes dolog világos, ez az rsync szolgáltatása, de a rename/move problémát hogyan oldja meg? Mert amennyire én látom az rsync ezt nem tudja, és nem említi a doksi, hogy egyéb megoldás lenne, pedig nem egészen triviális feladat. Altalanos megoldasrol nem nagyon tudok. Szervezd meg ugy az adatokat, hogy ne legyen szukseg ilyen nagy atnevezesekre, vagy ha megis, akkor kezzel csinald meg azt a tuloldalon az rsync elott. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: Offsite backup
Moczik Gabor írta: Nem rettenet bonyolult, de nem is egy félórás munka rendesen megírni egy ls -i meg rsync paranccsal... Kompromisszummentesen nem tudod megoldani, ez tény. Nézni kell egy olyan fájlrendszert, ami támogatja ezt. Nincs kizárva hogy valamelyikben már van erre támogatás, hiszen a probléma általános jellegű. Filóztam ezen tegnap este, arra jutottam, hogy az ember csinál egy alkönyvtárat, ahova készít inode alapján hardlinkkel fájlokat (nyilván alkönyvtár szerkezetben, hogy ne legyen túl sok file bejegyzés egy helyen), a nevük is egyszerűen valami prefix + az eredeti inode-ok (így az egyediséget is elég egyszerű megoldani, nem kell hozzá külső adatbázis). Ezt gyönyörűen lehet kezelni rsynccel, az eredeti könyvtárstruktúra létrehozásához kell a plusz script. Node itt jönnek a kompromisszumok. Nem szabad ehhez a könyvtárhoz másnak hozzápitiszkálni, valamint szörnyen pacsálja az inode-okat, ha valaki helyet akar csinálni, meg fog lepődni, mert nem tűnik el fizikailag semmi sem ameddig ki nem nyesed innen is. Az eredeti problémát viszont elég egyszerűen és frappánsan meg tudod imígyen oldani. -- k-atti- _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: Offsite backup
Kovács Attila wrote: Kompromisszummentesen nem tudod megoldani, ez tény. Nézni kell egy olyan fájlrendszert, ami támogatja ezt. Nincs kizárva hogy valamelyikben már van erre támogatás, hiszen a probléma általános jellegű. Filóztam ezen tegnap este, arra jutottam, hogy az ember csinál egy alkönyvtárat, ahova készít inode alapján hardlinkkel fájlokat (nyilván alkönyvtár [...] Nem mondom hogy teljesen értem, bár sejtem mire gondolsz. Az fs-t így adatbázisnak használni elég gány szerintem. Ha lesz egy kis időm, inkább megírom amit elkezdtem, egy része már készen van, csak nem volt türelmem befejezni. SQL adatbázisba dolgozik, már csak a többi része hiányzik. :-) Közben néztem a Bacula-t is, sokmindent tud, de úgytűnik hogy ezt nem. Pedig furcsálnám ha még senki nem oldotta volna meg. :-) Mondjuk ez az egész csak DSL internetkapcsolaton probléma. _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: Offsite backup
Moczik Gabor írta: Nem mondom hogy teljesen értem, bár sejtem mire gondolsz. Csak végiggondoltam a lehetőségeket. Az fs-t így adatbázisnak használni elég gány szerintem. Nincs benne felesleges réteg. Egyébként ha a fájlrendszer nem támogatja azt amit akarsz, nem nagyon tudsz mást tenni. Valahol kompromisszumot kell kötnöd. Szerintem egyébként van olyan fájlrendszer ami jó lenne neked, és vszinű arra célszerű keresgélned. Sőt tuti :. http://oss.sgi.com/projects/xfs/ XFS implements fully journaled extended attributes. An extended attribute is a name/value pair associated with a file. Attributes can be attached to all types of inodes: regular files, directories, symbolic links, device nodes, and so forth. Attribute values can contain up to 64KB of arbitrary binary data. XFS implements three -- k-atti- _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: Offsite backup
In article 4b119ec0.4030...@progzmaster.hu, Moczik Gabor pm_levli...@progzmaster.hu writes: Van egy forr=E1s k=F6nyvt=E1r meg egy c=E9l _szerver_, mivel offsite backup= r=F3l = van sz=F3. Ha a forr=E1s k=F6nyvt=E1rban =E1tnevezem az A k=F6nyvt=E1rat B-= re, akkor = az rsync a k=F6vetkez=F5 fut=E1skor ezt nem tudja, =F5 =FAgy l=E1tja hogy a= z A = k=F6nyvt=E1r t=F6r=F6lve lett, valamint keletkezett egy B =E9s benne egymil= li=F3 =FAj = f=E1jl. Ezt mindet =E1t is viszi a t=FAloldalra. Valamikor 2002 körül csináltunk egy ilyen rendszert. Szolgáltatásnak szántuk: Az ügyfél óránként/naponta/hetente beküldi hozzánk a mentendõ file-okat mi pedig szerzõdésben meghatározott számú, földrajzilag elosztott gépre mentjük azokat, a saját jól felfogott érdekünkben igen helytakarékosan. Tehát az azonos file-okat egy gépen csak egyszer tesszük el. Függetlenül attól, hogy hány és milyen link mutatott rájuk. Digitális aláírással visszaigazoljuk az átvett file-okat és jótállunk érte, hogy szerzõdésben meghatározott ideig tároljuk és kérésre visszaküldjük az ügyfélnek, ha kéri. Nem lett belõle bombaüzlet, de egy állandó ügyfelü(n)k azóta is van. (Én már nem dolgozom ott.) Szóval a dolog kivitelezhetõ, ezzel csak azt akartam mondani. g _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: Offsite backup
Andras HORVATH wrote: Az alapveto problema, ami miatt sok cucc kiesik, hogy esszeruen le kell kekezelni egy fajl vagy konyvtar atnevezeset, athelyezeset. Mivel ADSL-rol van szo, az upstream savszelesseg igencsak szukos, nem megengedheto hogy egy 'rename' parancs tovabbitasa helyett egy egesz konyvtarat ujra felmasoljon. Dirvish. Diszkre ment es hardlinkeket csinal az elozo mentesebe a nem valtozott file-okrol, tehat hely- es savszelesseg-takarekos. Tud masik gepre is menteni. Már nézegettem régebben, a hardlinkes dolog világos, ez az rsync szolgáltatása, de a rename/move problémát hogyan oldja meg? Mert amennyire én látom az rsync ezt nem tudja, és nem említi a doksi, hogy egyéb megoldás lenne, pedig nem egészen triviális feladat. _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: Offsite backup
Moczik Gabor írta: Már nézegettem régebben, a hardlinkes dolog világos, ez az rsync Szerintem a hardlink esetében indifferens hogy átnevezted a fájlt. Inkább annak a lekezelése az érdekes, hogy nem tudod kitörölni véglegesen a belinkelés miatt a mentett fájljaidat. -- k-atti- _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: Offsite backup
Moczik Gabor írta: hogy egyéb megoldás lenne, pedig nem egészen triviális feladat. Azt hiszem nem voltam pontos. A feladat triviális egyébként. Ezért vannak az inode-ok. Eléggé pontosan azonosítják a fájlt. Persze ha másik fájlrendszerre mozgatod a fájlodat, akkor bukik a dolog -- k-atti- _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: Offsite backup
Kovács Attila wrote: Moczik Gabor írta: Már nézegettem régebben, a hardlinkes dolog világos, ez az rsync Szerintem a hardlink esetében indifferens hogy átnevezted a fájlt. Inkább annak a lekezelése az érdekes, hogy nem tudod kitörölni véglegesen a belinkelés miatt a mentett fájljaidat. Nnna. Van egy forrás könyvtár meg egy cél _szerver_, mivel offsite backupról van szó. Ha a forrás könyvtárban átnevezem az A könyvtárat B-re, akkor az rsync a következő futáskor ezt nem tudja, ő úgy látja hogy az A könyvtár törölve lett, valamint keletkezett egy B és benne egymillió új fájl. Ezt mindet át is viszi a túloldalra. Ezt csak külső eszközzel lehet lekezelni, aminek van egy nyilvántartása az előző állapotról, és ehhez tudja hasonlítani a mostanit, ami alapján kiderül hogy a könyvtárat át kell nevezni. Mivel az rsync ezt nem tudja, kell egy másik külső megoldás ami a távoli szerveren végrehajt 1db átnevezés parancsot. És akkor még mindig a local adatbázis alapján feltételeztük, hogy a túloldali szerveren ennek-meg-ennek a fájlnak itt-meg-itt kell lennie (mert a legutóbbi mentéskor odakerült). Ha a túloldalon valami elromlik, onnantól bukik az egész. Egy ilyen rendszernél elvárható hogy ettől még a jelenlegi backup sikerüljön és használható legyen. Ha nem is automatikusan, de valahogy javítható kell legyen. Azaz kell még egy külső megoldás, ami ellenőrizni tudja hogy a távoli szerveren lévő állapot konzisztens-e. Ehhez tudni kell a helyi-távoli indoe számok összetartozását is. Nagyon nem triviális. Igen sok minden kell az rsync köré hogy ez működhessen (a távoli hostra is). _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: Offsite backup
Moczik Gabor írta: Ezt csak külső eszközzel lehet lekezelni, aminek van egy nyilvántartása az előző állapotról, és ehhez tudja hasonlítani a mostanit, ami alapján kiderül hogy a könyvtárat át kell nevezni. Kell egy lista nyilván. Illetve kettő, mert a túloldali inode-okról is, a tetejében rekurzívan, mivel az esetleges átnevezéseket úgy kell végrehajtani. Erre remek lehet az ls -i -R parancs kimenete. Az rsync előtt kell ennek futnia persze. Mivel az rsync ezt nem tudja, kell egy másik külső megoldás ami a távoli szerveren végrehajt 1db átnevezés parancsot. Ez tény. A tetejében gázos lehet, ha az adott inode újrahasznosul. (Ez tényleg lehet komoly gáz) És akkor még mindig a local adatbázis alapján feltételeztük, hogy a túloldali szerveren ennek-meg-ennek a fájlnak itt-meg-itt kell lennie Ha nincs ott, mi történhet? Legfeljebb többet dolgozik az rsync. Nem olyan rettenet bonyolult ez. -- k-atti- _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: Offsite backup
Kovács Attila wrote: Kell egy lista nyilván. Illetve kettő, mert a túloldali inode-okról is, a tetejében rekurzívan, mivel az esetleges átnevezéseket úgy kell végrehajtani. Erre remek lehet az ls -i -R parancs kimenete. Az rsync előtt kell ennek futnia persze. Az inode listát fel is kell dolgozni úgy, hogy a végén legkevesebb műveletet hajtsuk végre. Mivel az rsync ezt nem tudja, kell egy másik külső megoldás ami a távoli szerveren végrehajt 1db átnevezés parancsot. Ez tény. A tetejében gázos lehet, ha az adott inode újrahasznosul. (Ez tényleg lehet komoly gáz) Átnevezés esetén nem, inkább törlés esetén. Amit én elkezdtem írni, az nézi a fájlméretet és az mtime-ot is. És akkor még mindig a local adatbázis alapján feltételeztük, hogy a túloldali szerveren ennek-meg-ennek a fájlnak itt-meg-itt kell lennie Ha nincs ott, mi történhet? Legfeljebb többet dolgozik az rsync. Nem olyan rettenet bonyolult ez. Nem éppen. Ha ott kéne legyen, de nincs ott, akkor az rsync létre fog hozni egy fájlt, aminek az inode száma nem lesz azonos azzal ami az adatbázis(ok)ban van, és erről nem árt értesülni valahogy. Lényeg hogy kétirányú kommunikáció kell a két gép között !!! az rsync-en kívül !!!. Nem rettenet bonyolult, de nem is egy félórás munka rendesen megírni egy ls -i meg rsync paranccsal... _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: Offsite backup
Moczik Gabor pm_levli...@progzmaster.hu wrote: Az alapveto problema, ami miatt sok cucc kiesik, hogy esszeruen le kell kekezelni egy fajl vagy konyvtar atnevezeset, athelyezeset. Mivel ADSL-rol van szo, az upstream savszelesseg igencsak szukos, nem megengedheto hogy egy 'rename' parancs tovabbitasa helyett egy egesz konyvtarat ujra felmasoljon. Dirvish. Diszkre ment es hardlinkeket csinal az elozo mentesebe a nem valtozott file-okrol, tehat hely- es savszelesseg-takarekos. Tud masik gepre is menteni. Nekem otthon dirvish ment egy kulso diszkre, majd ezt tovabb mentem az ADSL-en felfele egy kicsi scripttel. Neked ez nem kell, hacsak nem akarsz tobb peldanyt a mentesedbol. HTH raas -- Those who say it cannot be done should not interrupt the person doing it. -- Chinese proverb _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: Offsite backup
Hi! Moczik Gabor pm_levli...@progzmaster.hu írta 2009-11-19 19:57-kor: Ha mar backup, akkor en olyan rendszert keresek, amivel neten keresztul lehet offsite backupot kesziteni egy masik szerverre. Elkezdtem mar irni egy rsync-en es SQL szerveres metadata tarolason alapulo script gyujtemenyt, de ido es kedv hianyaban nem fejeztem be... baculával milyen problémád volt? Üdv:Gyur! _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Offsite backup
Hali! Ha mar backup, akkor en olyan rendszert keresek, amivel neten keresztul lehet offsite backupot kesziteni egy masik szerverre. Elkezdtem mar irni egy rsync-en es SQL szerveres metadata tarolason alapulo script gyujtemenyt, de ido es kedv hianyaban nem fejeztem be... Az alapveto problema, ami miatt sok cucc kiesik, hogy esszeruen le kell kekezelni egy fajl vagy konyvtar atnevezeset, athelyezeset. Mivel ADSL-rol van szo, az upstream savszelesseg igencsak szukos, nem megengedheto hogy egy 'rename' parancs tovabbitasa helyett egy egesz konyvtarat ujra felmasoljon. _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
