backup - mi a legoptimalisabb?

Fórumok

backup - mi a legoptimalisabb?

Hozzászólások

En mar lattam olyat, hogy a Tivoli Storage Manager mentoszoftver adatbazisa szallt el.
Es nem tudtuk teljesen visszaallitani, mert nem volt teljes hasznalhato mentes rola.
Minden szalag, ami nem szerepelt a helyreallitott Tivoli adatbazisban hasznalhatatlan volt :)
Ugyanis a tivoli storage manager (legalabbis az a verzio amit hasznaltunk) nem volt kepes az adatbazisat felepiteni a szalagokra kiirt adatok alapjan.

[quote:ab08541cb2="pe2hu"]En mar lattam olyat, hogy a Tivoli Storage Manager mentoszoftver adatbazisa szallt el.
Es nem tudtuk teljesen visszaallitani, mert nem volt teljes hasznalhato mentes rola.
Minden szalag, ami nem szerepelt a helyreallitott Tivoli adatbazisban hasznalhatatlan volt :)
Ugyanis a tivoli storage manager (legalabbis az a verzio amit hasznaltunk) nem volt kepes az adatbazisat felepiteni a szalagokra kiirt adatok alapjan.

Hmm... a TSM-et naponta kétszer mentjük 2 helyre. Lokális szalagra, és egy másik TSM szerverre. Pontosan azért mert, ha az adatbázisa elszáll, akkor az utolsó adatbázis mentés utáni kliens mentések ugrottak. :)Csináltunk már olyat, hogy egy szerverre tesztképpen visszaállítottuk az "éles" Tivoli adatbázist, de nem volt vele semmi gond. Persze a TSM sem bugmentes, és vannak vele néha rendes szívások, de ennek ellenére az egyik legprofibb.

Még eszembe jutott egy apróság, ami már lehet, hogy túlságosan szőrőző.
Mentési rendszer kialakításakor lehet az is szempont, hogy a rendszerrel mentett adatokat mekkora erőfeszítés átmigrálni egy másik mentési rendszer alá. Futottam már rá olyan esetre, hogy egy régi elavult, nem supportált rendszert azért kellett megtartanunk (a hozzá tartozó rozsdásodó vasakkal), mert a vele mentett adatokat nem lehetett átmigrálni az új mentési rendszerbe, de a vele mentett adatokat még évekig tárolni kellett. Szerintem dragon erről is rendelkezik egy-két tapasztalattal :)

Nem teljesen ide vágó kérdés, de van -e linux alá olyan dolog, mint unixokon (pl solaris) ufsdump/ufsrestore?
Amivel pl. a teljes file rendszert (inode táblával, fileokkal, meg mindennel) ki lehet pakolni pl. szalagra, vagy file-ba.
Ez speciel nagyon jól használható Solarison mentésre.

[quote:6093313247="zwei"]Nem teljesen ide vágó kérdés, de van -e linux alá olyan dolog, mint unixokon (pl solaris) ufsdump/ufsrestore?
Amivel pl. a teljes file rendszert (inode táblával, fileokkal, meg mindennel) ki lehet pakolni pl. szalagra, vagy file-ba.
Ez speciel nagyon jól használható Solarison mentésre.

A dd parancssal lehet ilyet csinálni, bár nekem az a bajom vele, hogy nem alkalmas egy olyan rendszer mentésére, ahol a rendszer nagyobb, mint a rendelkezésre álló terület, bár hálózatban ez még nem nagy probléma...
Nem tud valaki egy olyan Norton Ghost féle megoldást? Vagy, hogy hogy tudnám az egész rendszert több részre összetömöríteni, esetleg milyen ISO készítő progi van, stb?... Olyan megoldást keresek, ahol a boot lemezt betéve image fájlokból vissza tudom tölteni a rendszert... (alá Norton Ghost)

[quote:89129e1583="zwei"]

Még eszembe jutott egy apróság, ami már lehet, hogy túlságosan szőrőző.
Mentési rendszer kialakításakor lehet az is szempont, hogy a rendszerrel mentett adatokat mekkora erőfeszítés átmigrálni egy másik mentési rendszer alá. Futottam már rá olyan esetre, hogy egy régi elavult, nem supportált rendszert azért kellett megtartanunk (a hozzá tartozó rozsdásodó vasakkal), mert a vele mentett adatokat nem lehetett átmigrálni az új mentési rendszerbe, de a vele mentett adatokat még évekig tárolni kellett. Szerintem dragon erről is rendelkezik egy-két tapasztalattal :)

:) valóban volt nem egy ilyen ügyfél. A tapasztalat az, hogy közel lehetelen két különböző mentési rendszer között a mentett adatokat migrálni. Általános okai: a szoftverek eltérő működési elvei, a támogatott mentőeszközök különbözősége és az eltérő szalagformátumok (nem dlt, meg dds, hanem amire a rendszer formázza, hogy írni tudja), stb. Ezért is van, ahogy zwei mondta, több helyen bizony a régi is megy még. Legtöbbször még egy mentési rendszeren belül is embert próbáló egy ilyen feladat.

