2010/2/7 Petru Ratiu <rpe...@gmail.com> > 2010/2/7 Valentin Cozma <vco...@elfyard.com>: > > 2010/2/7 Dragos Chiriac <dra...@secured.ro>: > >> > >> Si ca sa nu se lase cu injuraturi data viitoare cand > > mai vedem, nu mai recomanda raid ca backup ca n-are nici o legatura > > (si ce zici tu e o reteta sigura sa-ti scurtezi timpul pana cand vei > > avea nevoie de backupul ala). > > > > > > Poti sa explici asta in argumente simple , sa le inteleaga si novicii ca > > mine ? > > 1. "raid != backup" inseamna ca raid te apara doar de cazurile in > care-ti crapa vreunul din discurile fizice de sub el (raid0 nu intra > in discutie), nu si de chestiile care se fac direct pe array, fie prin > filesystem, fie pe block device-ul matricii. > > 2. resincronizarea unui array e o operatiune f. costisitoare atat ca > i/o bandwidth cat si, se spune, ca scurtare a timpului de viata al > discurilor. Explicatia e ca la resincronizare, se face o citire > secventiala a intregii matrici, ceea ce sugruma foarte tare orice alte > operatii de i/o cu discurile alea. Intelepciunea populara zice ca daca > "freci" foarte tare un disc (a se citi i/o sustinut) risti sa-l uzezi > mai tare.Celebrul PDF de la Google cu hard drive reliability a gasit > corelarea asta doar la discurile "tinere", insa am auzit o serie de > repoarte mai rcente care exprima ingrijorarea privind folosirea de > discuri foarte mari in raid-uri, intrucat creste considerabil riscul > ca in timpul resincronizarii cauzate de inlocuirea unui disc defect, > sa-ti crape altul si sa te lase cu ochii in soare. > > In orice caz, sunt foarte ferm convins ca resincronizarea unei matrici > raid trebuie sa ramana un eveniment exceptional si sa nu devina > operatie regulata. Povestile cu poduri de cale ferata le las pt. la > bere :) > > -- > Petre "don't thread on me" Ratiu > _______________________________________________ > RLUG mailing list > RLUG@lists.lug.ro > http://lists.lug.ro/mailman/listinfo/rlug >
Sa va spun toata povestea, acum ca am recuperat destule si sunt mai calm Era o masina XenServer 5.5.0 cu storage-ul (din lipsa de fonduri) pe discurile locale. Discurile locale erau 2x500GB Seagate puse in raid 1 software. Aici incepe partea pentru care imi vine sa imi trag palme: 1. Nu am verificat daca cele 2 discuri se sincronizau intre ele 2. ca urmare toate datele s-au scris pe un singur disc (cel care a crapat), celalalt ramanand cu datele de la instalare. /boot-ul era pe flash, iar ROOT-ul era pe /dev/md1 (pentru a evita ca swap-ul sa fie pe flash). Acum o sa mut tot ROOT-ul pe flash, mai putin fisierul de SWAP mai exista un /dev/md2 nefolosit si egal ca marime cu /dev/md1 iar /dev/md3 continea ISO repository si VM repository Am recuperat ROOT-ul si discurile virtuale (unele imposibil de folosit, dar altele utilizabile) Situatia curenta sta in felul urmator: nu am /proc/mdstat, deci in continuare nu se face sincronizarea discurilor. Aici as vrea putin ajutor, daca se poate ... Cat priveste back-up-ul, ma gandesc la snapshot-uri la masinile virtuale. De asemenea ceva sistem de back-up-ul va trebui sa fie si pentru celelalte servere fizice (windows sau linux). Nu stiu daca va fi aceeasi solutie pentru ambele situatii, dar macar pentru masinile virtuale pentru inceput. _______________________________________________ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
