Offsite backup
Moczik Gabor
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 - li...@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux
Andras HORVATH
Moczik Gabor <pm_le...@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
PÁSZTOR György
Hi!
"Moczik Gabor" <pm_le...@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!
Moczik Gabor
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.
Kovács Attila
Moczik Gabor írta:
> Már nézegettem régebben, a hardlinkes dolog világos, ez az rsync
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-
Kovács Attila
Moczik Gabor írta:
>
> hogy egyéb megoldás lenne, pedig nem egészen triviális feladat.
>
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-
Moczik Gabor
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).
Kovács Attila
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.
>
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.
>
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
>
Legfeljebb többet dolgozik az rsync. Nem olyan rettenet bonyolult ez.
--
k-atti-
Moczik Gabor
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...
Gabor Gombas
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
---------------------------------------------------------
Kovács Attila
Moczik Gabor írta:
> Nem rettenet bonyolult, de nem is egy félórás munka rendesen megírni egy
> ls -i meg rsync paranccsal...
>
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-
Moczik Gabor
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.
Kovács Attila
Moczik Gabor írta:
> Nem mondom hogy teljesen értem, bár sejtem mire gondolsz.
> Az fs-t így adatbázisnak használni elég gány szerintem.
>
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-
Kiss Gabor
In article <4B119EC0...@progzmaster.hu>,
Moczik Gabor <pm_le...@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