Ha már eddig elhangzottak itt "nevek" akkor én is hadd tegyek hozzá egyet kettőt. A Tivolival és a Veritassal egy ligában játszik a Legato. Személy szerint ezt preferálom leginkább, mert: unixos világból származik és ez meglátszik az felépítésén és a kezelésén. Átgondolt és világos. Minden mentésnél menti a saját adatbázisait is ami egy esetleges összeomlás esetén nagyon jól jön a helyreállításnál. És minden kölünösebb gond és megkötés nélkül tudom mozgatni a különböző Legato szerverek között azok adatait. Van még sok szimpatikus tulajdonsága, de ez nem a reklám helye.

Aztán még elég jó bár a fentieknél egyel alcsonyabb kategóriában fut a CommVault és a BakBone. Persze sok van még, sokféle tudással és képességel, de legalább az igények alapján meglehet találni a célnak leginkább megfelelőt :)

üdv,
dragon

[quote:0943d0088c="Oregon"]Hi All!

- Sokak rsync-re eskusznek, viszont ezzel az a gaz, hogy a usererror-t vagyis nem kivant torlesek ellen nem ved, hanem szepen leszinkroniazalja azt is.
Mivel tavoli menteseket keszitek, igy a felesleges adatmozgas miatt nekem meg igy is ez a legjobb megoldas jelenleg.

Inkrementális rsync mentés: dirvish

[quote:fdcf1b6413="norbert79"]
Nem tud valaki egy olyan Norton Ghost féle megoldást? Vagy, hogy hogy tudnám az egész rendszert több részre összetömöríteni, esetleg milyen ISO készítő progi van, stb?... Olyan megoldást keresek, ahol a boot lemezt betéve image fájlokból vissza tudom tölteni a rendszert... (alá Norton Ghost)

hát... mondjuk attól függ milyen platformra keresed. Pl. a Legatonak van ilyen bővítménye Win és Solaris osekre.

de nézd meg az http://adatkezeles.lap.hu disaster recovery megoldások fülét. lehet, hogy a termék linkek nem mennek, de a foldalról megtalálod mindet, mert még mind létezik. :)

A dd parancssal lehet ilyet csinálni, bár nekem az a bajom vele, hogy nem alkalmas egy olyan rendszer mentésére, ahol a rendszer nagyobb, mint a rendelkezésre álló terület, bár hálózatban ez még nem nagy probléma...
Nem tud valaki egy olyan Norton Ghost féle megoldást? Vagy, hogy hogy tudnám az egész rendszert több részre összetömöríteni, esetleg milyen ISO készítő progi van, stb?... Olyan megoldást keresek, ahol a boot lemezt betéve image fájlokból vissza tudom tölteni a rendszert... (alá Norton Ghost)

A dd-erre nem túl jó. (Pl a visszatöltést csak ugyanakkora méretű partícióra tudod megoldani)
közben megtaláltam: http://dump.sourceforge.net/ És debianra is letölthető apt-al.

[quote:3d71f75168="norbert79"]
Nem tud valaki egy olyan Norton Ghost féle megoldást? Vagy, hogy hogy tudnám az egész rendszert több részre összetömöríteni, esetleg milyen ISO készítő progi van, stb?... Olyan megoldást keresek, ahol a boot lemezt betéve image fájlokból vissza tudom tölteni a rendszert... (alá Norton Ghost)

A partimage valami ilyesmit tud, bár még nem használtam.

http://www.partimage.org/

Rich

Rich, dragon, köszi a segítséget, mindkettőt megnézem...
(Azt hiszem végignyálazom az O'Reilly féle Backup and Recovery könyvet is... :) )

[quote:1f0355ba7c="tef"]http://www.fluffy.co.uk/boxbackup

Hmm ez igen! Le is csereltem gyorsan a hdup-ot. :-)) Thx a linket es az ismertetot! Ha volna kedved szerintem irhatnal egy komolyabb lelegzetvetelu hirt a hup-ba errol a programrol!

Egy jó alternatíva még: hdup http://miek.nl/projects/hdup16/hdup16.html

# incremental backups: monthly, weekly and daily dumps,
# encryption of the archive (via mcrypt or GPG),
# compression of the archive (bzip/gzip/lzop/none),
# possibility to transfer the archive to a remote host,
# possibility to restore the archive from a remote host,
# ability to split up archives,
# no obscure archive format (it is a normal compressed tar file), and
# simple to use.

[quote:b4bc35bd79="dragon"]Hello,

Évek óta adattárolási és backup rendszerek tervezésével és implementálásával (és persze értékésítésével :) ) keresem a kenyerem. zwei mondandója elég jól összefoglalta a lényeget. bár nem feltétlenül a megfelelő összefüggésekkel.

Az első lépésként mindenképpen tisztába kell jönnöd az adataid valódi értékével (nem azzal, hogy mit gondolsz róluk, hogy hanem hogy a cégednek akár anyagilag akár erkölcsileg mit jelent ha nincsenek).
Ez meghatározza a költség kereteid, ebből pedig kialakul a lehetséges megoldások köre. Eztán ki kell alakítani a mentési stratégiát (mit, mikor, hova, hányszor, meddig stb.) majd neki lehet állni a gyakorlati megvalósításnak az első tesztekkel és egyebekkel.

aki meg nem olvasta, mindenkeppen megeri elolvasni ezt:
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/backup-basics.html

