deduplikációs NAS megoldás backup célra

Merevlemezek, vezérlők

Szükségünk lenne egy 4 diszkes, RAID5-ös, 3T méretű, 1GBE-s hálózati tárhelyre backup célból, nettó 150K alatt (diszkek +50K). Minden éjszaka kb. 1T vagy 2T adat menne rá, ami nagyban hasonlítana már korábban ráírt adatokra. Azt hoztuk ki, hogy nem dedupos módszerrel, nagyobb tárhellyel, nem gagyi NAS-sal 200K-ból tudjuk kihozni a projektet diszkekkel együtt, de így csak pár napot tudunk menteni. Azt saccolom, hogy ilyen árból már egy kisebb tárhelyű, viszont dedupot tudó megoldás is kijön. A gép lehet dobozos, vagy akár dzsunka szerver is, nem kell redundánsnak lennie, hiszen ez maga a redundancia lesz. Szerintem már 100K-ból kijön egy dzsunka szerver, rádobunk egy Nexentát vagy FreeNAS-t vagy bármit, és projekt teljesítve, csak ugye zajos, sok helyet foglal, sokat zabál, stb. A kérdés az, hogy szerintetek egy ilyen gépecske tényleg teljesíti a kitűzött célt és teljesítmény elvárásokat, illetve van-e kicsit drágábban célhardver, amihez esetleg nagyon király management OS is jár, és jó tapasztalatotok van vele?

  • 3710 megtekintés

( zwei | 2011. 07. 04., h – 17:44 )

Teszteld ki bármivel, hogy tényleg alkalmas -e az adat dedupra. (pl. PC-re tákolt nexenta segítségével.)
Sok esetben tűnik úgy, hogy igen, a gyakorlat szerint aztán mégsem.

Adattól és körülményektől függően azzal lehet sok helyet nyerni, ha a backup storage megoldás tömöríti a mentett adatokat.

Ha egy szerverről mentek egy 500 gigás teljes image-et, aztán másnap megint, az tapasztalatok szerint 95%-99%-ban egyforma lesz. Ha mentek 10 külön gépről 10 db teljes image-et, és mindegyiken Windows Server 2008 R2 SP1 x64 van, azokban megintcsak sok gigabájt egyforma lesz, az adatokon és eltérő programokon kívül sok gigabájt, ami maga a Windows.

Követelmény, hogy teljes image legyen a lehető leggyorsabb visszaállíthatóság miatt, fájl szintű mentés kizárt. Követelmény, hogy mindegyik gépünkről legyen mentés. Követelmény, hogy sok napi backupunk legyen.

--
joco voltam szevasz

Ez a követelményrendszer azért igencsak durva - vélelmezem, hogy backup terén nem túl advanced ember állította össze, no mindegy. Ha tényleg ezt kell megcsinálni, akkor tényleg garantáltan működő, dedup-ot tudó storage kell, inkább sok kicsi, mint kevés nagy diszkkel, lehetőleg raid 10-et használva.

