Jobb későn, mint soha - Haszprus überblog

RSS: hozzászólások ehhez a bejegyzéshez 18 hozzászólás - Szólj hozzá Te is!


1) Hedge
Hmm… Valami backup egység nem lenne nálad jobb megoldás? Nem olcsók ezek a cuccok, de hosszú távon nagyon is kifizetődők… pl engem sokszor mentettek meg az idegösszeomlástól…

Hedge, az a kérdés hogy milyen módon frissül rajtuk az adat. Nos? Mert ha full automatikusan, és mondjuk on-the-fly felkerül rájuk minden, az nagyon istenes. (Kérdés mit ér meg, olyan sokat azért nem. Nem az a nagy baj, ha elvész x órányi cuccom, hanem hogy elvész x évnyi cuccom.)

Asszem, hogy egy vinyó a mentés olcsóbb, mint a DVD-k, azonos tárhelyet feltételezve.

Olthyer, ebben az árkategóriában ez nekem nem szempont (mindkettő olcsó)

ami szempont az a megbízhatóság, hozzáférhetőség, újrahasznosíthatóság és a mentésre/ellenőrzésre ráfordítandó idő

Haszprus,
ami szempont az a megbízhatóság, hozzáférhetőség, újrahasznosíthatóság és a mentésre/ellenőrzésre ráfordítandó idő
Mind alapján ráadás vinyó, nyilván - nem is értem, miért szöszölgettél DVD-kkel.

Olthyer, megbízhatóság… egyszerre szállt el a backup vinyóm és a normál… ilyen dvd-vel nincs.

amúgy vinyón már így is két példány van mindenből.

7) WiZARD
Vinyó akkor használható backupnak imho, ha a géptől független. Minimum a tápellátása, de még jobb ha szekrényben van, és heti 1x rakod be, amikor backupolsz rá.
Dvd sajnos közel se megbízható hosszútávon.

(én is dvdre backupolok)

WiZARD, még mindig az a bajom ezzel h semmi se garantálja h ne pont 1xre szálljon el a két vinyó
ha valami elektromos probléma van akkor könnyen szállhatnak el 1xre

Haszprus, A DVD 1-2 év alatt használhatatlanná válik.
WiZARD, Egyetértek. Heti egyszer bepakolni, cuccokat felmásolni; amúgy szekrényben.
Mi is így használjuk a filmes vinyót, ami kb. tényleg csak tárolásra kell.

10) Tamás
Haszprus, volt olyan külső vinyóm, amin volt egy hatalmas Sync gomb, és adtak hozzá valami windowsos programot, ami a Sync gomb megnyomására a háttérben az egész belső vinyót lemirrorozta USB-n a külső vinyóra. Valami Freecom vagy milyen márka volt, már nem emlékszem rá, meg nyilván nem is tudtam kipróbálni, mert OS X-hez nem adtak drivert :-/ (Azóta mondjuk OS X-re lett Time Machine, úgyhogy már nem hiányzik). De szerintem neked valami ilyen lenne az ideális megoldás; asztali gépben akár folyamatosan bedugva is tarthatod a külső vinyót, kicsi az esélye, hogy USB-n keresztül független tápellátással is ugyanakkor döglik meg, mint a belső.

Én tervezem a közeljövőben 2 db 250 GB-os HDD beszerzését és RAID-be kötését. Lesz 5 parcíció, az utolsó a backup. Oda tolom át, amit menteni kell (lesz kifejezetten olyan partíció, amire azon cuccok kerülnek, ami jó ha kéznél van, de nem sírok, ha eltűnik). Külső backup vinyó meg egy 250 GB-os notebook hdd lesz USB-s (és/vagy FireWire-ös) keretben. Ezen kívül minden megy ki DVD-re is 2 vagy 3 példányban.

A technikai része nem is gond, csak pénz kérdése. Ami ennél kérdésesebb egy normális backup szisztéma kidolgozása. Eddig arra gondoltam, hogy tematikusan dobálom át nap végén backup partícióra a dolgokat, majd onnan backup vinyóra. Ha megvan egy DVD-nyi anyag a backup vinyón, akkor az megy DVD-re is. Valószínűleg év-hónap-nap formában lesznek a könyvtárak és ha van már egy újabb DVD-nyi anyag, már pörköljük is.