kulonos tekintettel a ``do nothing'' (16.11.6 szekcio) mentesi strategiara :), valamint az azt koveto ``which is the best?'' pontra.

ez utóbbi kezd nagyon megtecceni :wink:

[quote:5e90f6b418="vmiklos"]ez utóbbi kezd nagyon megtecceni :wink:

Meg nem probaltam, de termeszetebol adodoan ez nem tud kulonbsegeket menteni, tehat ha van egy 2 gigas fileod es csak egy byte valtozik benne (vagy a vegere kerul) az egesz file mentesre kerul a napi inkrementalt backup alkalmaval, mivel gondolom a tar -N opciojat hasznalja mentesre. (Meg1x mondom, ez csak IMHO, de eleg nagy a valoszinusege.)

Jah ami egyebkent szamomra vonzova teszi, az a mentes elkodolasa mcrypt vagy gpg altal, mivel szamunkra ez fontos szempont. Ket co-loc-ban levo gep keresztbe ment, egy rsync-es mentes kivalo _lenne_, amde ha megtorik egyik gepet, ott van rajta plain a teljes remote gep mentese, siman hozzaferhetoen. Ezert most sajat scripteket hasznalok tar.gz+gpg; de azert jo lenne vmi univerzalisabbat talalni.

nembaj az, ha menti az egészet
a csak a diffet mentené, akkor bármelyik diff sérül, megszívtad. így van 1 kis "hibatűrése" a backupnak :wink:

Vegigolvastam a topicot es megneztem nemelyik backup cuccot. A kerdesem nekem az (lehet figyelmetlen voltam), hogy hogyan lehet olyan backupot csinalni, ami csak bizonyos datum utani filekat archival es nem egy alapra huzza ra a kulonbseget. Tehat nekem a legutolso backup ota bekerult filek kellenenek csak. Erre van e valamilyen progi/modszer?

Hi All!

Egyszeru kerdesem a subject, viszont mi mogotte van:

- Alap kiindulo pont az, hogy helyben vagy tavol. Ebben nalam egyertelmu: tavol.
Sajna a cegem egyszer tuzkarban elveszett es a backupok is szepen bent egtek az iroasztalomon. Sza'l ez ma mar nem kerdes.

- Sokak rsync-re eskusznek, viszont ezzel az a gaz, hogy a usererror-t vagyis nem kivant torlesek ellen nem ved, hanem szepen leszinkroniazalja azt is.
Mivel tavoli menteseket keszitek, igy a felesleges adatmozgas miatt nekem meg igy is ez a legjobb megoldas jelenleg.

- CD iras, na ez sem a legkiralyabb megoldas mivel a CD (vagy DVD) kis merete miatt tovabba az adatok raktarozasa es az adathordozok megsemmisitese is tovabbi plusz melokat ad es koltseget general.
Volt ido amikor egy ujrairhato CD figyelt a szerverben es arra nyomtam a stuffot, de errol mar leszoktam. :)

- szalagos egyseg. nekem nem haverom, mert cserelgetni kell, es en spec amugy sem bizom (lehet lamasagom miatt) egy vasoxid szalagban.
nameg ott a masik gaz, hogy:

- adatmentes folyamta: ha "n" idonkent csinalom akkor az felulirja az elozo mentest vagy sem?
Ha nem irja felul akkor szivas tavolra menteni, ha felulirja akkor meg nem ved a usererror ellen.
Aki az egeszbol egy uj tar.gz-t csinal az mennyi elozo mentest tart meg?

Szorri, hogy ilyen default temat feszengetek, de tenyleg kivancsi vagyok a hup oregjei hogyan vigyaznak adataikra tobb gepes ceges szinten.
bye Oregon

És tud valaki olyan eszközt amivel az ACL-ket lehet hatékonyan menteni/megőrizni?

Az star-t ismerem de sima fájlokként szeretném menteni nem tar-ral.
(a hard linkes trükköt egyébként a legtöbb felsorolt eszköz beveti ;-)

Van egy subversion szerver, amit rendszeresen backupolnom kellene. Adott egy Tivolis backup lehetőség, amit igénybe is veszek majd, viszont ez csak heti, a legjobb esetben is két vagy háromnapi backupot jelent.

Én viszont szeretném a két backup közötti commitokat is valahogy biztonságban tudni. Triviális megoldás, h a commit általi változásokat kidumpolom egy file-ba, aztán ezt átküldöm egy másik gépre. Ennek az első fele megvan, a második felével, vagyis az adatok másik gépre eljuttatásával problémáim vannak.

Legkézenfekvőbb megoldás [legalábbis számomra]: fogom az scp-t, aztán áttolom vele a másik gépre. Igenám, de mi van akkor, ha a másik éppen akkor nem elérhető, vagy az áttöltés során vmiért megszakad a kapcsolat, stbstb... Szóval valami logikát kéne köré scriptelni, ami biztosítaná, h a file mindenképpen átjusson a másik gépre. Erre viszont, főleg a kitesztelésére, most nincs erőforrás.

Másik kézenfekvő megoldás, h uuencode-olom, aztán levélben elküldöm, így a MTA-ek szépen megoldják, h a file mindenképpen átjusson a másik gépre [nyilván esetleg némi késéssel]. Viszont ha vki beimportol mondjuk 80 megát, akkor azt a mailszerverek [de főleg azok adminjai <:] nem fogadják majd kitörő örömmel...

