Re: [rlug] Solutii BACK-UP
Quoting Radu Zoran radu.zo...@r2dev.ro: Pe 06.02.2010 16:09, Mircea Popescu a scris: A mai lucrat cineva cu vreunele dintre aceste solutii sau poate cu altele si imi poate recomanda ceva? Eu am folosit backuppc acum vreo 4-5 ani si am fost destul de multumit de el. Il adaptasem un pic, ii bagasem si ceva facilitati de cautare si interfata in romana (care nu stiu daca a ajuns in distributia finala). Stie sa trimita mail, si are (si) o interfata www suficient de simpla si pt. utilizatori non-tehnici. Mi-a mai placut ca stia sa faca singur backup de pe un calculator in momentul in care il detecta in retea (util pt. laptop-uri). Minusuri, din punctul meu de vedere, avea pe la cautarea de fisiere si la exportul de arhive (functionale, dar cu cateva mici probleme, aici a trebuit sa-l coafez eu putin). FWIW, e scris in perl si tine datele intr-o structura specifica (compresia mi se pare ca e optionala, dar si fara ea nu e trivial sa recuperezi fisiere 'de mana' daca moare daemon-ul, din cate imi aduc aminte) Da, confirm si eu, ca backuppc e o scula f. faina, si m-a scos dintr-un kk mare de tot acu un an. Il am in lucru cam de 3 ani. Face back-up la win/linux, prin cifs, rsync(complet/incremental), la un anume fisier la care ai mai multe backup-ri din urma, iti arata si versiuni(ai 7 backup-ri si iti arata ca de fapt sunt numai 2 versiuni diferite), foarte eficient la spatiu de stocare(face hardlink-ri daca ai acelasi fisier in mai multe backup-ri), poate sa faca si CD-ri/DVD-ri cu/fara paritate(via par2). Poti restaura ceva exact in sursa respectiva, local, arhivat(zip/tgz). Tot in thread-ul asta zicea careva si de consitenta datelor - asa ca poate te gandesti si la snapshot pe LVM. Am cateva masini la care fac snapshot via LVM si apoi backup prin backuppc/rsync cu limitare de banda in rsync, ca sa nu omor resursele. ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug -- English Version: This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. Versiunea Romana: Mesajul a fost scanat de MailScanner si este considerat a fi neinfectat. This message was sent using IMP, the Internet Messaging Program. pgp7auHV9vGsm.pgp Description: PGP Digital Signature ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Solutii BACK-UP
Quoting Alex 'CAVE' Cernat c...@cernat.ro: Da, confirm si eu, ca backuppc e o scula f. faina, si m-a scos dintr-un kk mare de tot acu un an. Il am in lucru cam de 3 ani. Face back-up la win/linux, prin cifs, rsync(complet/incremental), la un anume fisier la care ai mai multe backup-ri din urma, iti arata si versiuni(ai 7 backup-ri si iti arata ca de fapt sunt numai 2 versiuni diferite), foarte eficient la spatiu de stocare(face hardlink-ri daca ai acelasi fisier in mai multe backup-ri), poate sa faca si CD-ri/DVD-ri cu/fara paritate(via par2). Poti restaura ceva exact in sursa respectiva, local, arhivat(zip/tgz). Tot in thread-ul asta zicea careva si de consitenta datelor - asa ca poate te gandesti si la snapshot pe LVM. Am cateva masini la care fac snapshot via LVM si apoi backup prin backuppc/rsync cu limitare de banda in rsync, ca sa nu omor resursele. M-am uitat si eu si pare interesant. Intrebarea pe care o am este: functioneaza numai in modul push (adica serverul de backup trage de pe clienti) sau poate si pull (client pe client care exporta backup-ul pe server). Alex Din cate stiu eu numai push. Dar cred ca ai putea face si pull. De pe client sa executi o comanda pe host-ul cu backuppc(o montare sshfs de exemplu a datelor clientului?). This message was sent using IMP, the Internet Messaging Program. pgpbgqgheVNDa.pgp Description: PGP Digital Signature ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Solutii BACK-UP
On Sun,07.Feb.10, 13:32:41, Valentin Cozma wrote: 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 ? http://www.taobackup.com/ Salutări, Andrei -- http://yetanotherpersonal.blogspot.com/2009/09/neticheta-in-vremurile-noastre.html signature.asc Description: Digital signature ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Solutii BACK-UP
On Sun, 2010-02-07 at 03:02 +0200, Dragos Chiriac wrote: Sa-ti spun sincer, poti sa faci un raid 1 software pe 2 stabile + 1 usb, ca tot era treaba, si hardu pe usb sa-l bagi in raid cand trebe, astepti sa se sync, apoi il notezi ca faulty si pleci cu el. Eu practic asta, mai ales ca poti sa butezi de pe usb-ul ala cand ai chef. Depinde ce ai si ce vrei. Ca asa, la modu general, tivoli ruleaza:). Cred ca tu faci o confuzie cind ajungi la notiunea de backup :) ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Solutii BACK-UP
In termeni seriosi de data asta. Personal nu am pus mana decat pe amanda, bacula (oss) si tivoli (proprietar). Amanda mi se pare mai usor de invatat/folosit. Ambele au o curba de invatare destul de abrupta, iti ia ceva pana le intelegi pe bune. Daca vrei sa foloseti sistemul de backup ca scula de disaster recovery, trebuie sa inveti chiar si mai multe. (E diferenta intre backup si disaster recovery). E recomandabil sa separi pe partitii diferite sistemul de operare si datele ce trebuie recuperate. Pentru sistemul de operare e mai simplu sa foloseti ceva gen Mondo/Mindi. Dupa ce ai pus sistemul de backup joaca-te de-a recuperarea bine de tot. Repet, sistemele de backup nu sunt chiar intuitive. In plus depinde foarte mult ce vrei sa recupererezi. Pentru baze de date e recomandabil sa ai (si) replicare. Pentru cod sursa, carti, chestii cu schimbari mici dpdv binar de la o versiune la alta e mai simplu sa solosesti un VS (cvs, svn, git). Daca vrei sa faci imagini de pe chestii care sunt in continua modificare (baze de date stresate, de ex), e recomandbil sa inveti ce e ala LVM snapshot. Dragos Vali Dragnuta wrote: On Sun, 2010-02-07 at 03:02 +0200, Dragos Chiriac wrote: Sa-ti spun sincer, poti sa faci un raid 1 software pe 2 stabile + 1 usb, ca tot era treaba, si hardu pe usb sa-l bagi in raid cand trebe, astepti sa se sync, apoi il notezi ca faulty si pleci cu el. Eu practic asta, mai ales ca poti sa butezi de pe usb-ul ala cand ai chef. Depinde ce ai si ce vrei. Ca asa, la modu general, tivoli ruleaza:). Cred ca tu faci o confuzie cind ajungi la notiunea de backup :) Nu fac confuzie. Era un fel de gluma. Avea mai mult haz azi noapte la 3 :). ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Solutii BACK-UP
On 02/07/2010 12:55 PM, Dragos Chiriac wrote: E recomandabil sa separi pe partitii diferite sistemul de operare si datele ce trebuie recuperate. Pentru sistemul de operare e mai simplu sa foloseti ceva gen Mondo/Mindi. Sau - pe partea de servere - daca ai suficiente, masini virtuale (ma refer la solutii de gen vmware esxi + solutie de storage fc redundanta de la cap la coada, nu workstation) + snapshot-uri. Avantajul e ca daca-ti pica scula fizica clicka clicka si pornesti masina pe alta scula fizica (asta daca nu vrei sa cumperi partea de migrare automata), fara sa te stresezi ca nu booteaza, trebe alte drivere, muta hdd-urile etc. -- Dan Borlovan Datagroup-Int ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Solutii BACK-UP
2010/2/7 Dan Borlovan d...@level7.ro On 02/07/2010 12:55 PM, Dragos Chiriac wrote: E recomandabil sa separi pe partitii diferite sistemul de operare si datele ce trebuie recuperate. Pentru sistemul de operare e mai simplu sa foloseti ceva gen Mondo/Mindi. Sau - pe partea de servere - daca ai suficiente, masini virtuale (ma refer la solutii de gen vmware esxi + solutie de storage fc redundanta de la cap la coada, nu workstation) + snapshot-uri. Avantajul e ca daca-ti pica scula fizica clicka clicka si pornesti masina pe alta scula fizica (asta daca nu vrei sa cumperi partea de migrare automata), fara sa te stresezi ca nu booteaza, trebe alte drivere, muta hdd-urile etc. Pai in cazul in care are SAN storage ( si ma indoiesc ca are SAN daca oamenii nu au nici macar o solutie de backup acolo) nu mai are nevoie de nici o virtualizare si nici un ESXi. Si in nici un caz SAN-ul nu este o solutie de backup. Backup inseamna mai mult decit RAID. Pina la urma , omul vrea un amarit de software de backup (foarte probabil ceva free) si in schimb i se ofera solutii de zeci de mii de euro. -- Dan Borlovan Datagroup-Int ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Solutii BACK-UP
2010/2/7 Dragos Chiriac dra...@secured.ro: Amanda mi se pare mai usor de invatat/folosit. Ambele au o curba de invatare destul de abrupta, iti ia ceva pana le intelegi pe bune. Daca vrei sa foloseti sistemul de backup ca scula de disaster recovery, trebuie sa inveti chiar si mai multe. (E diferenta intre backup si disaster recovery). Chestia asta mi-a adus aminte de citatul urmator: Everyone hates backups. They are inconvenient. They are costly. Services run slower—or not at all—when servers are being backed up. On the other hand, customers love restores. Restores are why SAs perform backups. [...] Although the goal is to be able to restore lost data in a timely manner, it is easy to get caught up in the daily operational work of doing backups and to forget that restoration is the goal. As evidence, the collective name typically used for all the equipment and software related to this process is “backup system.” It should really be called “backup and restore systems” or, possibly more fittingly, simply the “data restoration system.” (Limonceli, Hogan Chalup - The Practice of System and Network Administration, 2nd ed. - pg. 619) Ce vreau sa zic e ca e usor sa uiti ca scopul nr. 1 al unui sistem de backup e sa recuperezi _repede_ datele de acolo. PS: Omul n-a pomenit de DR, hai sa nu ne mai laudam ce cuvinte complicate stim. 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). -- Petre don't thread on me Ratiu ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Solutii BACK-UP
2010/2/7 Petru Ratiu rpe...@gmail.com 2010/2/7 Dragos Chiriac dra...@secured.ro: Amanda mi se pare mai usor de invatat/folosit. Ambele au o curba de invatare destul de abrupta, iti ia ceva pana le intelegi pe bune. Daca vrei sa foloseti sistemul de backup ca scula de disaster recovery, trebuie sa inveti chiar si mai multe. (E diferenta intre backup si disaster recovery). Chestia asta mi-a adus aminte de citatul urmator: Everyone hates backups. They are inconvenient. They are costly. Services run slower—or not at all—when servers are being backed up. On the other hand, customers love restores. Restores are why SAs perform backups. [...] Although the goal is to be able to restore lost data in a timely manner, it is easy to get caught up in the daily operational work of doing backups and to forget that restoration is the goal. As evidence, the collective name typically used for all the equipment and software related to this process is “backup system.” It should really be called “backup and restore systems” or, possibly more fittingly, simply the “data restoration system.” (Limonceli, Hogan Chalup - The Practice of System and Network Administration, 2nd ed. - pg. 619) Ce vreau sa zic e ca e usor sa uiti ca scopul nr. 1 al unui sistem de backup e sa recuperezi _repede_ datele de acolo. Corect ! Si sunt extrem de putini cei care fac un plan de backup gindindu-se si la restore. Pentru ca daca ei in calcul restore-ul, deja costurile cresc ametitor (numar de tape-uri, timp de restore, numar de drive-uri in tape library, backup al tape-urilor, DR, etc). PS: Omul n-a pomenit de DR, hai sa nu ne mai laudam ce cuvinte complicate stim. 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). -- Petre don't thread on me Ratiu ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Solutii BACK-UP
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 ? mersi ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Solutii BACK-UP
Valentin Cozma wrote: 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 ? Pai omu tot cu un raid1 a pierdut datele. E doar o chestiune de timp pana faci ceva gresit si busesti ceva pe acolo. ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Solutii BACK-UP
Dan Borlovan wrote: On 02/07/2010 12:55 PM, Dragos Chiriac wrote: E recomandabil sa separi pe partitii diferite sistemul de operare si datele ce trebuie recuperate. Pentru sistemul de operare e mai simplu sa foloseti ceva gen Mondo/Mindi. Sau - pe partea de servere - daca ai suficiente, masini virtuale (ma refer la solutii de gen vmware esxi + solutie de storage fc redundanta de la cap la coada, nu workstation) + snapshot-uri. Avantajul e ca daca-ti pica scula fizica clicka clicka si pornesti masina pe alta scula fizica (asta daca nu vrei sa cumperi partea de migrare automata), fara sa te stresezi ca nu booteaza, trebe alte drivere, muta hdd-urile etc. Pai asa mai bine da bani lu' amazon ec2. Ca ma indoiesc ca are bani omu sa-si ia solutie de storage fc redundanta . ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Solutii BACK-UP
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 ? oricind poti pierde mai mult de un disk dintr-un array RAID si atunci ai pierdut toate datele. P.S Pentru RAID6 poti pierde mai mult de doua. mersi ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Solutii BACK-UP
Dragos Chiriac wrote: Valentin Cozma wrote: 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 ? Pai omu tot cu un raid1 a pierdut datele. E doar o chestiune de timp pana faci ceva gresit si busesti ceva pe acolo. Din ce am inteles eu era vb de o solutie 2 (permanente) + 1 (periodic) . hdd-ul usb se presupune ca nu se strica daca sta degeaba intr-un sertar in perioada dintre sincronizari. gresesc ? ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Solutii BACK-UP
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
Re: [rlug] Solutii BACK-UP
mersi, m-ai edificat ! ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Solutii BACK-UP
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
Re: [rlug] Solutii BACK-UP
Din ce am inteles eu era vb de o solutie 2 (permanente) + 1 (periodic) . 1. O alta copie (unica) nu te protejeaza de scenariul in care gigel de la contabilitate te suna si-ti spuna ca nu-si mai gaseste fisierul X pentru ca are impresia ca l-a sters acu' 3 saptamini. 2.Backup inseamna si o politica coerenta care sa-ti asigure si viteza de realizare a backupului, si viteza de restaurare precum si un numar decent de undo levels + o anumita granularitate la restore (nu vreau sa restaurez tot, doar anumite fisiere pe care le-am stricat din greseala spre ex ). Un alt mirror sincronizat din cind in cind nu ajuta la cele de mai sus. 3. Un resync de mirror e costisitor, ca inseamna o copie totala a unui volum - spre deosebire de un backup incremental care salveaza in loc de citeva sute de giga doar citiva zeci de mega cu fisierele schimbate. 4. Un resync de raid1 de 750G poate dura si peste 24h online (serverul inca online indeplinindu-si treaba in mod normal). Si asta pe sata-sata. Ma astept ca pe usb sa fie mult mai lent, si afara de asta sa genereze si wait times destul de seriosi pe sistem. Asta inseamna ca este EXTREM de lent si EXTREM de solicitant pentru toate discurile, ajutind la scurtarea timpului lor de viata. ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Solutii BACK-UP
2010/2/7 Vali Dragnuta vali.dragn...@inode.ro: Din ce am inteles eu era vb de o solutie 2 (permanente) + 1 (periodic) . 1. O alta copie (unica) nu te protejeaza de scenariul in care gigel de la contabilitate te suna si-ti spuna ca nu-si mai gaseste fisierul X pentru ca are impresia ca l-a sters acu' 3 saptamini. Noi la un moment dat am anuntat userii ca se face backup. La vreo saptamana au inceput sa vina oameni sa le restauram diverse chestii ca le-au sters din greseala, si ca tot e backup sa-i ajutam si pe ei. Dupa o perioada am renuntat la backup, am anuntat oamenii ca daca mai sterg chestii o fac pe barba lor. Surprinzator, au devenit mai atenti cand lucreaza cu chestii pe fileserver. Eu personal nu cred ca backupul trebuie sa rezolve prostia utilizatorilor, ci sa protejeze atunci cand pica sistemul fizic si trebuie eventual restaurat pe o alta masina. 2.Backup inseamna si o politica coerenta care sa-ti asigure si viteza de realizare a backupului, si viteza de restaurare precum si un numar decent de undo levels + o anumita granularitate la restore (nu vreau sa restaurez tot, doar anumite fisiere pe care le-am stricat din greseala spre ex ). Un alt mirror sincronizat din cind in cind nu ajuta la cele de mai sus. Faci unul mare si lat pe saptamana sau pe zi si tii cateva copii in urma. Bine, acu depinde si ce obiective ai la backup. 3. Un resync de mirror e costisitor, ca inseamna o copie totala a unui volum - spre deosebire de un backup incremental care salveaza in loc de citeva sute de giga doar citiva zeci de mega cu fisierele schimbate. Eh, d'aia e bine sa ai chestii gen RAID5/6, sa nu faci resync numai dupa un disc sa-l futizezi la greu. 4. Un resync de raid1 de 750G poate dura si peste 24h online (serverul inca online indeplinindu-si treaba in mod normal). Si asta pe sata-sata. Ma astept ca pe usb sa fie mult mai lent, si afara de asta sa genereze si wait times destul de seriosi pe sistem. Asta inseamna ca este EXTREM de lent si EXTREM de solicitant pentru toate discurile, ajutind la scurtarea timpului lor de viata. ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Solutii BACK-UP
2010/2/7 Eugeniu Patrascu eu...@imacandi.net: Eh, d'aia e bine sa ai chestii gen RAID5/6, sa nu faci resync numai dupa un disc sa-l futizezi la greu. La RAID5 futizezi _toate_ hard-discurile (adica bitii care se restaureaza pe 1 disc se compun din chunkurile echivalente de pe toate celelalte N-1). La RAID6 nu stiu f. sigur care e schema de calcul a paritatii, dar la redundanta de 2 discuri, ma astept sa munceasca pentru un anumit chunk doar N-2 din celelalte N-1, asa ca un disc oarecare nu mai e citit 100%, ci doar (N-2)/(N-1) * 100%, ceea ce inseamna 75% pt. array de 5 discuri si din ce in ce mai mult pt. mai multe. In orice caz, schema propusa (cu un disc in storage) te lasa fara array degradat cam tot timpul, cu exceptia raid1 (unde ai 50% citiri pe cele 2 discurile permanente si 100% scrieri pe ala pieton). -- Petre don't thread on me Ratiu ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Solutii BACK-UP
2010/2/7 Mircea Popescu popescu.mir...@gmail.com: 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. Vezi ca mai toate distributiile vin cu un cron script care da mail daca prinde md-urile degradate, incearca sa activezi chestia asta sa te traga de maneca data viitoare. 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 ... Asta nu prea inteleg. /proc/mdstat apare imediat ce e modulul md incarcat. Ori device-urile alea /dev/mdX nu sunt ce par a fi (ls -l /dev/md0 trebuie sa zica major 9, minor 0), ori te uiti in alta parte (/proc-ul masinii fizice), ori e altceva voodoo aici care imi scapa. 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). Vezi ca si asta e cu cantec. In functie de ce aplicatii iti scriu pe filesystemul ala trebuie sa te asiguri ca in momentul snapshotului datele scrise pe disc sunt consistente. Bazele de date si mailboxurile sunt foarte susceptibile de chestia asta. Sau daca zici ca e Xen, ai putea sa poti pune masina pe pauza sa faci snapshot atat de disc cat si de memorie (cel putin conform documentatiei, rog insa pe cineva cu mai multa experienta in ale Xen sa expuna eventualele penalitati pe care le poti avea pt. o masina de productie, atat la snapshot ca si la restore). -- Petre don't thread on me Ratiu ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Solutii BACK-UP
Noi la un moment dat am anuntat userii ca se face backup. La vreo saptamana au inceput sa vina oameni sa le restauram diverse chestii ca le-au sters din greseala, si ca tot e backup sa-i ajutam si pe ei. Dupa o perioada am renuntat la backup, am anuntat oamenii ca daca mai sterg chestii o fac pe barba lor. Surprinzator, au devenit mai atenti cand lucreaza cu chestii pe fileserver. Eu personal nu cred ca backupul trebuie sa rezolve prostia utilizatorilor, ci sa protejeze atunci cand pica sistemul fizic si trebuie eventual restaurat pe o alta masina. Backupul nu este solutia - dar nici cauza prostiei utilizatorilor. Nu cred ca trebuie legate prea mult intre ele fenomenele. Exemplul cu gigel era doar foarte comod. Poti sa pui in loc de persoana end user gigel un script gresit care strica niste date, un virus neprins la timp, practic orice accident se poate intimpla. (We know that shit happens ) Faci unul mare si lat pe saptamana sau pe zi si tii cateva copii in urma. Bine, acu depinde si ce obiective ai la backup. Pai vezi, depinde de situatia de la fata locului. 500G pe un disc usb zilnic e impractic. Eh, d'aia e bine sa ai chestii gen RAID5/6, sa nu faci resync numai dupa un disc sa-l futizezi la greu. Vezi si ce a zis Petre - raid5 e chiar mai rau. Backupul e backup, redundanta e redundanta - 2 lucruri diferite cu obiective care se suprapun doar partial, ca atare unul nu-l poate inlocui pe celalalt. ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Solutii BACK-UP
2010/2/7 Petru Ratiu rpe...@gmail.com: 2010/2/7 Eugeniu Patrascu eu...@imacandi.net: Eh, d'aia e bine sa ai chestii gen RAID5/6, sa nu faci resync numai dupa un disc sa-l futizezi la greu. La RAID5 futizezi _toate_ hard-discurile (adica bitii care se restaureaza pe 1 disc se compun din chunkurile echivalente de pe toate celelalte N-1). Teoretic fiecare disc e futizat doar jumate la RAID5 in configuratie minima si direct proportional cu numarul de discuri in configuratii mai complexe, logica (zic io) fiind ca o sa citeasca de pe discuri doar datele de paritate, nu tot ca la RAID1. La RAID6 nu stiu f. sigur care e schema de calcul a paritatii, dar la redundanta de 2 discuri, ma astept sa munceasca pentru un anumit chunk doar N-2 din celelalte N-1, asa ca un disc oarecare nu mai e citit 100%, ci doar (N-2)/(N-1) * 100%, ceea ce inseamna 75% pt. array de 5 discuri si din ce in ce mai mult pt. mai multe. Nu mai putin, ca fiecare disc contine mai putine date de paritate cu cat numarul de discuri din array creste ? In orice caz, schema propusa (cu un disc in storage) te lasa fara array degradat cam tot timpul, cu exceptia raid1 (unde ai 50% citiri pe cele 2 discurile permanente si 100% scrieri pe ala pieton). ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Solutii BACK-UP
2010/2/7 Eugeniu Patrascu eu...@imacandi.net: 2010/2/7 Petru Ratiu rpe...@gmail.com: 2010/2/7 Eugeniu Patrascu eu...@imacandi.net: Eh, d'aia e bine sa ai chestii gen RAID5/6, sa nu faci resync numai dupa un disc sa-l futizezi la greu. La RAID5 futizezi _toate_ hard-discurile (adica bitii care se restaureaza pe 1 disc se compun din chunkurile echivalente de pe toate celelalte N-1). Teoretic fiecare disc e futizat doar jumate la RAID5 in configuratie minima si direct proportional cu numarul de discuri in configuratii mai complexe, logica (zic io) fiind ca o sa citeasca de pe discuri doar datele de paritate, nu tot ca la RAID1. Nu. Uite un exemplu (ca sa nu fac eu ascii art, luam poza de pe wikipedia, de la http://tinyurl.com/yjhadpk ). Ap este format dupa algoritmul Ap = A1 xor A2 xor A3 samd. In cazul in care vrei sa calculezi blocul de paritate, iti trebuie _toate_ celelalte blocuri din stripe, nu doar unul . Daca iti lipseste unul din blocurile normale, se foloseste exact acelasi algoritm (A2 = A1 xor A3 xor Ap). La RAID6 nu stiu f. sigur care e schema de calcul a paritatii, dar la redundanta de 2 discuri, ma astept sa munceasca pentru un anumit chunk doar N-2 din celelalte N-1, asa ca un disc oarecare nu mai e citit 100%, ci doar (N-2)/(N-1) * 100%, ceea ce inseamna 75% pt. array de 5 discuri si din ce in ce mai mult pt. mai multe. Nu mai putin, ca fiecare disc contine mai putine date de paritate cu cat numarul de discuri din array creste ? Repet, mi-s mai neclari algoritmii de paritate de la raid6 (am cautat acu pe net si deocamdata sunt la fel de prost ca inainte), asa ca n-as prea da exemple. In orice caz, ma bazez pe faptul ca un bloc de paritate se calculeaza pe baza a N-2 discuri, ca atare din oricare N-1 blocuri bune dintr-un stripe, se citesc N-2, de unde formula mea de mai sus. Care tinde spre 100% cu cresterea lui N (75% la 5 discuri, 80% la 6 discuri, 90% la 10 discuri, samd.). Pe undeva e logic: cu cat ai mai putina redundanta, cu atat ai nevoie de mai multe date ca sa o refaci. -- Petre don't thread on me Ratiu ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Solutii BACK-UP
Pe 06.02.2010 16:09, Mircea Popescu a scris: A mai lucrat cineva cu vreunele dintre aceste solutii sau poate cu altele si imi poate recomanda ceva? Eu am folosit backuppc acum vreo 4-5 ani si am fost destul de multumit de el. Il adaptasem un pic, ii bagasem si ceva facilitati de cautare si interfata in romana (care nu stiu daca a ajuns in distributia finala). Stie sa trimita mail, si are (si) o interfata www suficient de simpla si pt. utilizatori non-tehnici. Mi-a mai placut ca stia sa faca singur backup de pe un calculator in momentul in care il detecta in retea (util pt. laptop-uri). Minusuri, din punctul meu de vedere, avea pe la cautarea de fisiere si la exportul de arhive (functionale, dar cu cateva mici probleme, aici a trebuit sa-l coafez eu putin). FWIW, e scris in perl si tine datele intr-o structura specifica (compresia mi se pare ca e optionala, dar si fara ea nu e trivial sa recuperezi fisiere 'de mana' daca moare daemon-ul, din cate imi aduc aminte) ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Solutii BACK-UP
În data de 07.02.2010, Petru Ratiu rpe...@gmail.com a scris: 2010/2/7 Eugeniu Patrascu eu...@imacandi.net: Eh, d'aia e bine sa ai chestii gen RAID5/6, sa nu faci resync numai dupa un disc sa-l futizezi la greu. La RAID5 futizezi _toate_ hard-discurile (adica bitii care se restaureaza pe 1 disc se compun din chunkurile echivalente de pe toate celelalte N-1). La RAID6 nu stiu f. sigur care e schema de calcul a paritatii, dar la redundanta de 2 discuri, ma astept sa munceasca pentru un anumit chunk doar N-2 din celelalte N-1, asa ca un disc oarecare nu mai e citit 100%, ci doar (N-2)/(N-1) * 100%, ceea ce inseamna 75% pt. array de 5 discuri si din ce in ce mai mult pt. mai multe. In orice caz, schema propusa (cu un disc in storage) te lasa fara array degradat cam tot timpul, cu exceptia raid1 (unde ai 50% citiri pe cele 2 discurile permanente si 100% scrieri pe ala pieton). -- Petre don't thread on me Ratiu ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug -- Trimis de pe dispozitivul meu mobil ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
[rlug] Solutii BACK-UP
Acum ca m-am fript cu pierderea de date, ar trebui sa iau masuri pt back-up. Aia e ... da-i, Doamne, romanului mintea cea de pe urma ... As vrea sa imi fac un server de back-up, deci solutie software si nu echipament dedicat. Ar trebui sa aiba posibilitatea de back-up automat atat de pe linux cat si de pe windows, back-up sa se faca incremental. Alte amanunte gen sa dea mail admininstratorului cu rezultatele operatiilor sunt importante dar pot trai si fara ele. Wikipedia imi da urmatoarea lista open-source: Package [image: ↓] http://en.wikipedia.org/wiki/List_of_backup_software# License http://en.wikipedia.org/wiki/License [image: ↓]http://en.wikipedia.org/wiki/List_of_backup_software#Available for Windows http://en.wikipedia.org/wiki/Microsoft_Windows? [image: ↓]http://en.wikipedia.org/wiki/List_of_backup_software#Available for Mac OS X http://en.wikipedia.org/wiki/Mac_OS_X? [image: ↓]http://en.wikipedia.org/wiki/List_of_backup_software#Available for Linux http://en.wikipedia.org/wiki/Linux? [image: ↓]http://en.wikipedia.org/wiki/List_of_backup_software#Has a Graphical user interfacehttp://en.wikipedia.org/wiki/Graphical_user_interface ? [image: ↓] http://en.wikipedia.org/wiki/List_of_backup_software#AMANDAhttp://en.wikipedia.org/wiki/Advanced_Maryland_Automatic_Network_Disk_Archiver BSD http://en.wikipedia.org/wiki/BSD_licensesYesYesYesNoAreca Backuphttp://en.wikipedia.org/wiki/Areca_Backup GPL http://en.wikipedia.org/wiki/GNU_General_Public_License v2.0YesYesYes YesBackupPC http://en.wikipedia.org/wiki/BackupPCGPLhttp://en.wikipedia.org/wiki/GNU_General_Public_License v2.0YesYesYesYesBacula http://en.wikipedia.org/wiki/BaculaGPLhttp://en.wikipedia.org/wiki/GNU_General_Public_License v2.0YesYesYesYesDirSync Pro http://en.wikipedia.org/wiki/DirSync_ProGPLhttp://en.wikipedia.org/wiki/GNU_General_Public_License YesYesYesYesDAR http://en.wikipedia.org/wiki/DAR_(Disk_Archiver)GNU GPL 3http://en.wikipedia.org/wiki/GNU_GPL_3#Version_3 YesYesYesNo A mai lucrat cineva cu vreunele dintre aceste solutii sau poate cu altele si imi poate recomanda ceva? Multam ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Solutii BACK-UP
Fii te rog amabil si incearca sa repostezi lista de aplicatii de care esti interesat, dar intr-un format inteligibil multumesc obs: eu as folosi freenas sau ceva similar, cu un ftp sau rsync server. sau eventual samba pt windowsarii din jur. backupc, bacula si amanda sint solutii testate si fiabile. On 02/06/2010 04:09 PM, Mircea Popescu wrote: Acum ca m-am fript cu pierderea de date, ar trebui sa iau masuri pt back-up. Aia e ... da-i, Doamne, romanului mintea cea de pe urma ... As vrea sa imi fac un server de back-up, deci solutie software si nu echipament dedicat. Ar trebui sa aiba posibilitatea de back-up automat atat de pe linux cat si de pe windows, back-up sa se faca incremental. Alte amanunte gen sa dea mail admininstratorului cu rezultatele operatiilor sunt importante dar pot trai si fara ele. Wikipedia imi da urmatoarea lista open-source: Package [image: ↓] http://en.wikipedia.org/wiki/List_of_backup_software# License http://en.wikipedia.org/wiki/License [image: ↓]http://en.wikipedia.org/wiki/List_of_backup_software#Available for Windows http://en.wikipedia.org/wiki/Microsoft_Windows? [image: ↓]http://en.wikipedia.org/wiki/List_of_backup_software#Available for Mac OS X http://en.wikipedia.org/wiki/Mac_OS_X? [image: ↓]http://en.wikipedia.org/wiki/List_of_backup_software#Available for Linux http://en.wikipedia.org/wiki/Linux? [image: ↓]http://en.wikipedia.org/wiki/List_of_backup_software#Has a Graphical user interfacehttp://en.wikipedia.org/wiki/Graphical_user_interface ? [image: ↓] http://en.wikipedia.org/wiki/List_of_backup_software#AMANDAhttp://en.wikipedia.org/wiki/Advanced_Maryland_Automatic_Network_Disk_Archiver BSD http://en.wikipedia.org/wiki/BSD_licensesYesYesYesNoAreca Backuphttp://en.wikipedia.org/wiki/Areca_Backup GPL http://en.wikipedia.org/wiki/GNU_General_Public_License v2.0YesYesYes YesBackupPC http://en.wikipedia.org/wiki/BackupPCGPLhttp://en.wikipedia.org/wiki/GNU_General_Public_License v2.0YesYesYesYesBacula http://en.wikipedia.org/wiki/BaculaGPLhttp://en.wikipedia.org/wiki/GNU_General_Public_License v2.0YesYesYesYesDirSync Pro http://en.wikipedia.org/wiki/DirSync_ProGPLhttp://en.wikipedia.org/wiki/GNU_General_Public_License YesYesYesYesDAR http://en.wikipedia.org/wiki/DAR_(Disk_Archiver)GNU GPL 3http://en.wikipedia.org/wiki/GNU_GPL_3#Version_3 YesYesYesNo A mai lucrat cineva cu vreunele dintre aceste solutii sau poate cu altele si imi poate recomanda ceva? Multam ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Solutii BACK-UP
2010/2/6 lonely wolf wo...@prolinux.ro: Fii te rog amabil si incearca sa repostezi lista de aplicatii de care esti interesat, dar intr-un format inteligibil multumesc Eu sunt de vina ca am dat approve la mesaj (ca era mai mare decat cei 40K setati ca limita) si nu mi-a trecut prin cap ca mailman strica html-urile. -- Petre don't thread on me Ratiu ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Solutii BACK-UP
2010/2/6 Petru Ratiu rpe...@gmail.com 2010/2/6 lonely wolf wo...@prolinux.ro: Fii te rog amabil si incearca sa repostezi lista de aplicatii de care esti interesat, dar intr-un format inteligibil multumesc Eu sunt de vina ca am dat approve la mesaj (ca era mai mare decat cei 40K setati ca limita) si nu mi-a trecut prin cap ca mailman strica html-urile. -- Petre don't thread on me Ratiu ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug imi cer scuze iata lista din nou Package License Available for Windows? Available for Mac OS X? Available for Linux? GUI? AMANDABSD Yes Yes Yes No Areca BackupGPL v2.0 Yes Yes Yes Yes BackupPCGPL v2.0 Yes Yes Yes Yes BaculaGPL v2.0 Yes Yes Yes Yes DirSync ProGPL Yes Yes Yes Yes DARGNU GPL 3 Yes Yes Yes No ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Solutii BACK-UP
2010/2/6 Mircea Popescu popescu.mir...@gmail.com: imi cer scuze iata lista din nou Sau mai bine ziceai http://en.wikipedia.org/wiki/List_of_backup_software#Open_source si ne descurcam noi :P -- Petre don't thread on me Ratiu ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Solutii BACK-UP
2010/2/6 Petru Ratiu rpe...@gmail.com 2010/2/6 Mircea Popescu popescu.mir...@gmail.com: imi cer scuze iata lista din nou Sau mai bine ziceai http://en.wikipedia.org/wiki/List_of_backup_software#Open_source si ne descurcam noi :P corect, dar eliminasem eu cateva mai intai -- Petre don't thread on me Ratiu ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
Re: [rlug] Solutii BACK-UP
Sa-ti spun sincer, poti sa faci un raid 1 software pe 2 stabile + 1 usb, ca tot era treaba, si hardu pe usb sa-l bagi in raid cand trebe, astepti sa se sync, apoi il notezi ca faulty si pleci cu el. Eu practic asta, mai ales ca poti sa butezi de pe usb-ul ala cand ai chef. Depinde ce ai si ce vrei. Ca asa, la modu general, tivoli ruleaza:). Mircea Popescu wrote: 2010/2/6 Petru Ratiu rpe...@gmail.com 2010/2/6 Mircea Popescu popescu.mir...@gmail.com: imi cer scuze iata lista din nou Sau mai bine ziceai http://en.wikipedia.org/wiki/List_of_backup_software#Open_source si ne descurcam noi :P corect, dar eliminasem eu cateva mai intai -- Petre don't thread on me Ratiu ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug ___ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug