abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
    včera 11:00 | Pozvánky

    Přímý přenos z konference OpenAlt 2024, jež probíhá tento víkend v prostorách FIT VUT v Brně. Na programu je spousta zajímavých přednášek. Pokud jste v Brně, stavte se. Vstup zdarma.

    Ladislav Hagara | Komentářů: 0
    1.11. 23:55 | Humor

    V Coloradu unikla hesla k volebním počítačům. Více než 2 měsíce byla tabulka se stovkami hesel do BIOSu volně na webových stránkách. Dle úřadu je potřeba ještě druhé heslo, takže se o žádnou bezprostřední bezpečnostní hrozbu pro volby nejedná [Ars Technica].

    Ladislav Hagara | Komentářů: 0
    1.11. 18:33 | IT novinky Ladislav Hagara | Komentářů: 20
    31.10. 22:44 | IT novinky

    Apple představil nový MacBook Pro s čipy M4, M4 Pro a M4 Max.

    Ladislav Hagara | Komentářů: 67
    31.10. 22:00 | Zajímavý software

    Na GOG.com běží Halloween Sale 2024. Při té příležitosti lze získat zdarma počítačovou hru Return of the Phantom.

    Ladislav Hagara | Komentářů: 0
    31.10. 20:22 | IT novinky

    Společnost OpenAI spustila internetový vyhledávač ChatGPT search.

    Ladislav Hagara | Komentářů: 1
    31.10. 14:33 | Pozvánky

    Konference OpenAlt 2024 proběhne již tento víkend 2. a 3. listopadu v prostorách FIT VUT v Brně. Začíná ale už v pátek na warm-up party ve Studentském klubu u Kachničky v 17:00. Pokud jste ještě areál FITu nenavštívili, k dispozici jsou pokyny k orientaci. Na programu je 54 přednášek a workshopů. Témata jsou od silně technických témat jako je třeba GCC nebo PostgreSQL po méně technické témata jako eGovernment, nebo třeba detailní analýzu … více »

    Ladislav Hagara | Komentářů: 5
    31.10. 13:23 | Nová verze

    Byla vydána nová verze 6.9 živé linuxové distribuce Tails (The Amnesic Incognito Live System), jež klade důraz na ochranu soukromí uživatelů a anonymitu. Přehled změn v příslušném seznamu. Tor Browser byl povýšen na verzi 14.0.1. Tor client na verzi 0.4.8.13. Thunderbird na verzi 115.16.0.

    Ladislav Hagara | Komentářů: 2
    31.10. 12:33 | Komunita

    Vývojáři free a open source synchronizačního nástroje (a p2p náhrady Dropboxu) Syncthing oznámili, že z důvodu odporu ze strany Google Play ukončují podporu OS Android. Bohužel v rámci toho zmizí i vydání Syncthing na F-Droid, který má slabší uživatelskou základnu. Syncthing je na Androidu implementován formou wrapper aplikace, která spustí Syncthing démon, vyžádá potřebná oprávnění a zpřístupní webové rozhraní démona. Ve srovnání se

    … více »
    Harvie.CZ | Komentářů: 6
    31.10. 01:11 | Nová verze

    V červnu 2022 bylo oznámeno, že z K-9 Mailu se stane Thunderbird pro Android. Trvalo to poněkud déle, než vývojáři předpokládali, ale včera byl první stabilní Thunderbird pro Android 8.0 vydán.

    Ladislav Hagara | Komentářů: 0
    Rozcestník

    Dotaz: poskozena zaloha LVM snapshotu

    6.1.2016 13:26 fish | skóre: 22
    poskozena zaloha LVM snapshotu
    Přečteno: 558×
    Zdravim,

    narazil jsem na zvlastni problem a uz nevim kde hledat puvodce.

    Mam virtualizacni server Debian+Xen hypervizor, virtualy maji kazdy svuj LV.

    Na nej se pripojuje zalohovaci stroj, ktery provadi zalohu dat nasledujicim jednoduchym postupem:

    - vytvori snapshot

    - stahne snapshot pomoci `ssh "dd if=snapshot bs=10M 2>/dev/null" | dd of=vm.img bs=10M`

    - zrusi snapshot

    Vsechno funguje, ale ve chvili, kdy jsem pro kontrolu pridal vypocet checksumu snapshotu na zdrojovem a image na cilovem serveru, jsem zjistil, ze jeden ze ctyr virtualu ma pokazde chybu v datech. Zbyvajici jsou vzdy vporadku. Velikost VM je u vsech virtualu stejna a i preneseny poskozeny image je cely. Kdyz ten samy snapshot na zdroji preulozim do image a pak stahnu pres scp, jsou data vporadku (na to ale obecne nemam kapacitu, proto se data stahuji primo pres dd+ssh).

    Zkusil jsem oba stazene image porovnat a chyba se objevila na cca 15G z 20G. Slo odhadem o 1024B, puvodni blok obsahuje pouze nuly, v cilovem je nahodne nastaveny kazdy osmy byte. Kopirovani image trva relativne dlouho, takze jsem zatim nezkousel, jestli k poskozeni dojde pokazde stejne.

    Narazil nekdo na podobny problem, pripadne mate napad co vyzkouset?

    diky za napady

    Odpovědi

    Jendа avatar 6.1.2016 13:49 Jendа | skóre: 78 | blog: Jenda | JO70FB
    Rozbalit Rozbalit vše Re: poskozena zaloha LVM snapshotu
    To může být i chyba v RAM. Má to ECC? Memtest?
    Kopirovani image trva relativne dlouho
    Pokud je bottleneck v síti, velmi doporučuju dělat rsync --inplace, přenese pár metadat a jen změny.
    Jendа avatar 6.1.2016 13:50 Jendа | skóre: 78 | blog: Jenda | JO70FB
    Rozbalit Rozbalit vše Re: poskozena zaloha LVM snapshotu
    (a taky to zchecksumuje, takže je větší šance, že se na tyto chyby přijde)
    6.1.2016 18:48 fish | skóre: 22
    Rozbalit Rozbalit vše Re: poskozena zaloha LVM snapshotu
    rsync bych samozrejme pouzil rad, kdyby ovsem umel prenaset obsah blockdevice. Vim, ze existuji patche, ale nechce se mi na produkcni server davat jinou nez balickovou verzi.

    Kazdopadne to nemeni nic na tom, ze ten stavajici prenos by mel fungovat, i za cenu toho, ze se prenasi zbytecne vic dat. Problem s pameti to podle me nebude (a nemam sanci to overit). Moc se mi nezda, ze by se problem objevil vzdy jen u jednoho LV. Nicmene me to navedlo na jiny napad - potencialni problem s raid1. Pustil jsem check a skutecne se objevilo nekolik inkonzistenci. Byla by to sice velka nahoda, ze by se projevily zrovna jen u dat snapshotu pro jeden LV, ale moznost to je. Pustil jsem resync pole a dam vedet, jestli to pomohlo.
    6.1.2016 20:55 pavele
    Rozbalit Rozbalit vše Re: poskozena zaloha LVM snapshotu
    S volbou --inplace by to měl rsync umět.
    Jendа avatar 7.1.2016 04:31 Jendа | skóre: 78 | blog: Jenda | JO70FB
    Rozbalit Rozbalit vše Re: poskozena zaloha LVM snapshotu
    rsync bych samozrejme pouzil rad, kdyby ovsem umel prenaset obsah blockdevice
    V dotazu píšeš of=vm.img, tak jsem myslel, že přenášíš blockdevice do souboru, a to umí.
    7.1.2016 10:28 fish | skóre: 22
    Rozbalit Rozbalit vše Re: poskozena zaloha LVM snapshotu
    V tom pripade netusim jak. rsync prenese device node, nikoli jeho obsah. Pro prenos obsahu existuje patch copy-devices, ten ale podle diskuzi, ktery jsem nasel, prikompilovava asi jen Fedora a Ubuntu. --inplace samotny to neresi, ale pro zapis do ciloveho BD by samozrejme byl potreba a pro prenos velkych image se taky vyplati.
    Jendа avatar 7.1.2016 10:51 Jendа | skóre: 78 | blog: Jenda | JO70FB
    Rozbalit Rozbalit vše Re: poskozena zaloha LVM snapshotu
    Hm, fakt to nejde.
    7.1.2016 23:03 Jooky (inactive) | skóre: 39 | blog: Jooky | Bratislava
    Rozbalit Rozbalit vše Re: poskozena zaloha LVM snapshotu
    mas nasledovnu konfiguraciu ?

    - dva a viac diskov cez md raid/mirror
    - nad tym vsetkym lvm
    - VM pouziva svoj vlastny swap

    ak ano, tak:

    Hlavne zo swapom sa stava jedna istym sposobom "zaujimava" vec. Ak VM dochadza pamat, tak nejake data odprace do swapu. Odpratanie do swapu vygeneruje I/O request a ten sa na MD vrstve rozdeli na dva (mirroring). Je ista pravdepodobnost, ze app, ktora sa dostava do swapu sa "zobudi". Zobudenie sprevadza zrusenie swap requestu a teda aj I/O. To moze vyustit do situacie, ze na jeden disk sa zapis dostane a na druhy nie. Kedze bola I/O operacia zrusena, tak nie je dovod akokolvek konkretny blok riesit a mirror ostane rozdielny. Pri citani "round-robin" read politika sposobi, ze raz dostanes zapisane data a raz nieco, co tam bolo predtym ...

    - Ak mas konfiguraciu inu, tak skus to spresnit od diskov az po mountpointy/swap vo virtualkach.
    8.1.2016 11:43 fish | skóre: 22
    Rozbalit Rozbalit vše Re: poskozena zaloha LVM snapshotu
    Vzasade ano, je to md raid1, na nem LVM a v jednotlive LV pro VM. Nicmene swapy jsou jako oddelene LV a ty samozrejme nezalohuju.

    Kazdopadne to zatim vypada, ze ten problem skutecne vznikal nekonzistenci raidu. Po resyncu jsem opakovane zkousel provest zalohu a data jsou pokazde vporadku.

    Ale stejne me prekvapuje, ze muze nekonzistence vzniknout pri praci s tolika urovnemi (VM FS > Hypervizor > LVM > MD), kdyz az MD je ten kdo vi o existenci vice disku a cekal bych, ze co prijme, to zapise na oba. Nicmene kdyz jsem zkontroloval par dalsich serveru, nekonzistence se objevuji casteji nez bych cekal.

    Jedny veci ale porad nerozumim. Jak muze checksum blockdevice souhlasit s checksumem lokalnim image toho device, ale lisi se od checksumu image toho sameho device preneseneho po siti? Nenapada me duvod, proc by to dd se zapisem na disk zpracovaval jinak nez dd se zapisem do stdout ...
    8.1.2016 17:29 Jooky (inactive) | skóre: 39 | blog: Jooky | Bratislava
    Rozbalit Rozbalit vše Re: poskozena zaloha LVM snapshotu
    Ono to v zasade je, aj nie je problem :)

    Zrusena I/O operacia je z pohladu filesystemu / swapu nepotrebna. Dany blok nebude FS, ani swap do dalsieho zapisu pouzivat, takze -> nie je problem

    Block level zaloha, alebo raid verifikacia nad takto puzivanym polom moze ukazovat chybu, aj ked realne chyba nie je -> tu je to asi na dlhsiu diskusiu

    Ked mas cas sa s tym pohrat, tak skus nasledovne:
    - pockaj az sa znova nejaka inkonzistancia ukaze
    - skus si najst addresu, na ktorej sa to nachadza
    - cez debugfs si daj vypisat obsah daneho bloku (napr. podla navodu tu)

    Podla mna to ukaze na nejake volne miesto.

    Co sa tyka dalsej otazky:
    dd if=/dev/vg_daco/lv_nieco-snapshot bs=1M | ssh niekto@niekde dd of=zaloha.bin bs=1M
    
    musi preniest data 100% rovnako. Ak nesedia kontrolne sucty, tak zrejme nemas "cisty" neinteraktivny shell. Skus pozriet, ci sa ti nieco z profilu nenacitava, co trosku pozmenuje data ...

    btw. ja by som v produkcii nepouzival dd | ssh dd. Je tam hodne veci, co sa ti moze potichu pokazit. Na problem prides az v momente, ked zistis, ze nie je zaloha ... Ja osobne by som zalohu robil cez sw bacula (Backing up Raw Partitions)

    ps: nebude lepsie robit zalohu dat z virtualok, ako zalohovat vsetko vratane nepouziteho miesta ?
    8.1.2016 20:24 fish | skóre: 22
    Rozbalit Rozbalit vše Re: poskozena zaloha LVM snapshotu
    dd if=/dev/vg_daco/lv_nieco-snapshot bs=1M | ssh niekto@niekde dd of=zaloha.bin bs=1M
    
    musi preniest data 100% rovnako. Ak nesedia kontrolne sucty, tak zrejme nemas "cisty" neinteraktivny shell. Skus pozriet, ci sa ti nieco z profilu nenacitava, co trosku pozmenuje data ...
    To me samozrejme napadlo jako prvni, proto jsem zkusil ty data porovnat a neslo o zadny truncate/append nebo pridani "dat" obsahujicich hlaseni shellu nebo ssh. Byl to vylozene binarni rozdil, kdy se lisily radove desitky bytu a obsahovaly nahodna data.
    btw. ja by som v produkcii nepouzival dd | ssh dd. Je tam hodne veci, co sa ti moze potichu pokazit. Na problem prides az v momente, ked zistis, ze nie je zaloha ... Ja osobne by som zalohu robil cez sw bacula (Backing up Raw Partitions)

    ps: nebude lepsie robit zalohu dat z virtualok, ako zalohovat vsetko vratane nepouziteho miesta ?
    Moznych problemu jsem si vedom, ale tohle reseni ma zasadni vyhodu v tom, ze v pripade problemu muzu ten image rovnou spustit v zaloznim hypervizoru. Z Baculy a podobnych, bych ho musel nejdriv nekam obnovit. Z tech VM zaroven delam i rdiff-backup, ale s nim zase nemuzu udelat plnohodnotnou zalohu bez zastaveni VM (a davat dovnitr VM LVM jen kvuli snapshotu nevidim jako idealni). Kazdopadne diky za napady a pripominky. Aktualne ty checksumy souhlasi, takze nemuzu dal experimentovat, ale docela rad bych nekdy prisel na to, kde se tam ten rozdil v datech bral ...
    10.1.2016 12:59 Jooky (inactive) | skóre: 39 | blog: Jooky | Bratislava
    Rozbalit Rozbalit vše Re: poskozena zaloha LVM snapshotu
    To me samozrejme napadlo jako prvni, proto jsem zkusil ty data porovnat a neslo o zadny truncate/append nebo pridani "dat" obsahujicich hlaseni shellu nebo ssh. Byl to vylozene binarni rozdil, kdy se lisily radove desitky bytu a obsahovaly nahodna data.
    hmmmm, ssh a samotne tcp/ip si robi kontrolu. Mozes na zdroji a cieli zbehnut memtest ? "just to be sure"

    bacula a spol -> ak zakaznik ocakava taky styl restoru, tak si asi moc nevyberies. Ja mam to "stastie", ze sme sa dohodli na file level restore. Kazdy system ma svojho bacula clienta a len realne data vyhatujem z masin ...
    Kazdopadne diky za napady a pripominky. Aktualne ty checksumy souhlasi, takze nemuzu dal experimentovat, ale docela rad bych nekdy prisel na to, kde se tam ten rozdil v datech bral ...
    nz, ked by sa to znova ukazalo, tak skus najst presne blok. Z toho by sa dalo dopatrat cez debugfs, co tam je presne. Dole som este pridal jeden koment, kedze asi som to uplne presne nesformuloval predtym + par napadov ako monitorovat take pole. (Na thread si necham zapnute sledovanie)
    8.1.2016 19:00 R
    Rozbalit Rozbalit vše Re: poskozena zaloha LVM snapshotu
    To je podla mna pekna blbost. MD nevie nic o tom, co ma vnutri - ci je to filesystem, swap alebo nieco lubovolne ine. Takze nesmie za ziadnych okolnosti dopustit, aby data nezapisal na vsetky zariadenia v mirrore.
    8.1.2016 19:16 Jooky (inactive) | skóre: 39 | blog: Jooky | Bratislava
    Rozbalit Rozbalit vše Re: poskozena zaloha LVM snapshotu
    Nieje :o) ... a nejde o realne zapisy, tie musia byt vzdy zapisane na kazdy relevatny disk v raid konfiguracii. Ide o stav, ked app / kernel zrusi I/O request v momente, ked uz data zacali byt zapisovane. Riesilo sa to tu uz raz. Ked budem mat cas, tak skusim pohladat povodny thread.
    8.1.2016 22:57 lertimir | skóre: 64 | blog: Par_slov
    Rozbalit Rozbalit vše Re: poskozena zaloha LVM snapshotu
    A máš představu, jak moc se to používá. Sice vím že existuje io_cancel, ale moc netuším, jak to smysluplně použít. Tedy, kdy jsem schopen se dostat do situace, kdy se jednak v jednu chvíli rozhodnu pro IO operaci a než operace je provedena zjistím nové skutečnosti na základě nichž bych ji chtěl zrušit.
    10.1.2016 12:45 Jooky (inactive) | skóre: 39 | blog: Jooky | Bratislava
    Rozbalit Rozbalit vše Re: poskozena zaloha LVM snapshotu
    eeee, nemyslel som io_cancel. Ospravedlnujem sa, skusim to sformulovat trosku inak.

    - Ak je "naspodu" raid5 a podobne (stripe + parita), tak toto spravanie je viac nez len podozrive + echo "check" > /sys/block/md*/md/sync_action nesmie ukazat nieco ine ako 0 (slovom nula) v /sys/block/md*/md/mismatch_cnt

    - Ak je "naspodu" raid1 (mirror, popripade kobinacia ako raid10), tak "by design" sa mozu tie dva disky lisit. Preto napr distribucie s automatickou kontrolou md-raid ignoruju mirror.

    Nemal som pouzit nazov "zrusena" I/O, ale skorsie nepotrebna / zahodena. Priklad:

    1) Je malo pamate a VM sa rozhodne nejaku stranku dat do swapu. Toto vyprodukuje dve I/O operacie a je celkom dobra sanca, ze sa APP prebudi a zapise do stranky (ked je malo pamate). VM si danu stranu oznaci ako "dirty" a neriesi, co sa stalo so zapisom. Realne moze jedna DMA operacia dobehnut s povodnymi datami a druha s novymi, alebo jedna z nich nedobehne vobec (ked VM povie, ze to uz nepotrebuje). V realnom stave nie je dovod z takeho miesta citat, takze sa to nejak neriesi, no block level backup bude ukazovat rozdiel (podla toho z ktoreho disku a md rozhodne citat).

    2) Nejaka app ma "memory mapped" subor. Do suboru priebezne prihadzuje data a manager pamate ich prehadzuje do suboru. Tak isto sa moze stat, ze sa data zmenia a na diskoch nie su do dalsieho zapisu rovnake data. Tato situacia by mala trvat len kratko, ale zalezi na obieme zmenenych dat + ak sa napr. nespravne signalizuje vyrabanie snapshotu filesystemu (toto je snad uz konecne fixnute v LVM), tak dany blok sa v aktualnom stave "zafixuje".

    3) "memmory mapped" subor je po zmenach, ktore sa ciastocne zapisali vymazany. (toto musim pozriet, ci to stale tak funguje) Data sa uz nebudu zapisovat a obsadene miesto sa oznaci ako volne. Tak isto je toto skorsie az race condition, ale moze nastat ...

    Ak sa cita vsetko, vratane miest, ktore nie su validne (volne miesto, este nezapisane, etc.). Tak vysledok zalezi od toho, z ktoreho disku sa raid rozhodne precitat. Dost zaujimave citanie na tuto temu je jeden debian bug report. Konkretne odpoved #41.

    V pripade md-raid(-u) v mode mirror check pola moc nepomoze. Jednine ako skontrolovat, ze vsetko ide ako ma, je kontrolovat aj uroven pod. Ked je moznost, tak aj uroven nad:

    - stav diskov (pravidelne smart -t short, smart -t long, smart -a / mozem vyzdielat moj konfig, ak je to zaujimave)
    - samotne pole, ci nehlasi I/O errory a je spravne zlozene, etc.
    - checksumy na urovni filesystemu *
    - z casu na cas memtest (len vazne pri velkej paranoi, alebo podozreni na problem)

    * (ja vramci paranoje kontrolujem vsetky staticke subory a cast dynamickych kontrolujem oproti katalogu / dobuducna mam plan prejst na fs s checksumami dat, zrejme btrfs)

    FYI: zbehol som na jednej mojej masine check a mismatch_cnt je nenulove. Ked budem mat cas, tak s tym skusim kus pohrat :o)
    Jendа avatar 10.1.2016 13:09 Jendа | skóre: 78 | blog: Jenda | JO70FB
    Rozbalit Rozbalit vše Re: poskozena zaloha LVM snapshotu
    Preto napr distribucie s automatickou kontrolou md-raid ignoruju mirror.
    Debian mi mirror neignoruje a jednou za pár měsíců tam najde chyby (stroj s ECC). Tohle by je mohlo vysvětlovat (je to virtualizační host a na tom RAID1 jsou swapy všech virtuálů; paměti mají celkem dost, ale i tak to občas trochu zaswapuje).

    Tím pádem odvolávám jak jsem tu někde psal „po půl roce jsem konečně viděl na disku silent data corruption“. Současně se mi ale dost zúžil prostor, kde data corruption hledat.
    FYI: zbehol som na jednej mojej masine check a mismatch_cnt je nenulove. Ked budem mat cas, tak s tym skusim kus pohrat :o)
    Check to rovnou opraví, ne?
    10.1.2016 15:20 Jooky (inactive) | skóre: 39 | blog: Jooky | Bratislava
    Rozbalit Rozbalit vše Re: poskozena zaloha LVM snapshotu
    V tom bugreporte z 2007 preberali moznost vypnut check na mirror poliach a nasledny reporting mismatch_cnt. Ked mam pravdu povedat, nepozeral som ci to tak aj naozaj spravili.
    md arrays can be scrubbed by writing either check or repair to the file md/sync_action in the sysfs directory for the device.

    Requesting a scrub will cause md to read every block on every device in the array, and check that the data is consistent. For RAID1 and RAID10, this means checking that the copies are identical. For RAID4, RAID5, RAID6 this means checking that the parity block is (or blocks are) correct.

    If a read error is detected during this process, the normal read-error handling causes correct data to be found from other devices and to be written back to the faulty device. In many case this will effectively fix the bad block.

    If all blocks read successfully but are found to not be consistent, then this is regarded as a mismatch.

    If check was used, then no action is taken to handle the mismatch, it is simply recorded. If repair was used, then a mismatch will be repaired in the same way that resync repairs arrays. For RAID5/RAID6 new parity blocks are written. For RAID1/RAID10, all but one block are overwritten with the content of that one block.
    man 4 md

    check explicitne nevyzaduje fixnut data. Fixuje sa len to, co by sa normalne fixlo pri beznom citani s chybou na disku. repair explicitne vyzaduje kazdu inkonzistenciu fixnut. Pri mirror poliach (1 a 10) to znamena, ze sa viacmenej nahodne vyberie jeden disk a rozdielne preplacnu na ostatnych.

    Založit nové vláknoNahoru

    Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

    ISSN 1214-1267   www.czech-server.cz
    © 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.