Valakinek valami ötlete, ami hasonló szituációban már bevált [és lehetőleg out of the box működik (;]? Köszönöm.

[quote:c833d7556e="norbert79"][quote:c833d7556e="zwei"]Nem teljesen ide vágó kérdés, de van -e linux alá olyan dolog, mint unixokon (pl solaris) ufsdump/ufsrestore?
Amivel pl. a teljes file rendszert (inode táblával, fileokkal, meg mindennel) ki lehet pakolni pl. szalagra, vagy file-ba.
Ez speciel nagyon jól használható Solarison mentésre.

A dd parancssal lehet ilyet csinálni, ...

man tar....

[quote:b25b973853="Oregon"]
- Sokak rsync-re eskusznek, viszont ezzel az a gaz, hogy a usererror-t vagyis nem kivant torlesek ellen nem ved, hanem szepen leszinkroniazalja azt is.
Mivel tavoli menteseket keszitek, igy a felesleges adatmozgas miatt nekem meg igy is ez a legjobb megoldas jelenleg.

Inkrementalis backupot kell csinalni. Ajanlom az rsnapshot ( http://www.rsnapshot.org/ ) programot, az tokeletes backupra, szerintem. rsyncet hasznal (ergo relative gyors), tud remote backupolni, es inkrementalis (avagy ha a juzer torolt egy filet, regebbi backupban meg megvan).

Egy masik erdekes program a pdumpfs, amivel http://snapshot.debian.net/ keszult. Egyetlen hatranya, hogy nem remote (de a keszitett cuccokat rsyncel at lehet kuldeni, vagy helybol NFS-re csinalod, vagy hasonlo O:).

Az en megoldasom egy harmadik eset lehet, de ez tobb-useres rendszeren nem biztos hogy megoldas: en minden atadomat valamilyen VCS-ben ($HOME - CVS, minden mas Arch) tarolom, es vagy 4 helyre mirrorozva van. Egy ember, a sajat adatait igy tok jol tudja vedeni. Ott, ahol random userek vannak, akik hallani sem akarnak CVS-rol, Archrol meg plane, ez kevesse oldhato meg ^_^" (Pedig rem elegans es megbizhato, csakhat elegge geek-specifikus megoldas:)

[quote:fdfc2fb136="sz"]Legkézenfekvőbb megoldás [legalábbis számomra]: fogom az scp-t, aztán áttolom vele a másik gépre. Igenám, de mi van akkor, ha a másik éppen akkor nem elérhető, vagy az áttöltés során vmiért megszakad a kapcsolat, stbstb... Szóval valami logikát kéne köré scriptelni, ami biztosítaná, h a file mindenképpen átjusson a másik gépre. Erre viszont, főleg a kitesztelésére, most nincs erőforrás.

miért nem rsync? tudja csak a változásokat menteni, esetleg utána md5 hogy minden rendben van-e: megszakadt kapcsolat - félig átvitt fájlok stb

vagy maradsz scp-nél de ugyanúgy csinálsz md5-öt minden átvitt fájlról és azt is átküldöd a másik gépen meg bizonyos időszakonként ellenőrzöd hogy a másolat megegyezik-e...ha nem úgyis látod:pl dob egy mail-t hogy nem egyezik, vagy csak része jött át, akkor meg átnyomod újra...

En hazi termesztesu tavoli backupot hasznalok, a kov. semaban:
- /, /usr -> full readonly -> csak akkor valtozik, ha _en_ valtoztatom, akkor pedig full backup rola
- /scratch -> jatszoter, nem mentem
- /var, /var/home -> inkrementalis backup naponta, full akkor, ha az addigi inkrementalisok esznek annyi helyet, mint az elozo full

A mentesek keszitesere kulcsauthentikalt backup user, sudo a mentoscriptre, kivulrol jon es futtatja a scriptet (ssh backup@host 'sudo /valahol/mentes.sh' >mentes-$(date).tar.bz2). A mentoscript 'tar cjl $mit_mentsek' full esetben, ugyanez '--newer /var/state/backup/backup.marker'-rel inkrementalis esetben.
Ami meg nincs benne: titkositas (egyszeru lenne), extended attributumok (pl. immutable :)..) kezelese.
Amire nagyon jo meg, az a /, /usr integritasellenorzese: ugyanaz, mintha mentest csinalnek, de csak az md5-jet nezem. Uzemszeruen _nem valtozhat_, ergo az md5 sem.
A particio-szintu mentessel az volt a bajom, hogy (mivel a felszabaditott helyeken is van adat), nem igazan tomoritheto, ergo iszonyu nagy darab, es nehez belole pl. csak reszeket visszahozni. A particiorol-tar-bz2 eseten kezzel kell ujraparticionalni az uj vinyot, kitomoriteni, ujra-lilo-zni, stb., de altalaban tobbszor mentek, mint ahanyszor vissza kell allni belole :), ergo ez a plusz negyedora nekem megeri a helytakarekossagot.

