Iulian Roman <iulian.ro...@gmail.com> wrote:
> 
> > Păi nu ziceai că ce simplu e cu mksysb și că ce păcat că în Linux nu
> > avem așa ceva? Să nu-mi zici că la sute/mii de mașini în rețea tu cu
> > mksysb voiai să faci backup… Dacă nu știe nici măcar backup
> > incremental, nu este scula potrivită.
> > 
> 
> daca ai fi citit cu atentie thread-ul ai fi observat ca am mentionat
> ca folosesc tsm ca si client de backup. pe toate systemele.
> incremental. si solutia ma intereseaza exclusiv pentru rootvg. tu
> vrei sa imi spui ca folosesti numai rsync pentru backup ?si insisti
> ca e scula potrivita ?si insisti ca e scalabila la sute/mii de
> masini ?

Ți-am dat exemplu rsync ca un echivalent superior pentru mksysb, dar
nu, nu aș folosi rsync pentru scenariul pe care l-ai creionat tu. Cu
atât mai puțin mksysb, care nu știe nici măcar de backup incremental.
Chiar și numai pentru rootvg, tot e muuult prea mult să copiezi toate
rootvg-urile prin rețea la fiecare backup.

[snip]

> > mksysb, HMC, NIM server șamd or fi simple pentru tine și le
> > configurezi într-un minut pentru că ani de zile ai lucrat cu ele.
> > Mie, ca începător într-ale AIX-ului, mksysb mi se pare primitiv,
> > HMC abia îl deslușesc după săptămâni de interacționat cu interfața
> > lui stupidă, iar NIM server este o nebuloasă.
> 
> sunt sigur ca ai sa intelegi utilitatea lui cind o sa il folosesti
> mai des. hmc are ca system de operare Linux, asa ca ai echivalent
> comand line la toate functiile gui. da, Nim are o oarecare curba de
> invatare si poate parea o nebuloasa la inceput.

Apropo de HMC, n-am zis că nu-i util, e chiar o sculă deșteaptă, de
interfața lui am zis ca e stupidă. Chiar dacă rulează pe Linux, io din
Linux nu pot manipula pe de-a întregul interfața web decât dacă-mi
instalez un Firefox antic, nicio versiune la zi nu are suport de la IBM
și chiar îs chestii care nu funcționează în Firefox 24 ESR, care-i cea
mai veche versiune Firefox cu suport de la Mozilla.

 
> > Dar, să proclami că mksysb este ce trebuie pentru a
> > face backup decent la sute/mii de mașini în producție, pe care să le
> > poți restaura cât mai rapid, mi se pare exagerat în condițiile în
> > care e o sculă foarte limitată pentru că:
> > 
> nu e exagerata.
> >  1. nu știe backup incremental
> nu asta e scopul

La rootvg tot cu mksysb insiști că ai face backup. Dacă ai veni la mine
cu soluția asta, nu ți-aș accepta-o. O dată pentru traficul de rețea
inutil dat de lipsa suportului pentru backup incremental. Încă o dată
pentru frecatul discurilor degeaba, că de fiecare dată ai scrie tot ce
e în rootvg. Și încă o dată pentru spațiul masiv pe care l-ar ocupa
multiple salvări, pentru cazul în care s-ar dori restaurări din imagini
mai vechi.


> >  2. nu poate face backup la tot ce-i pe mașină
> nu asta e scopul
> >  3. e recomandat să-l faci doar când mașina nu-i în producție
> >  (deci peste noapte?).
> 
> complet gresit

Mno, aici mi s-o dat bullshit-metrul peste cap. Pentru că în manualul
mksysb scrie clar:

       Note:
       1    While the mksysb command is running, ensure that system
       activity is minimal.

De ziceai ceva de genul „da, dar…” sau alte variante, mai puteam să
înghit. Dar, să proclami că prima notă din manualul mksysb este complet
greșită, e prea mult. Extraordinary claims require extraordinary proofs.

Respectând indicațiile IBM din manual pentru mksyb înseamnă că ar fi
nevoie de o fereastră de backup pentru salvarea rootvg-urile și, prin
urmare, va rezulta o granularitate mare pentru salvări, pentru că, cât
de des ai o fereastră de backup la mașini în producție? O dată pe zi,
adică peste noapte? Deci la fiecare restaurare se pierd datele de până
la o zi de pe acea mașină. Se poate mai bine de atât…

Attachment: signature.asc
Description: PGP signature

_______________________________________________
RLUG mailing list
RLUG@lists.lug.ro
http://lists.lug.ro/mailman/listinfo/rlug

Raspunde prin e-mail lui