(Csak egy apró kérdés: ha minimális a változás, akkor a tömörített image mondjuk hetente plusz napi változás normálisan mentve miért is nem jó?

Mekkora a visszaállásra az időablak? A "leggyorsabb" az eléggé messze van a jól definiálttól.

Én állítottam össze, és Windows Server Backup-pal egyáltalán nem durva, ha megvan a dedup. Ennek a cuccnak annyi a hátránya, hogy hálózaton keresztül csak full image-et tud menteni. Cserébe a visszaállítás időtartama nagyságrendileg akkora, mint egy Windows telepítés. Ha elkezdek tömörítgetni, az eleve nem egyszerű, ha az MS by default nem támogatja, és az egyforma blokkok száma is nullára fog konvergálni. Full image mentés végtelenül egyszerű, gyors, jól támogatott. Ha van dedup, akkor simán elfér rá sok gép sok napi mentése, tehát csak ennyi a kulcs.

--
joco voltam szevasz

Bocs, de nagyon látszik, hogy brossúra alapján lett kitalálva, és nem megtervezve. A mentési időablak 11 óra, ami egy mentés bármilyen elhasalása esetén már kevés lesz.
A kulcs nem az, hogy "belefér", hanem hogy lehetőleg minden eshetőségre gondolni kell. Persze, neked elvileg egyszerű a dolgod azzal, hogy csak egy dvd-t kell bedugni, aztán visszaáll az előző állapot, de egy normális mentési rendszernél sem sokkal több - és ott jóval kevesebb adatot kell megmozgatnod, jóval nagyobb biztonsággal férsz bele a mentésre szánt időbe, etc.

( siposg | 2011. 07. 04., h – 18:50 )

A 100-at kevésnek tartom. Elég nagy méretű diszkekből összerakni nem kevés pénz, még ha a gép ingyen volt is. Nekem egy celeronos gép állt rendekezésre egy adott környezetben. A sata vezérlő, meg a két diszk a tükörhöz akkor vitte a 70-et. Kisebb diszkekkel sem lesz sokkal olcsóbb. Szóval szerintem megoldható sufnigéppel az alábbiakkal:

- tar rsyncnek megfelelő opcióval
- rsync --link-dest paraméterrel értelmesen

Linuxscripting

Rsync nem igazán jöhet szóba, a gépek on-the-fly állítják elő a nem kicsi image-eket, és nem lehet helyben tárolni őket.

3*1.5T SATA diszk megvan nettó 50-ből, így RAID5-tel adott a 3T tárhely. Szerintem 100-ból már nem rossz gépet lehet összerakni, csak épp a fogyasztása, zaja, mérete nem optimális.

--
joco voltam szevasz

Hmm, azt hiszem a tar-ra gondoltál, vagy nem backupra van szükséged, esetleg én nem értettem mit szeretnél.

Akármekkora imidzseket is lehet másolni. Valóban az rsync fájl alapú dedupot tud nyújtani. Neked blokk alapúra lesz szükséged, ha jól értem.
Ez esetben a sebesség lesz talán a legfontosabb, inkább több diszk, mint kevesebb. Raid-5 helyett inkább használnék raid-10 -et minél több diszkkel.

Linuxscripting

Block alapon pl az EMC datadomain lehet megoldás, de az nem ez az árkategória, viszont a dedupot már kliensoldalon elvégzi, így nem megy minden át a hálón. Persze ahhoz egy backup szoftver is kell a kliensekre.

Javasolom alkalmanként a teljes mentést offline usb-s hdd-re és a szokványos módon az adatok mentését, ha van dedup akkor jó, de hogy ne kelljen minden nap átpumpálni az összes adatot, azt is inkrementálisan oldható meg rendesen, a db-k csak dump-al mennek. Vagy egy rendes bacckup alkalmazással megoldod, duplicity, bacula, stb... erre én is rákérdeztem, eddig targz elég volt, de nem túl elegáns.

Milyen adatok vannak?

Most láttam csak a többi hozzászólást. Míg válaszolok, nem látom csak az első bejegyzést...

Szóval virtuális gépeket akarsz on the fly mentegetni snapshot jelleggel. Ez esetben meg kell vizsgálni a virtualizációt mit nyújt. Van amelyik a vendég gépek fáljait képes kezelni és az azonos fájlokat képes egy példányban tárolni a fizikai diszken, attól függetlenül, hogy különböző virtuális gépek imidzseiben vannak.

Linuxscripting

Szia!

ASUS E35M1-M
ADAPTEC ASR-2405 ROHS SGL SATA/SAS RAID 4 portos kártya PCIE
HDD Western Digital 2Tb SATA2 64Mb HDD (WD20EARS):
HDD Western Digital 2Tb SATA2 64Mb HDD (WD20EARS):
HDD Western Digital 2Tb SATA2 64Mb HDD (WD20EARS):
HDD Western Digital 2Tb SATA2 64Mb HDD (WD20EARS):
CHENBRO ES34169 Tower

Ez olyan 150k, 7200rpm-es vinyokkal ~170.
Bar attol felek ilyen teruleten egy Brazos nem lesz eleg ha tizenX terakat kell megmozgatni. :D

Ahhoz egy kicsit at kene terveznem az ajanlatot, de megallna 200k-bol szvsz, ha az mrg mindig a felso hatar.

( STP | 2011. 07. 05., k – 09:34 )

1. "Minden éjszaka kb. 2T adat menne rá..."
2. "...a gépek on-the-fly állítják elő a nem kicsi image-eket, és nem lehet helyben tárolni őket."
Aztán mekkora a kimenő sávszélességed, és a backup időablakod?
(Mert ez így egy kicsit durva.)

Igen, ez a része az. 50 MB/s sebességgel 11 órára jön ki, tehát este 20-tól reggel 7-ig nyugodtan lemehet. Aztán az is lehet, hogy majd páros-páratlan napi felosztás lesz, akkor már tuti menni fog. A sávszélesség nem probléma, mert a szomszéd irodába tervezzük tenni.

--
joco voltam szevasz

Nem vagyok otthon az NTFS-ben.
Tuti, hogy -normál üzemben- ha csak néhány 100 file-t változtatnak meg, az FS változása minimális? (page file, indexelés, miegymás)
Csináltál erre már tesztet, mielőtt egy rendszert építenél rá?

Másrészt cipőkanállal méretezni az időablakot nem túl szerencsés.
Harmadrészt, egy katasztrófaterv(ező) jót röhögne egy közvetlen közelben lévő (és vélhetően egyetlen) helyre történő mentési stratégián.

Mivel nem írtál napi változási rátát (csak céloztál rá, hogy minimális a változás), így talán jobb megoldás lenne heti egy full, míg a többi napon inkrementális mentést végezni. Ha már annyira image párti vagy, a full akár lehetne az is. A hét végébe biztosan beleférne.

A teljes épület összeomlására valóban nem számítunk, majd megemlítem a főnöknek, hogy evvel mi legyen.

Annyi a probléma, hogy a Windows Server Backup csak helyi diszkre tud inkrementálisan menteni. Hálózati helyre csak full image megy. Úgy véljük, hogy ha minden egyéb szempontból tökéletes a módszer, akkor hadd pörgesse pazarlóan a hálózatot.

--
joco voltam szevasz

A megoldás tényleg olcsó, gyakorlatilag semmibe nem került. De miért drága a fazék? És mit számít, hogy milyen a leves, ha egyszer backupnak lesz az egész? Csak nem dől össze a világ, ha nem a legjobb megoldást használom erre a célra, a lényeg, hogy ott lesznek az image-ek, évente 1x szükség lesz rá, és ennyi.

--
joco voltam szevasz

A storage, amire menteni fogsz, az a drága ebben az esetben. Nem annyi,a mennyit rászántatok, hanem pöttyet több. Ha a mentési időablakba ha nem férsz bele másfélszer az indulásnál, akkor előbb-utóbb szívás lesz belőle...

A levesnek (backup) nagyon jónak, mi több, optimális esetben az eredeti rendszernél megbízhatóbbnak kell lennie (ha nem tudod/nem jössz rá, hogy miért, akkor még gondolkodj rajta...).

Ki mondta, hogy nem felel meg a Windows Server Backup? Ha teszem azt találunk egy megoldást az inkrementális mentésre, a deduppal még akkor is jól járunk, mert sok hasonló gépünk van. Ha meg már dedup, akkor a Windows Server Backuppal csak annyi a baj, hogy egy csomó adatot átküld a hálón, aminek 5%-a lesz fizikailag diszkre írva, de ez nem zavar.

--
joco voltam szevasz

File alapú dedup esetén mindig mindent átküld, csak rendes backup szoftverek tudnak kliens oldalon dedupot végezni.

A WÍn server backup egy nagy XXXXXX. Semmit nem tud és még szar is.

Van ingyen használható megoldás is. Ha egyszerűen akarsz akkor rendes backup alkalmazások mellett, egy cobaian backup is jobb, persze a db-k mentését mindenképpen rendes dumpal kell megoldani, ha exchange is van akkor az tud egyszerre két tárolót is kezelni, persze csak lokálisan felcsatlakozva, mint iscsi, így abból tudsz online másolatot tartani.
Fájl alapon remek napi backupot tudsz csinálni rsync windwosos változatával és ahhoz tartozó rsync szerver dedup fájlrendszerrel, akár egyszerűen dátum nap könyvtárába célozva.

Mi lehet még?

Mindent fullra menteni minden nap hát ... általában fát se tankkal vágnak hanem fűrésszel.

Az se egy leányálom, ha fájl alapon akarsz visszaállítani egy teljes Windowst, én inkább pazarolnék a sávszéllel, de legyen image alapú. Az kell, hogy ha gáz van, akkor az utóbbi x nap mentéséből rámutatok egyikre, és abból 2 óra alatt legyen új rendszer. Esetleg tudsz olyan programot, ami image-et ment, de már kliens oldalon tárolja a blokkonkénti checksumokat, és csak a változott blokkokat küldi át hálózaton?

--
joco voltam szevasz

Nem kell azt olyan szigorúan venni. Akkor nem követelmény a 2 óra alatti visszaállás, de preferált. És mivel image alapú mentésnél ez a valóság, akkor minek adjam lejjebb? Mivel nincs végtelen sok pénzünk, muszáj lesz valami kompromisszum. A dedupos, full image-es megoldásnak összesen annyi a baja, hogy a hálózaton sokkal több adat megy át, mint ami változott. És akkor mi van, elporlad az UTP? Ezen kívül minden napra és minden gépre van egy full image-em, amiből 2 óra alatt visszaállok, a dedup miatt bőven elférek 3T tárhelyen, akkor most miről beszélünk?

--
joco voltam szevasz

Mondjuk azért add lejjebb, mert a garantált kettő órához drágább tárolótömböt kell beállítani. Ahogy írtad, a jelenlegi állapotban elég a mentési időablak. Mi lesz, ha jön még egy szerver, vagy megnő -csak 10%-kal a mentendő adatok mennyisége? Honnan lesz plusz egy órád a mentésre?
Hogy miről beszélünk? Nagyjából arról, hogy kaptál sok-sok tanácsot tapasztaltabb kollégáktól, javaslatokat megbízható(bb), jól bevált módszerrel történő mentési stratégia kialakítására úgy, hogy a tárolótömbre szánt keretbe is biztosan beleférj - a mentési időablak mellett. Te viszont kötöd az ebet a karóhoz, hogy az, amit kitaláltál, az jó, és az kell nektek.

Jó, és ha fájl alapon mentek, a túloldalon Samba/NFS/anyámkínja megoldásnál megmarad a mappákon például az összes Windowsos ACL? Megmaradnak az alternate streamek, a hardlinkek, meg mittudomén mik? Tényleg ennyire rossz az image alapú mentés, hogy most mindenki ezen rugózik?

--
joco voltam szevasz

Ez már csak a backup megoldáson/szoftveren múlik. Alapvetően semmi baj nincs az image alapú mentéssel, csak nem így szokták csinálni, mert általában nincs rá idő, és persze mert eszi a helyet mint állat.

Amúgy támadt egy - lehet h hülye - ötletem. Ha fel lehetne akasztani egy iSCSI "disket" akkor az vajon lokális disk lenne? Mármint a mentés szemével nézve? Mert ha igen, akkor arra kell dobni fájlrendszert, és máris tudsz inkrementálisan menteni a NAS-ra.Persze ennek a megoldásnak is tuti vannak betegségei, pl. minden gépnek külön kell kiadni egy-egy területet, de talán nem reményetelen.

"Ha fel lehetne akasztani egy iSCSI "disket" akkor az vajon lokális disk lenne?"

Igen, tudsz rá a Windows backuppal inkrementálisan menteni, mintha lokális diszk lenne.
Visszaállni viszont csak akkor tudsz belőle (bare metal restore), ha van iSCSI kártya a szerverben, mert a szoftveres iSCSI nem fog működni amikor az install DVD-ről bootolsz.

Kb. De mindenképp muszáj tesztelni hogy a visszatöltés rendesen megoldható-e. Nekem működik úgy win, hogy fel lett téve egy cd-ről, majd rá lett töltve a mentés. Viszont nekem ez a megoldás annyira nagyon nem tetszik, mert nem értek hozzá, és a fene se tudja, hogy mit hogyan állított vissza.

Viszont a gép azóta is megy, köszöni szépen.

Még nem próbáltam, de rémlik, hogy a Win 2008 R2/7-től kezdve a telepítő alapból tud visszaállítani.

Nincs baj evvel egyébként, mert ha máshogy nem megy, hát USB-n rádugom a backup eszközt a cél gépre arra a kis időre, valahogy majdcsak látni fogja.

Már csak az a kérdés, hogyan használok egy iSCSI eszközt sok Windowsról. Ez pl. úgy mehetne, hogy a RAID tömbre csinálok N darab NTFS partíciót, és egy gép egy partíciót használ. Így minden gép lát egy nagy NTFS partíciót, ahova tudja rakni a Windows Server Backup az inkrementális mentéseket, csak épp a dedupot buktam, ami azért a hasonló gépek miatt kicsit segítene, de végülis inkrementális mentésekkel talán már nem annyira baj ez.

--
joco voltam szevasz

Gondolom csak OS+app mentésről van szó, az adatokat máshol/máshogy mentitek. Ebben az esetben a szerverek teljes mentése mehet egy közös (dedup-ot tudó) megosztásra (azaz fájlrendszer szinten kiosztott területre, a napi inkrementális mentés meg egy-egy iSCSI LUN-ra, amik egymástól valóban független területek a tárolótömbön.
Ha a szervereken az automatikus frissítés be van kapcsolva, akkor arra gondolj, hogy azt mindenképp célszerű teljes (image) mentéssel kombinálni. Azaz: T teljes, I inkrementális (indexben a backup készlet száma), U update: T1I1I1I1I1I1UT2I2I2I2I2I2I2T1I1...

Csak ez így már két eszköznek tűnik. A Windows csak oda tud inkrementálisan menteni, ahova már tett egy teljeset, tudtommal.

Továbbá az iSCSI-val az is bajom, hogy blokk szintű, tehát az azt használó gép hiba esetén simán tönkrevághatja a fájlrendszert a backupon is. Illetve nem tudom a volume-ok méretét dinamikusan átrendezgetni, ami egy ZFS+SAMBA/NFS megoldásnál adott, illetve szükség sincs rá, mert ott többen tudnak egy tárhelyet használni. Elsőre jól hangzott ez az iSCSI, de szerintem nem megoldás a problémára, első körben mégis inkább ZFS+SAMBA/NFS.

--
joco voltam szevasz

arany apám, iscsi az egy protokoll, meg tudod csinálni még otthoni szappantartó dobozokkal is (a legtöbbje támogat iscsi-t), hogy nem egy partíciót ajánlat ki, hanem csinálsz egy image file-t (ami akár dinamikusan növekedhet, akár előre lefoglalod neki a helyet), aztán ezt a "virtuális diszket" ajánlod ki scsi-n.

ha egy tanácsot megfogadsz:
a sok hülyeséget, amit összehordtál, dobd ki, felejtsd el, s állíts be egy pc-t pár merevlemezzel, s ezen próbálj ki több nas rendszert(openfiler, freenas, stb.stb.), s kísérletezgess, próbálgass, s emellett olvasgass pár hétig, mielőtt élesbe nekiállsz megtervezni reális alapokon egy cég biztonsági mentési stratégiáját.

Szerintem nem hordtam össze annyi hülyeséget. Azt írtam fentebb is, hogy sose használtam még iSCSI-t, tehát ha egy iSCSI-hoz nem értő emberre akarjátok ezt ráerőltetni, nehogy már én legyek a hülye. Az is egy dolog, hogy egyesek szeretnek minden szóba belekötni, már erről is lehetne pár új témát nyitni, de azért a Windows image mentésre normális alternatívát eddig nem ajánlott senki. Tisztában vagyok vele, hogy nem értek minden ehhez kapcsolódó technológiához, mert fejlesztő vagyok, na de kérem, pont itt próbálok informálódni.

--
joco voltam szevasz

Nem ajánlott normális alternatívát? Olvasni tudsz? A legfontosabb, amibe többen belekötöttünk, az az, hogy cipőkanállal, brossúra-kockásfüzetes számolás alapon kijelentetted, hogy beleférsz a mentési ablakba. Bármi, ismétlem, bármi közbejön, már kapod is torokra a hosszúcumit, még a mentés során. Ráadásul a számításodba - gondolom- a mentett image ellenörzése nem is volt figyelembe véve - anélkül meg nagyjából orosz rulett a dolog...
Az csak hab a tortán, hogy a rászánható keretből a vázolt teljesítményigényt kiszolgáló, a jelenlegi szervereidnél megbízhatóbb(!) tárolást biztosító storage nem biztos, hogy ki fog jönni.

Ahogy én látom, minimum 2 nagyságrendnyi(!) különbség van a full és a napi inkrementális mentés mérete között. Ilyen esetre napi full-t csinálni, csak azért, mert arra van ingyen szoftvered... No mindegy, te tudod, csináld, ahogy akarod, én megyek drbd-vel játszadozni :-)

Jó, akkor máshogy kérdezem: tud valaki olyan szoftvert, ami image szinten képes Windowsokat menteni, az utóbbi X napból bármelyik image-et vissza tudom állítani a Windows telepítőből, és jól működik?

Tényleg kockázatos a számítási módszerem, tényleg nincs benne image ellenőrzés, de az gondolom lejött, ez nem az a cég, ahol most milliókat fogunk szánni egy csiricsáré megoldásra. Egész eddig is volt backupunk, nem a legjobb, tákolt, részleges mentés, és a visszaállításra elmentek néha napok, de túléltük valahogy, biztos csak szerencsénk volt. Érzésre tudjuk, hogy kb. milyen szintű rizikóra akarunk felkészülni, és erre kb. mennyit szánunk. Most annyit szeretnénk, hogy több adatot mentsünk, és hamarabb vissza szeretnénk belőle állni, evvel mondjuk évi 10 embernapnyi munkát spórolunk. Nem lesz tökéletes, nem lesz gyors, nem lesz sok kilences rendelkezésre állású, nem lesz távoli helyen, stb., ilyen az élet, ezt sajnálom is egyébként. Nem mondom, hogy kőbe van vésve a költségvetés, jó indokkal növelhető, de azért nagyon eltérni nem tudunk, nem fogunk. Elhiszem, hogy olyannak, akinek ez jobban szakmájába vág, annak ez siralmas is lehet akár, és az ilyen emberek biztonsági kritériumai szerint ez nem megbízható, de ezen a szinten, amiről én beszélek, egy nem túl megbízható storage-ra történő backup is végtelenszer megbízhatóbb, mintha egyáltalán nem lenne backup. Igenis számít, hogy a Windows Server Backup kéznél van, és rohadjon meg az MS, amiért távoli helyre nem tud inkrementálisan menteni. Ilyen peremfeltételek mellett kitartok amellett az állításom mellett, hogy valós alternatívát nem írt senki. Egyetlen konkrétumnak az iSCSI tűnik, és marhára vonzó az, hogy evvel menne az inkrementális mentés, de ez sem problémamentes, és ha teszem azt, nincs jó megoldás arra, hogy dirty adat mentesen tudjam konzisztensen snapshotolni az NTFS image-et, akkor sajnos nem ér semmit, márpedig a Windowsnál néha van olyan, hogy sorry, ezt nem lehet.

--
joco voltam szevasz

Tegyük fel, hogy nekiállok fájl szinten menteni Sambán keresztül Cobiannal például, vagy akár rsynccel. Így kevés adat megy át a hálón, ez világos. A túloldalon snapshotolgatok, és így lesz több napi backup, jó. De ezekből a fájlokból hogy állítasz vissza egy teljes Windowst, ha a legtöbb *nixos fájlrendszeren még a dosos attribútumokat se tudja megfeleltetni a Samba, nemhogy az NTFS ACL-jeit és egyéb egzotikus dolgait? Bárcsak így lenne, ha hinnék benne, már rég nem lenne miről beszélnünk. Értem én, hogy fájl szintű backuppal megoldható, hogy újrahúzzuk a szervert, aztán visszamásolgatjuk backupból az adatokat meg a configokat, egy *nix mentésnél simán ezt tenném én is, de itt most Windowsról beszélünk. Pont azt akarjuk elkerülni, hogy ne kelljen órákon át telepítgetni meg configokat visszamásolni, hanem rögtön a kész rendszert tudjuk visszatenni. Most őszintén, szerinted olyan jó ötlet lenne ezt fájl szinten csinálni? Lehet, hogy én tudok rosszul valamit, amihez nem értek, és akkor következetesen hülyeséget beszélek, de hogy nem logikusan gondolkodok, az nem kicsit túlzás.

--
joco voltam szevasz

Egy QNAP TS-419P-t lehet venni nettó 110-ért, és ez állítólag tud iSCSI-t, úgyhogy szerintem a mi keretünkből, a nettó 150-ből, elég jó kis doboz jön össze. Nálad is ez a soho NAS kategória? Én eleve ilyesmi eszközre gondoltam, erre zeller írja, hogy ennyi pénzből nem lesz megbízható, akkor légyszi beszéljétek meg egymás között, mert ebből tényleg nem jön le nekem, hogy mire gondoltok. Konkrét ár és típus nélkül könnyű dobálózni, hogy te hülye, vegyél olcsóbbat/te hülye, vegyél drágábbat, mikor melyik.

Btw olvastad a topic címét? Deduplikáció. Lesz vagy 30 terabájtnyi image-em, de a dedup miatt 3 terabájt helyet fog foglalni. Én szívesen beszélgetek, csak most nem tudom, miről beszélünk.

--
joco voltam szevasz

Van a mese a bácsiról a fiáról meg a szamárról, ahogy mennek a vásárra.
Olyan megoldást nem fogsz találni, ami mindenkinek jó lesz. Olyat keress, ami neked - a cégnek - megfelel. Úgyis neked kell vele vergődni. Kb. bármilyen megoldás ellen fel lehet hozni érveket, és épp így mellette is.

Te írtad, hogy számodra az iSCSI nem megnízható, mert mi van, ha összef0ssa magát a wendóz, és az fs-t összekuszálja? Csak halkan mondom, hogy a szamba meg nem lesz túl gyors...

Egyébként meg eb karóhoz kötését látom a részedről, úgyhogy részemről ennyi - csináld, ahogy és amivel akarod...

Vedd észre, hogy az alapkoncepcióddal (napi full image mentés) van baja itt a legtöbb hozzáértő(bb) kollégának.
Az inkrementális mentésre is adtunk megoldást (iSCSI), de akár helyi plusz diszk, amiről miután kész, mehet a másolás a storage-ra.
Ha attól parázol, hogy elhasal a szervered, és összekuszálja a fs-t az iSCSI eszközön _is_, akkor van egy qrva rossz hírem: a tárolótömbnek is hasonló esélye van összef0snia magát, és a teljes mentést összekuszálni.
De... Minden szerver kap kettő iSCSI LUN-t, egyik nap az egyiket, másik nap a másikat "veszi fel", és az inkrementális mentést páros/páratlan elven oda rakja, a hetedik napon a full mentést meg rakod, ahova akarod, akár egy közös megosztásra is - ahova a napi inkrementális mentés után átmásolod a mentés eredményét - azaz ott szépen meglesz a legutóbbi full plusz a hozzá tartozó inkrementális backup set. No?

Írtam fentebb is, hogy ez a megoldás tök jó, és köszönöm. Nem is kell két LUN, csak annyi kell, hogy mentés után snapshot kell a LUN-ról a remote oldalon, és akkor nem zavar, ha a kliens megöli a fájlrendszerét, mert az egész nyers iSCSI-n kiajánlott tárterületről van snapshot. Ehhez már csak összesen annyi hiányzik, hogy a Windowsnak meg tudjam mondani, hogy flusholja a dirty adatait, és konzisztens állapotban tudjak snapshotolni. Ha ezt megoldom, akkor ez lesz a megoldás. Nem is vitatom, ez tényleg nagyon jó. Ha ezt nem sikerül, akkor marad a (szerintem se jó, de a legkevésbé szar) full image-es módszer. Nem direkt szórakozásból akarok full image-et menteni, természetesen.

--
joco voltam szevasz

Nem, ez két backup set. Az egyik héten az "paros" könvvtárba tolod a mentést, a másik héten meg a "paratlan"-ba. Ha a kliens képes írni a legutóbbi mentést tartalmazó eszközre, akkor tönkre tudja tenni - akár fájlként, akár blokkonként történik az írás. Az olcsó eszközöddel blokdevice-ra tudsz inkrementális mentést csinálni, de onnan a "túloldalon" el tudod másolni az elkészült napi mentéseket a storage más területére, amit már nem tudsz hazavágni. (Ja, image esetén is agyon lehet vágni a korábbi fájlokat, ha csak ez fáj...)

A szamba/NFS jó játék, csak rohadt lassssssú lesz egy normális iSCSI-hoz képest. A szamba úgy NT4 körül még vállalható sebességet tudott, mostanára azért bőven van mit javulnia...

"Még nem próbáltam, de rémlik, hogy a Win 2008 R2/7-től kezdve a telepítő alapból tud visszaállítani"

Igen. Az install dvd bootolásakor kiválaszthatod, hogy visszaállítást, vagy telepítést szeretnél-e.
Visszaállításnál lehetőséged van samba share-t felcsatolni, vagy lokális (pl. usb) diszket megadni.
Iscsi-t nem.

"Ez pl. úgy mehetne, hogy a RAID tömbre csinálok N darab NTFS partíciót,"
Legegyszerűbb pl. linuxos LVM volume-ot kiajánlatni iscsi-n, amit a windows egy darab diszknek lát.
Az átméretezése megoldható, ha az lvm-et átméretezed. A windows ekkor a megnövelt diszket fogja látni. Azt nem tudom, hogy ha pl. oprendszer mentés tárolására használod, a rajta levő mentést ez hogyan befolyásolja. A tippem az, hogy nem lesz vele gond, de ez csak egy nem megalapozott tipp.

A dedupról sem feltétlen kell lemondani, ha zfs volume-ot használsz iscsi targetként.
Ezt is lehet dinamikusan növelni.
Más kérdés, hogy a freebsd alapú zfs jelenleg nem tud dedupot (de fixme, ha mégis.)

Itt most azt vetették fel kollégák, hogy használjam a Windowsban levő inkrementális mentést. Ehhez az kell, hogy a diszket a Windows lokálisnak látja. Továbbá NTFS fájlrendszernek kell rajta lennie. Tehát buktam a ZFS-t, az átméretezgetés megoldható de nem triviális, és a kliens gép simán tönkre tudja vágni a remote fájlrendszert is. Úgyhogy végső soron szerintem az iSCSI nem nyert.

--
joco voltam szevasz

"Továbbá NTFS fájlrendszernek kell rajta lennie. Tehát buktam a ZFS-t,"

Ha az iSCSI szerveren zfs volume-okat csinálsz, és ezeket kiajánlod iSCSI targetként a windowsnak, akkor a windows azt "nyers" diszkeknek fogja látni, és tehetsz rá ntfs-t.

Kb. minden iSCSI storage ilyen elven működik, vagyis a backenden az adattárolás formája lényegtelen a kliens szempontjából.

de ugyanez van virtualizáció esetén is. A windowsos image lakhat fájlban akármilyen fájlrendszeren, lvm köteten, vagy bármin. Az a windows számára csak egy diszk, amire ntfs kerül.

Még nem teljesen értem. A ZFS egy fájlrendszer, tehát fájlok vannak rajta. Az iSCSI-hoz nekem kell csinálni egy image fájlt a fájlrendszerre, amit kiajánlok, és ez lesz a nyers diszk a Windowsnak, vagy ez hogy megy? Érdekes a téma egyébként, csak semmivel nem visz előrébb, mert backup célra szerintem sokkal megbízhatóbb egy nem blokk szintű remote elérés.

--
joco voltam szevasz

Az iSCSI-hoz nekem kell csinálni egy image fájlt a fájlrendszerre, amit kiajánlok, és ez lesz a nyers diszk a Windowsnak, vagy ez hogy megy?

nem neked kell csinálnod, az image fájlt megcsinálja a rendszer. te csak közlöd, hogy egy dedikált x gb méretű block device-t kérek, és megkapod, aztán azt iscsi-n kiajánlhatod. a fájlrendszerben azt az image fájlt nem fogod látni, mert azt előled eldugja a rendszer.

"ég nem teljesen értem. A ZFS egy fájlrendszer, tehát fájlok vannak rajta"

Nem teljesen. Tudsz rajta volume-okat is csinálni.

"Az iSCSI-hoz nekem kell csinálni egy image fájlt a fájlrendszerre, amit kiajánlok, és ez lesz a nyers diszk a Windowsnak, vagy ez hogy megy? "

Nem fájl, hanem volume (mint pl. linuxban az LVM-nél). A többit jól látod.

"Érdekes a téma egyébként, csak semmivel nem visz előrébb, mert backup célra szerintem sokkal megbízhatóbb egy nem blokk szintű remote elérés."

Miért megbízhatóbb? A tárolóeszközön mindkét esetben felléphet blokkszintű korrupció (ami egyébként zfs-el elég jól kivédhető).
Egyébként zfs-re tudsz samba/cifs megosztást is csinálni, ebben az esetben is lehet deduplikációd, viszont az inkrementális mentés lehetőségét bukod.

Ha magában a zfs-ben nem bízol, az teljesen más téma.

A ZFS-ben bízok. SAMBA/NFS esetében a backup akkor megy tönkre, ha meghal a backup szerver. iSCSI esetében a backup akkor megy tönkre, ha meghal a backup szerver VAGY meghal a kliens szerver és tönkrevágja az egész fájlrendszert.

A Windows inkrementális mentésében az a nagyon jó (tudtommal), hogy Volume Shadow Copy alapú. Tehát nem kell végig checksumolnia az összes használatban levő blokkot a diszken ahhoz, hogy tudja, mi változott, hanem alapból tudja, mi változott, és csak azt viszi át.

Tehát két lehetőségem van. iSCSI, inkrementális mentés, de kockázatos. Vagy SAMBA/NFS, full mentés, de evvel minden nap végig lesz olvasva az összes blokk a diszkről, és át is lesz tolva hálózaton, és csak a backup szerveren a dedup miatt nem fog kiíródni.

Vagy lehet, hogy van itt egy 3. megoldás. iSCSI, inkrementális mentés, és minden nap a mentés után snapshotolok a backup szerver ZFS-én. Ha egy fájlrendszer megdöglik, nem baj, ott a tegnapi snapshot. Jól látom, hogy ez működhet? Annyi a kérdés, hogy a Windowsokat rá tudom-e venni, hogy a snapshot idején egy konzisztens állapot legyen az iSCSI eszközön.

--
joco voltam szevasz

"SAMBA/NFS esetében a backup akkor megy tönkre, ha meghal a backup szerver. iSCSI esetében a backup akkor megy tönkre, ha meghal a backup szerver VAGY meghal a kliens szerver és tönkrevágja az egész fájlrendszert."

Nem egészen értem a logikádat, de javíts ki.
TEhát "meghal a kliens szerver" alatt mondjuk azt értjük, hogy a kliens pl. tol egy "rm -rf"-et a backuőnak felcsatolt volumeon?
Mert ha igen, akkor tök mindegy, hogy iscsi-n keresztül vagy egy blokkeszközöd felcsatolva, melyet lokális lemeznek lát a windows, vagy samba/nfs-en keresztül van egy megosztás felcsatolva, mindkettőt akár kompletten le is tudja törölni a g*cibe a kliensen mondjuk egy elkurodott trójai.

Ebből adódóan goto normális backup szoftver, aminek a kliense kommunikál a mentőeszközzel, OS-szinten nem látszik a mentett adat - igaz visszaállni általában egy üres OS+backup agent kell, de ez bele szokott férni (elég gyoran tolják vissza az adatokat a normálisabb szoftverek...)

Mit nem értesz? Pont nemrég volt, hogy az egyik géppel valami történt, áramingadozás, kékhalál, háttérsugárzás, akármi, de minden fájlrendszer, amin dirty adat volt, az meghalt. Nem egy tipikus esemény NTFS-ek esetén, de előfordul. Ha elmeséled nekem, hogy NFS-en keresztül hogy teszel tönkre egy fájlrendszert, kíváncsian várom. Nem vagyok hülye, fájl szinten le lehet törölni és tönkre lehet tenni mindent, de fájlrendszer szinten csak az iSCSI-n. Vicces ezt olvasni azok után, hogy fentebb meg pont abba kötöttek bele, hogy jaj de nem biztonságos módszert találtam ki és szégyelljem magam.

--
joco voltam szevasz

mert a felcsatolt nfs-t nem lehet letörölni távolról, mi? mert az nfs pont arról híres, hogy mennyire precízen lehet az acl-eket meg permissionokat állítgatni.
én a logikádat nem értettem, ezért írtam, hogy blablabla... olvasd el megint, ha érdekel, s előbb értelmezz.

amit kitaláltál, az meg no comment, de te idejöttél véleményt kérni, többen is mondtunk jópár olyan ötletet, amit esetleg évek óta bevált szinten használunk, de te csak a hülyeségedet tolod továbbra is, s meg vagy sértődve, hogy megmondjuk őszintén, hogy hülyeség a koncepciód.

most felmerül a kérdés, hogy akkor mi a francnak kérdezel, ha utána minden válaszba csak belekötsz, meg mindenki hülye, csak te vagy a helikopter?

Oké, sok mindenben igazad van. A félreértés ott kezdődött, hogy én csak a vasról kérdeztem, a mentés mibenlétéről nem, ezek után jogosan vettem kötekedésnek, hogy mindenáron olyan dologról akartok meggyőzni, amit én nem is kérdeztem, nem is voltam képben annyira, hogy egyáltalán erről okosat kérdezzek. Nyilván ezért kérdeztem vissza mélyebben, mert a félmondatokból semmit nem értettem, de nem kötekedő szándékkal, mert egy pillanatig sem titkoltam, hogy sose láttam még iSCSI-t, de érdekelt, hogy meg lehet-e oldani konkrétan ezt, amellett, hogy sok mindenre nagyon jó az iSCSI. Most már, hogy tudom, hogy ez a Windowsban helyi diszk lesz, és hogy hogyan működik, ezért örömmel jelentem, hogy meggyőztetek, legalább ennek nem fogok még egy fórumtémát indítani. Úgyhogy végülis köszi az ötletet, kötekedjünk máskor is. Image mentés lesz, iSCSI-ra, inkrementális, backup szerveren snapshotolgatva a biztonság kedvéért. Tudom, egyszerre kellett volna kérdezni a vasat és a módszert, de a módszer eléggé kőbe volt vésve már előttem is, és mint látjuk, nagyjából marad is így.

Azt is tudom, hogy *nix-ot tuti fájl alapon mentenék, és egy *nix-hoz szokott embernek égnek állhat a haja az image-től, illetve nagyon nagy odafigyeléssel Windowst is lehetne úgy menteni, de itt most nálunk a mi peremfeltételeinkkel ez lesz az optimum. Ha valaki még mindig le akar beszélni az image-ről, az tegye, én nem zárkózok el és végig fogom olvasni, de a válaszom lehet, hogy kötekedő lesz. És igenis hangoztak el más részéről is hülyeségek, azokra meg egész egyértelmű, hogy védem az álláspontom. Tévedés: előbb windowst kell installállni, és csak utána mehet a restore, pedig valójában alapból mehet a restore. Tévedés: tegyek Windows Server Backuppal full mentést X tárhelyre és inkrementálist Y-ra, pedig ezt ez a szoftver nem tudja. Tévedés: ennyi pénzből szar és megbízhatatlan vas fog kijönni, pedig valójában még egy kicsit olcsóbb vassal is végtelenszer jobb, mintha egyáltalán nem lenne backup. Tévedés: szarjam le, hogy az iSCSI sebezhetőbb a fájlrendszer megölhetősége miatt az NFS-nél, pedig valójában arról van szó, hogy van egy csomó rizikófaktor, némelyikről úgy döntünk, hogy együtt élünk velük, mert túl nehéz lenne kivédeni, de másokról meg, amiket a peremfeltételekhez képest komolyabb erőfeszítés nélkül kivédhetünk, azt igenis védjük ki. Persze hogy NFS-t, iSCSI-t, bármit le lehet törölni, ebből a szempontból egálban vannak, de ettől még az is igaz, hogy az iSCSI-nak van plusz egy rizikója, amit említettem, és kell is, lehet is, fogunk is ellene védekezni a snapshottal. A lényeg, hogy én sokat tanultam, remélem más is.

--
joco voltam szevasz

( Fisher v | 2011. 07. 05., k – 09:39 )

Kicsit off, elnézést is kérek érte, de talán itt is érdemes felvetni: mennyire megbízható egy FreeNAS + zfs(?) dedup? Esetleg tömörítéssel együtt? Mert őszintén szólva én még mentést se mertem rátenni még zfs-re.

( fimikz | 2011. 07. 05., k – 15:05 )

az en home NAS-om kb pont az, amit te elmondtal, es netto 155-bol jott ki. van benne egy chenbro haz[1], egy supermicro X7SPA-h deszka[2], 4G memoria, 4x1T WD green diszk (alacsony fogyasztas), es 2x250G sysdiszk. olyan 40-60MB/s korul forgalmaz gigas halon soho switchekkel, ZFS van a 4db 1T-s diszken, es fbsd 8.2-STABLE -ben mar van dedup is. uh gyakorlatilag a kornyezetben minden adott, ami neked kell. egyebkent ha kell nagyker, asbis-nal mindent megkapsz egy hasonlo cucc megepitesehez.

szerintem egy ilyen kis csoda tokeletesen megfelel a celjaidnak. nekem homeserver, HD filmeket nezunk rola, es neha toltogetek is le ra. panasz meg nem volt ra.

[1] http://www.chenbro.com/corporatesite/products_detail.php?sku=167
[2] http://www.supermicro.com/products/motherboard/ATOM/ICH9/X7SPA.cfm?typ=H

Jeee... akkor majdnem ugyan az mint amit en irtam, csak en Brazos-szal meg 4x2T-vel szamoltam, meg egy egesz jo RAID vezerlovel... :P allitom, az enyemet is ki tudnam hozni olcsobbra de az elso bolt arlistajabol neztem a dolgokat ami a "kezembe akadt" :D Bele kell meg vagni egy/ket SSD-t meg oszt' jovan, es meg boven a 200k-s hatar alatt vagyunk egy nagyobb Chenbro hazzal.

( handler | 2011. 07. 05., k – 20:46 )

Miert nem probalod ki az egyszerubb, de potencialis otleteket kb 1/10-re skalazott adatmennyiseggel, valamelyik elfekvo gepen? Persze csak ovatosan, lesznek meglepetesek...