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] Backup ftp
2010/1/23 Razvan Deaconescu raz...@rosedu.org: Daca vrei doar actualizarea continutul, fara suport de versionare (adica nu te intereseaza fiecare pas de actualizare), nu cred ca ai nevoie de un version control system. Ai nevoie de rsync, care, din pacate, nu merge peste FTP (sau nu stiu eu cum). Am descoperit acum cateva minute un utilitar care se cheama zsync: Description: client-side implementation of the rsync algorithm zsync is a file transfer program to download files from remote web servers. If a previous version of a file is available locally, zsync will only download changed parts and hereby minimise the download volume. The algorithm is the same as used by rsync(1), but zsync does not require any server software (apart from a web server), nor does it need shell access. Instead, it uses a control file (.zsync file) that describes the file to be downloaded, which it uses to determine the blocks to fetch. This file is created once on the server (and not for each request) and sits next to actual file to download Pare sa fie file-by-file, dar poti face un tar cu tot tree-ul si cred ca tot scuteste o gramada de bandwidth. (Disclaimer: n-am citit mai mult decat descrierea pachetului si o mentiune a lui intr-un blogpost, si m-am gandit ca situatia asta ar fi printre putinele cazuri in care se justifica un asemenea tool). -- 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 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