[quote:379b7dfd04="Rich"][quote:379b7dfd04="norbert79"]
Nem tud valaki egy olyan Norton Ghost féle megoldást? Vagy, hogy hogy tudnám az egész rendszert több részre összetömöríteni, esetleg milyen ISO készítő progi van, stb?... Olyan megoldást keresek, ahol a boot lemezt betéve image fájlokból vissza tudom tölteni a rendszert... (alá Norton Ghost)

A partimage valami ilyesmit tud, bár még nem használtam.

http://www.partimage.org/

Rich

Mi használjuk üzemszerűen. Akár hálón egy másik gépre is át tudod nyomni az image-et, vagy persze ki is írhatod. Le tudja menteni a win partíciódat is. (Már akinek van ilyenje...)

Charlie.

[quote:16a8c4d54a="sz"]miért nem rsync? tudja csak a változásokat menteni, esetleg utána md5 hogy minden rendben van-e: megszakadt kapcsolat - félig átvitt fájlok stb

Elolvastad a peremfelteteleket, vagy csak beleszolsz?

asd

[quote:4535949818="tso"]miért nem rsync? tudja csak a változásokat menteni, esetleg utána md5 hogy minden rendben van-e: megszakadt kapcsolat - félig átvitt fájlok stb

Mert minden commitkor keletkezik egy dump_XXX file (ahol XXX a revízió száma), és ez csak az adott commit által végrehajtott változásokat tartalmazza. És ez a file egyedi minden commit esetén, tartalma a továbbiakban már nem változik, úgyhogy az rsync felesleges.

[quote:4535949818="tso"]vagy maradsz scp-nél de ugyanúgy csinálsz md5-öt minden átvitt fájlról és azt is átküldöd a másik gépen meg bizonyos időszakonként ellenőrzöd hogy a másolat megegyezik-e...ha nem úgyis látod:pl dob egy mail-t hogy nem egyezik, vagy csak része jött át, akkor meg átnyomod újra...

Igen, nagyjából tudom, h mit kellene csinálni, h szép legyen és jó, de erre írtam az előző hsz-ben, h ennek a megírására és főleg a tesztelésére nincs most idő.
Meg abban is biztos vagyok, h ilyet már valaki csinált, csak én nem bírtam eddig megtalálni. Aztán ha nem muszáj, akkor nem állok neki a kereket újra feltalálni (;

egyezz meg vkivel, h közösen backupoltok egymás szerverére (lehetőleg pár 100 km távolság legyen köztetek) :wink:

[quote:c05ea80f0b="charlie"]
Mi használjuk üzemszerűen. Akár hálón egy másik gépre is át tudod nyomni az image-et, vagy persze ki is írhatod. Le tudja menteni a win partíciódat is. (Már akinek van ilyenje...)
Charlie.

Legyen meg egy + pont a partimage mellett! :) Kb 20 win klienst mentek vele NTFS-sel + Partimage-el installalok uj Windows-t is :) Legjobb! :)
Csak egy aprodag meg: Ha NTFS-t mentesz vele A VILAGERT SE TOMORITSD a partimage-el az image-et mert a budos eletbe tobbet nem latod az adataid :)))

[quote:43a5548025="vmiklos"]egyezz meg vkivel, h közösen backupoltok egymás szerverére (lehetőleg pár 100 km távolság legyen köztetek) :wink:

ilyen gondom nincs. :)
1 km a tavolsag jelenleg ami csak az atom ellen nem ved :)

[quote:0f5f00e4b8="algernon"][quote:0f5f00e4b8="Oregon"]
- Sokak rsync-re eskusznek, viszont ezzel az a gaz, hogy a usererror-t vagyis nem kivant torlesek ellen nem ved, hanem szepen leszinkroniazalja azt is.
Mivel tavoli menteseket keszitek, igy a felesleges adatmozgas miatt nekem meg igy is ez a legjobb megoldas jelenleg.

Inkrementalis backupot kell csinalni.

Egy masik erdekes program a pdumpfs, amivel http://snapshot.debian.net/ keszult. Egyetlen hatranya, hogy nem remote (de a keszitett cuccokat rsyncel at lehet kuldeni, vagy helybol NFS-re csinalod, vagy hasonlo O:).

Azt hiszem kell keresnem egy idegen szavak szotarat. :)

NFS: nos ez nem mindig valt be, mivel a ket halo wlan-nal van osszekotve egy-egy iranyitott antennalval es van olykor szakadas, csomagveszteseg. Ilyenkor rendesenbefekezodnek a dolgok.

Azert koszonom a tippeket.

[quote:7e8b16a17f="Oregon"][quote:7e8b16a17f="algernon"][quote:7e8b16a17f="Oregon"]
- Sokak rsync-re eskusznek, viszont ezzel az a gaz, hogy a usererror-t vagyis nem kivant torlesek ellen nem ved, hanem szepen leszinkroniazalja azt is.
Mivel tavoli menteseket keszitek, igy a felesleges adatmozgas miatt nekem meg igy is ez a legjobb megoldas jelenleg.

Inkrementalis backupot kell csinalni.

Azt hiszem kell keresnem egy idegen szavak szotarat. :)

Inkrementalis -> nem felulirja az elozo backupot, hanem csak azt backupolja, ami az elozohoz kepest valtozott.