Viszont ezt csak a munka jellegű dolgokra csinálnám (programok (forráskódok), tervek, doksik, levelezés, stb.), a képek, zenék külön állatfaj. Azoknak fent lesz tartva egy partíció, amin gyűjtögetve lesznek. Ha megértek mentésre (összejött egy DVD-nyi anyag pl. albumokból), akkor mennek DVD-re 2-3 példányban (ha megtartani nem akarom, de ha még meg akarok hallgatni valamit, akkor megy a nem mentendő anyagok közé).

Ezen kívül gondolkodom a teljes oprendszer heti vagy havi ghost-olásán, de ez nagy eséllyel csak backup vinyóra kerülne, DVD-re nem.

12) NeoXon
Max Logan: allati termelekeny programozo lehetsz, ha a forraskodot mindig DVD-kre kell menteni Szvsz a forraskodja meg egy oprendszernek is elfer egynehany floppyn. Ehelyett erdemesebb egy SSD-n vagy akar pendrive-okon elmenteni, azok ha nincsenek surun hasznalva, evtizedekig is biztonsaggal taroljak az adatokat.

Persze ha ejjel-nappal videot / zenet vagsz es meg evek multan is szukseg lehet a nyersanyagra, akkor valoban jol johetnek a DVD-k meg X db backup vinyo.

Max Logan, verziókezelő rendszer

NeoXon: mint írtam, nem csak forráskódok, hanem doksik (pl. árajánlat, szerződések, stb.), a teljes levelezés backup-ja, szóval a munka termékeit menteném ki napi lebontásban. Valamint pl. hobbi tevékenység termékei (SketchUP modellek), stb.

Haszprus: anno próbálkoztam SVN-nel, de értelmes, szájbarágós, alapoktól kezdős, magyar doksi nélkül nem igazán éreztem rá az ízére, avagy az értelmét látom, csak használni nem tudtam. Amit nem igazán értettem, hogy mit és miért és miért ott tárol le a fájlrendszerben; Windowsról van szó egyébként és egy nagy nehezen neten levadászott magyar doksi alapján telepítettem fel a szervert + TortoiseSVN-t.

Így maradt a minden nap kimentünk mindent elv. Ami bár rendundáns adattárolás, viszont a DVD nem túl drága.

Ui.: Valaki egy értelmes full alapoktól kezdős magyar SVN doksit nem tud? Tehát onnantól kellene, hogy induljon, hogy igényünk van a verziókezelésre, definiálja, hogy mi az, aztán mint megoldás vezesse be az SVN-t és magyarázza el, hogy mit, miért, hogyan.

Max Logan Anno a lab4 projectet csináltuk épp TortoiseSVN-nel, de én semmit nem olvastam hozzá, eléggé magától értetődött (igaz, nagyon mélyre sem ástam benne). Megkérdezem a srácot aki feldobta hogy használjuk, hátha neki van valami kiterjedt doksija.

mainframe: Bő fél évvel ezelőtt próbálkoztam SVN-nel. TSVN-nel nem volt gond, működött, használtam is. Csak nem igazán értettem, hogy a history-t file szinten miért úgy menti el ahogy. Valamint nem volt részletes leírásom arról, hogy gyakorlatban hogyan kell csinálni pl. azt, hogy van egy project, annak egy modulját (jól körülírható fájlok fizikailag más helyen a könyvtárszerkezetben) akarom kicsit átalakítani, hozzátenni fájlokat, és ezt hogyan tudom megcsinálni, hogy majdan tudjam egyesíteni az éles project-tel.

Szóval a lényegét értem, hogy mire jó a verziókezelés, csak gyakorlatban nem igazán tudom, hogy hogyan kell megvalósítani, amit akarok. Arra meg sem időm, sem kedvem, hogy kisakkozzam, hogy mit és hogyan kell.

Meg az sem teljesen tiszta, hogy hogyan tud több ember egy project-en dolgozni. Van pl. egy olyan file, ami alapja egy project-nek (valami alap osztály vagy közös lib fájl) és ezt b*sztatja két ember, más dolgokat ír át benne (de pl. ugyanazt a függvényt, vagy osztályt), hogy ebből hogyan lesz a végén egy olyan kód, amiben mindkét ember változtatásai benne vannak és a kettő funkcionalitása egyesül. Szóval az elméleti hátterét és a folyamatokat nem ismerem, ehhez nem találtam magyar leírást…