[quote:7e8b16a17f="Oregon"]
NFS: nos ez nem mindig valt be, mivel a ket halo wlan-nal van osszekotve egy-egy iranyitott antennalval es van olykor szakadas, csomagveszteseg. Ilyenkor rendesenbefekezodnek a dolgok.

Az csak egy vad otlet volt. pdumpfs + rsync jobbabb. Ha meg local backupot egyatalan nem akarsz, akkor rsnapshot. (Van meg rdiff-backup is a radarom, meg meg par dolog...)

Ez is boot lemezzel dolgozik. FTP-n lehet atvinni a cuccost, es egy iso fajlt csinal. Hasonlit a NG-ra :)
Lehet vele egyben lementeni a vinyot, vagy lehet particiokrol csinalni image-t.

http://www.feyrer.de/g4u/

Yndy

[quote:b509ecd4a9="vmiklos"]nembaj az, ha menti az egészet
a csak a diffet mentené, akkor bármelyik diff sérül, megszívtad. így van 1 kis "hibatűrése" a backupnak :wink:

Ezt nem igazan ertem. Ha barmelyik diff megserul akkor az aznapi diff nem lesz jo, de az elozo ill. majd a rakovetkezo miert lenne hibas? Pontosan ugyan igy ha az egesz 2 gigat mented az is megserulhet (es meg nagyobb esellyel is raadasul).

[quote:70b46b03d8="vmiklos"]nembaj az, ha menti az egészet
a csak a diffet mentené, akkor bármelyik diff sérül, megszívtad. így van 1 kis "hibatűrése" a backupnak :wink:

Ezert kell tobb helyre backupolni. Meg X idonkent (havonta, kethavonta, igenytol fuggoen) full backupot csinalni.

Elöször is meg kell határozni mennyit érnek az adatok...
A mentés soha se kerüljön többe mint az adatok értéke.
Viszont nagyon olcsónak sem érdemes lennie, kivéve ha teljes biztonságot ad.

A szallagos megoldás lehet nem a barátod, de még mindig az egyik legmegbízhatóbb dolog. Ezenfelül jó sok adat rámegy manapság már egy kazettára. Persze ha már több TB feletti menyiséggel dolgozol...

Ezenkívül havi mentést mindig elrakni, közte a kazetták egy heti forgásban (ha van pénz akkor a havi forgásban) ha nem sok változás van akkor az inkrementális vagy differenciális mentés egy gyors alternativa persze ez esetben jó lenne, ha a hétvégi mentés teljes lenne.
Így a visszaállítás véletlen törlés esetén 1 héten (vagy 1 hónapon) belül mindig lehetséges.

De a lényeg az, ha az adat sokat ér, ne gasasoskodjatok a mentéssel.

Ja és a mentési költségeknél azt is figyelembe kell venni, hogy nem az 1MFt-s mentőegység a költség, hanem etetni azt kazettákkal. Lehet hogy egy mentőegység olcsó, viszont drágák hozzá a kazetták...
Mi csak azzal hogy vettünk egy nagyobb szallagos egységet 2MFt-ért, amihez a korábbival ellentétben, 5-6 szallag helyett elég 1 szallag is, így éves szinten 3MFt-t spóroltunk meg, szóval az első évben nyereséget termelt az eszköz...

-Mr-

azt nem tudom, hogy a legoptimalisabb-e, de amit talaltam, nagyon megtetszett. a Ben Summers nevu angol ember azt csinalta meg BSD-licence-szel, ami volt novellen is:
* snapshot- es lazy (allandoan tukrozo) mentes, akar kombinalva
* csak a kulonbsegeket kell elkuldeni a backup-szerverre
* cert-alapu az egesz, kulcs nelkul a backupgep gazdaja csak nagy halom adatot lat (AES)
* hard- es softlimites quota, melynek terhere a torolt illetve uj verzioju file-ok regi peldanya marad meg
* intuitiv kezeles, igenyes CLI, eszkozok
* mar vagy 2 eve fejleszti, es igen megbizhato, de a szerzo igen ovatosan banik a production kifejezessel, ami backup software eseten elonyos

a software-t openbsdn kesziti a szerzo, de linuxon szerintem tobben hasznaljak, valamint mostanaban keszult el a win32-es build, igy windowst is lehet vele menteni (de nem windowsra).
http://www.fluffy.co.uk/boxbackup

Az optimalis az azt jelenti, h az elerheto legjobb.
Ebbol kovetkezoen nem letezik olyan h optimalisabb, sem legoptimalisabb.
Az egyik zeneszerzo (Beethoven, Bach, Mozart vagy talan Paganini?) egyik muveben azt az utasitast irta: Olyan gyorsan jatszani ahogy csak lehet.
Nehany sorral kesobb: Gyorsitani!. ;-)

Azt hiszem, így csak a merevlemezes mentés marad. Én is utálom a szalagos/cd/dvd mentést, ezért ha az illető cég is úgy gondolja, a következőt csináltam:
A mentés egy vagy több backup szerverre történik (attól függ, mennyire kényesek az adatok), a backup szerverek merevlemez mérete minél nagyobb legyen. Lehet jó szkripteket írni vagy perl progit (én inkább python) arra, hogy figyelje, mikor kezd kevés hely lenni a lemezen és ekkor figyelmezetető mailt küldjön. Ahol ezt engedik, ott automatikusan fel is szabadítja a helyet ilyenkor (törli a legrégebbi egy hetet). A backup szerverből egy a telephelyen van, de lehetőleg távol a szerverektől, bár van ahol ez nem oldható meg. A másik (vagy az egyetlen) pedig egy szerverparkban van elhelyezve. Attól függ az egész, a cég szeretné-e ha a saját szerverszobájában legyen vagy csak/és a szerverparkban. Én tar.gz-be szoktam menteni a megváltozott anyagokat egy szkripttel, minden napot egy-egy könyvtárba, ahol több részre van bontva a mentés, hogy ne keletkezzenek óriási fájlok, ha lehet. Persze az elején, illetve nagyobb változásnál kell egy teljes mentés is. A mentendő gépben szoktam csinálni egy partíciót erre ugyanazon vagy másik merevlemelezen, ahová lerakja a fájlokat, aztán sftp-vel elküldi a backup szerverre, majd törli a helyi gépről.
Persze van, ahol dvd-re megy és ezek másolatait hetente elviszi egy cég, saját páncéljába rakja és így őrzik. Ez tűzkár ellen nagyon jó védelem.

En egyszeru find, tar, scp parancsokat hasznalok crontabbol, valahogy igy:
[code:1:0806821a4e]#! /bin/sh

datum=`date +%y%m%d`
cd /root/mentesek

find /home -type f -newer utolso -not -name '*.iso' -not -name '*.bak' -not -name '*.asv' -print0 | xargs -0 tar czf $datum.tgz
ls -lR /home | gzip - > $datum.ls.gz
touch utolso

#Kevésbé elegáns, kimaradt napot nem potolja, de addig is...
scp -pq $datum.* soky:mentesek
[/code:1:0806821a4e]
A teljes ls-t is mentem, hogy tudjam melyik metesben kell keresni egy veletlenul torolt file-t.
A helyreallitas kicsit nehezkes, de szerencsere ritkan van ra szukseg.

sziasztok

Itt egy mentésekkel foglalkozó link:
http://www.backupcentral.com/
Itt össze van gyűjtve egy csomó kereskedelmi, és ingyenes szoftver, emellett hardverekről is lehet sok hasznos infót kapni.

Mivel van némi tapasztalatom mentési rendszerekben (jelenleg kb. 100Terabyte mentett/archivált adatot tárolunk egy 110 kliensből 2 szerverből, és 3 automata szalagkönyvtárból álló backup hálózaton) ezért egy két gyakorlati tippet adnék. Ezek egy részét már egy páran le is írták.

1. Mérd fel az adataid értékét. Ebbe beletartozik, hogy milyen adatból hány mentett verziót akarsz megőrizni, vagy meddig akarod tárolni a mentett adataidat.
Fogalmazd meg, hogy milyen elvárásaid vannak a mentő rendszerrel szemben: mentendő kliensek száma, típusa. Kritikus -e a mentés sebessége, a visszaállítás sebessége. Adatbázisok esetében kell -e "online" adatbázis mentés, stb.
Ezek ismeretében dönts a költségkeretről.

2. A fentiek után válaszd ki a mentőrendszert. Nagy mennyiségű adat gyakori mentése esetén érdemes lehet automata szalagkönyvtárba beruházni. Több tera mentése esetén egyébként a szalagnak van a legjobb ár/MB aránya. A szalagok elég megbízhatóak, bár 10 évnél hosszabb tárolási idő esetén időnként célszerű átírni az adatokat új szalagra. A szalag másik nagy előnye, hogy hordozható! Ha diszkre mentesz, egy távoli helyre, és leég az irodád, nem biztos, hogy lesz hálózatod, amin vissza tudod hozni az adatot, és a diszket nem biztos, hogy gyorsan a helyszínre tudod vinni.
Ha a mentőrendszer nem biztosítja a mentések időnkénti automatikus ellenőrzését, célszerű időnként visszatöltéssel ellenőrizni a mentések állapotát.
A megtelt szalagokat érdemes tűzbiztos szekrényben tartani. Ez nem csak a tűz ellen, de az "elkallódástól" is véd. (Egy kis méretű tűzálló "mackó" szerintem bármilyen cégnek megfizethető)
Ha központi backup szerverrel dolgozol, annak a konfigurációját mentsd a leggyakrabban.
Jó megoldás a több szintű mentési rendszer: A mentett adatok először diszkre kerülnek, majd folyamatosan íródnak ki szalagra, úgy hogy a legfrissebbek mindíg elérhetőek diszkről is. Ez egyrészt a mentés sebességét is növeli, másrészt ha "gáz van" akkor az utolsó mentés gyorsan elérhető.
Jó dolog az inkrementális mentés, de megfelelő időnként (a mentés gyakoriságától függően) mindenképp kell teljes mentéseket csinálni.

Én mentési rendszerben a Tivoli Storage Managerre esküszöm (a Veritas Netbackup sem rossz), bár tény hogy ez baromi drága. Az ingyenesek közül az Amanda elég igéretes (www.amanda.org). Az Interware szerverhoteljében is ezt használják, de személyes tapasztalatom nincs benne. Több kliens mentése esetén érdemes meglévő (ingyenes, vagy kereskedelmi) szoftvereket használni, és nem saját scripteket, mert a bugok nem mentéskor, hanem sürgős visszaállításkor jönnek elő. :)