Anno SVN nekem végülis arra kellett volna, hogy: van egy élesített project, ami áll X db file-ból. Jön egy fejlesztési igény, változik több file is a már éles project-hez képest, majd a végén, amikor a DEV cucc működik, ne kelljen mindent file-t újra felmásolni az éles szerverre, hanem ki tudjam válogattatni SVN-nel, hogy mit kell nekem FTP-n feltölteni.

De ezen funkcionalitás miatt már nem kell SVN, mert kidolgoztam egy saját depolyment tool-t, amivel élesítem a project-et. Így ha valami változik, akkor új élesített csomagot kell létrehozni és mindent törölni az éles szerverről; mert a deployment tool pl. tömöríti a CSS kódot, a JS fájlokat, összevon PHP fájlokat, amiket tömörít is (lévén éles szerveren lévő kódot nem változtatunk, mert az nem egészséges…), stb.

Szóval, ami nekem hiányzik az a verziókezelési elmélet és ezt követően egy példákon keresztül bemutatott how to sorozat…

17) Tamás
Van pl. egy olyan file, ami alapja egy project-nek (valami alap osztály vagy közös lib fájl) és ezt b*sztatja két ember, más dolgokat ír át benne (de pl. ugyanazt a függvényt, vagy osztályt), hogy ebből hogyan lesz a végén egy olyan kód, amiben mindkét ember változtatásai benne vannak és a kettő funkcionalitása egyesül.
Az SVN a változtatásoakt úgy tárolja el, hogy egy 2-3 sornyi környezetet is eltárol a változtatásokkal együtt, ez alapján azonosítja be, hogy mit kell módosítani egy másik fejlesztő régebbi verziójú fáján, hogy az újat kapja. Ha két fejlesztő a fájl két olyan részét piszkálja, hogy a körülöttük lévő két-három sornyi padding részek nem érnek össze, akkor fasza minden, mindkét változtatás két független revízióban mentésre kerül és kész. Ha összeérnek, akkor a második fejlesztőnél azt fogja jelezni az SVN, hogy conflict van, odaadja neked az eredeti fájlt (amiből kiindultak a módosításaid), odaadja a másik fejlesztő verzióját, meg odaadja az általad módosított változatot, aztán tessék, oldd fel a konfliktust magad. Épp ezért van egy olyan szabály az SVN-ben, hogy committálni csak akkor lehet, ha a legfrissebb revízión állsz, hogy a legfrissebb revízióra való frissítéskor mindig kijöjjenek a conflict szituációk. Szóval így. Az SVN-nek fogalma sincs arról, hogy mit jelent az, ami a fájlban van (szemantikailag), ő csak összefésüli a módosításokat, ha tudja; ha nem, akkor meg rád hagyja a piszkos munkát.
van egy élesített project, ami áll X db file-ból. Jön egy fejlesztési igény, változik több file is a már éles project-hez képest, majd a végén, amikor a DEV cucc működik, ne kelljen mindent file-t újra felmásolni az éles szerverre, hanem ki tudjam válogattatni SVN-nel, hogy mit kell nekem FTP-n feltölteni.
Erre a legegyszerűbb megoldás az, hogy az éles verzió a szerveren egy SVN-ből checkoutolt változat, így ott csak azt mondod neki parancssorból, hogy svn update, aztán az SVN szépen letölti a változásokat. A dolog abban az esetben nem működik, ha a távoli szerverre csak FTP vagy SSH hozzáférésed van; ilyenkor én azt szoktam, hogy a saját gépemen van az éles változatból egy mirror, arra nyomok egy svn update-et, majd rsync-kel szinkronizálom a távoli változatot a saját gépemen lévő mirrorhoz.

18) palix (nem regisztrált)
NeoXon, ami azt illeti, egy OS forráskódja nehezen fér el egy pár floppyn.
Szerintem még nem láttál linux kernelt, ami lefordítva mondjuk 4-5 mega, a forráskód tömörítve 20-30 mega és kicsomagolva 300-400 mega és ez csak a kernel.


Egy évnél régebbi bejegyzésekhez nem lehet hozzászólni.