Sajnos nem volt meg idom kiprobalni, de talan ez is egy alternativa:

http://www.bacula.org

Tamogatott rendszerek: Linux, FreeBSD, Solaris, MacOS X/Darwin, OpenBSD Client, IRIX Client, True64, Windows98/Me, Win2k, XP es allitolag AIX, HP-UX-en is megy, de errol meg nincsenek konkret tapasztalatok.

Hello,

Évek óta adattárolási és backup rendszerek tervezésével és implementálásával (és persze értékésítésével :) ) keresem a kenyerem. zwei mondandója elég jól összefoglalta a lényeget. bár nem feltétlenül a megfelelő összefüggésekkel.

Az első lépésként mindenképpen tisztába kell jönnöd az adataid valódi értékével (nem azzal, hogy mit gondolsz róluk, hogy hanem hogy a cégednek akár anyagilag akár erkölcsileg mit jelent ha nincsenek).
Ez meghatározza a költség kereteid, ebből pedig kialakul a lehetséges megoldások köre. Eztán ki kell alakítani a mentési stratégiát (mit, mikor, hova, hányszor, meddig stb.) majd neki lehet állni a gyakorlati megvalósításnak az első tesztekkel és egyebekkel.

a backupcentral jó oldal, de az http://adatkezeles.lap.hu oldalon is találtok egy kis link gyűjteményt. Néhány nem él a linkek közül, de sokféle megoldást mutat.

üdv,
dragon

[quote:ed00579615="zwei"] A szalag másik nagy előnye, hogy hordozható! Ha diszkre mentesz, egy távoli helyre, és leég az irodád, nem biztos, hogy lesz hálózatod, amin vissza tudod hozni az adatot, és a diszket nem biztos, hogy gyorsan a helyszínre tudod vinni.

Több kliens mentése esetén érdemes meglévő (ingyenes, vagy kereskedelmi) szoftvereket használni, és nem saját scripteket, mert a bugok nem mentéskor, hanem sürgős visszaállításkor jönnek elő. :)

A legtöbb megállapítással egyetértek de "ha leég az irodád", akkor nem feltétlen a leggyorsabb visszaállítás a megoldás, már úgyis nagy a baj, el lehet ugrani a lemezért.

Nekem szkripttel megy, de sohase volt bugos. Egyszerűen le kell ellenőrizni. Egy év alatt elég tapasztalat halmozódik fel, hogy tudjad, jó-e a megoldásod.

A legtöbb megállapítással egyetértek de "ha leég az irodád", akkor nem feltétlen a leggyorsabb visszaállítás a megoldás, már úgyis nagy a baj, el lehet ugrani a lemezért.

Attól függ. Amint azt dragon is írta, előbb fel kell mérned, hogy mi az adataid valódi értéke, és kell egy jó mentési stratégia. Könnyen kiszámolható, hogy mennyi bevételtől esik el egy cég minden kiesett óra alatt. Nem is beszélve az ügyfelek felé az erkölcsi kárról.
Gondolj bele pl. hogy egy Linux társzervert üzemeltetsz, ahol van pár fizetős ügyfeled. Ha elszállnak az adataid, akkor minnél gyorsabban helyre kell állítani, különben megrendül a szolgálltatásodba vetett bizalmuk.
A leggyorsabb nem jelenti azt, hogy összetákolt!
Nem csak a mentési stratégia a fontos, de a visszaállítási is. Az "elugrunk a vinyóért" módszer nem nevezhető a legjobb visszaállítási stratégiának.

Nagy rendszerek esetében nem csak mentési/visszatöltési tervek, de üzletfolytonossági tervek is vannak. Azaz nem elég azon gondolkodni, hogy hogyan hozzuk újra működőképes állapotba a rendszert, de arra sem árt, ha van terv, hogy hogyan tudunk addig is dolgozni, amíg minden újra helyre nem áll. Ez már nem feltétlenül informatikai dolog, de hasznos lehet bárkinek.

Nekem szkripttel megy, de sohase volt bugos. Egyszerűen le kell ellenőrizni. Egy év alatt elég tapasztalat halmozódik fel, hogy tudjad, jó-e a megoldásod.

Van egy privát szerverem, azt én is scripttel mentem (rsync). Nincs ezzel semmi baj. 1-2 gép esetén eléggé overkill is lenne ennél bonyolultabb megoldás.
De ha már több rendszered van, érdemes egy erre a célra fejlesztett meglévő szoftvert használni, ami pl. a mentett fileok adatait (mikor mi lett mentve, stb) is képes adatbázisban tárolni, illetve egy egységes, könnyen karbantartható/skálázható megoldást ad.

[quote:23f65df872="tef"]* snapshot- es lazy (allandoan tukrozo) mentes, akar kombinalva

Errol jut eszembe.
Akkor az teljesen jo, ha rsync-vel atrantom majd a a back_up szerver csinalja a snapshot-ot.
Azt hiszem ez lesz az en haverom.
Vagy ennek is van hatulutoje?