Příspěvky

1

Server / Re:Záchrana Btrfs volume poškozeného při btrfs check

« kdy: 13. 05. 2022, 01:21:54 »

Toto FUNGUJE pro mount:

Kód: [Vybrat]

localhost:~ # mount -o ro,rescue=nologreplay,rescue=ignorebadroots /dev/star1/backups /mnt

Do teď mě to nenapadlo zkusit, protože jsem myslel, že log už smazal btrfs rescue zero-log a použít backup root jsem také hned zkusil. Ale zafungoval až mount výše.

Co dál: Vytvořím nový Btrfs volume, přes btrfs send/receive přenesu několik vhodně zvolených snapshotů a začnu používat nový volume místo toho poškozeného. Budu u nového držet min. 1 LVM snapshot za cenu horšího výkonu (dle QNAP NAS warningu horšího o 5 až 30%, ale však to jsou jen zálohy).

Mezi tím jsem navíc zprovoznil nezávislé zálohování přes Kopia+rclone na box.com , kde si už pár let platím neomezené úložiště.

Děkuji velmi všem za cenné zkušenosti a rady.

PS: Kdyby někoho ještě napadlo něco k tomuto tématu, tak sem samozřejmě dál pište.

Podařil se zatím jen zázrakem ten read-only mount, což jest nic moc, ale třeba toto vlákno někdy někomu zachrání data.

2

Server / Re:Záchrana Btrfs volume poškozeného při btrfs check

« kdy: 12. 05. 2022, 10:38:15 »

A proto jsem v tomto ultra-konzervativec, co radeji EXT4, ktere si muze precist dekoderem v PHP

Neměl jsem do teď problém s používáním Btrfs, ale jen pod podmínkou, že žádná cenná data nemám jen na jednom místě, což bych stejně dodržoval tak jako tak a pod podmínkou, že čas od času provedu check dat alespoň přes btrfs scrub.

Pokud si na to troufate - implementujte RO userspace driver (tool) pro prochazeni filesystemem (resp. dump adresarove-souborove struktury) - dokumentace datovych struktur snad nekde musi existovat, ne?

Behem takoveho dumpu pak zjistite, kde se to rozbilo (zacnou vyskakovat reference na sektory za koncem partition a podobne), takze to musite pak napravit, aby jste se ke svym datum dostal.

Málo co by mě bavilo víc, ale bohužel už jsem fulltime pracující a tohle mi navíc ani nikdo nezaplatí :-(

Ano, bude to vyzadovat nejakou praci a studium, ale jsou to vase data. Za to, to bude vzdy stat.

Čistě z pohledu uživatele mě ani tak nezajímá jak to opravit, ale zajímá mě, zda se lze vyhnout tomu, aby btrfs check domrvil volume tak, že už z něj vůbec nic nedostanu bez total low-level hackingu.

Tj. zda může být při správných verzích kernelu apod. bezpečné spoléhat se na Btrfs stejně jako na ext4 a nebo dokonce i více (už jednou jsem relativně včas detekoval jeden low-level problém díky Btrfs checksumům dat, což ext4 nenabízí).

3

Server / Záchrana Btrfs volume poškozeného při btrfs check

« kdy: 12. 05. 2022, 01:12:35 »

Zdravím,

prosím o záchranu reputace Btrfs a jako vedlejší efekt i 5,28 TiB mých záloh. Volume vykazoval problémy a po spuštění a pádu btrfs check už nejde ani připojit. Popíši to celé chronologicky níže.

Popis

Měl jsem Linux openSUSE Leap 15.3 s jen oficiálními repozitáři. Byl ve VPS na QNAP NAS.

Do něj jsem měl z toho NASu přes ISCSI připojený 5,28 TiB volume obsahující zálohy všech mých serverů na šifrovaném Btrfs. Říkejme mu třeba blokové zařízení /dev/star1/backups:

Kód: [Vybrat]

localhost:~ # blockdev --getsize64 /dev/star1/backups
5798201655296

localhost:~ # blkid /dev/star1/backups
/dev/star1/backups: LABEL="space-backups" UUID="18d0fd43-c0ac-42f6-a480-fb4f02932b00" UUID_SUB="f91d3e0c-46a6-4ab4-b492-1ed211a1d030" BLOCK_SIZE="4096" TYPE="btrfs"

Protože se mi tento Btrfs volume začal přepínat vždy chvíli po bootu do read-only kvůli nějakému problému, spustil jsem na něm btrfs check, ten ale spadl:

Kód: [Vybrat]

krato-nas01-vps-backups:/home/krato # date ; time btrfs check --repair --clear-space-cache v1 --progress --check-data-csum /dev/star1/backups ; date
Mon May  9 17:03:49 CEST 2022
enabling repair mode
Opening filesystem to check...
Checking filesystem on /dev/star1/backups
UUID: 18d0fd43-c0ac-42f6-a480-fb4f02932b00
Failed to find [6147432235008, 168, 16384]
btrfs unable to find ref byte nr 6147432251392 parent 0 root 2  owner 0 offset 0
transaction.c:195: btrfs_commit_transaction: BUG_ON `ret` triggered, value -5
btrfs(+0x51f99)[0x55a7695aef99]
btrfs(btrfs_commit_transaction+0x1ae)[0x55a7695af58e]
btrfs(btrfs_clear_free_space_cache+0xdc)[0x55a7695a20bc]
btrfs(+0x157fa)[0x55a7695727fa]
btrfs(cmd_check+0x103a)[0x55a7695c4cca]
btrfs(main+0x8e)[0x55a76957c08e]
/lib64/libc.so.6(__libc_start_main+0xed)[0x7febe47e034d]
btrfs(_start+0x2a)[0x55a76957c28a]
Aborted (core dumped)

Po jeho pádu oddíl najednou už ani nešel připojit:

Kód: [Vybrat]

localhost:~ # mount /dev/star1/backups /mnt
mount: /mnt: wrong fs type, bad option, bad superblock on /dev/mapper/star1-backups, missing codepage or helper program, or other error.

localhost:~ # dmesg -T | tail
[Wed May 11 20:32:53 2022] BTRFS error (device dm-1): open_ctree failed
[Wed May 11 21:25:42 2022] hrtimer: interrupt took 18596350 ns
[Thu May 12 00:17:04 2022] BTRFS info (device dm-1): flagging fs with big metadata feature
[Thu May 12 00:17:04 2022] BTRFS info (device dm-1): disk space caching is enabled
[Thu May 12 00:17:04 2022] BTRFS info (device dm-1): has skinny extents
[Thu May 12 00:17:06 2022] BTRFS info (device dm-1): bdev /dev/mapper/star1-backups errs: wr 1, rd 0, flush 0, corrupt 408, gen 0
[Thu May 12 00:17:14 2022] BTRFS error (device dm-1): parent transid verify failed on 6086151716864 wanted 487495 found 487500
[Thu May 12 00:17:14 2022] BTRFS error (device dm-1): parent transid verify failed on 6086151716864 wanted 487495 found 487500
[Thu May 12 00:17:14 2022] BTRFS error (device dm-1): failed to read block groups: -5
[Thu May 12 00:17:14 2022] BTRFS error (device dm-1): open_ctree failed

Protože btrfs check při dalších pokusech opět vždy spadl, nainstaloval jsem novou VPS s openSUSE Tumbleweed, kernel upgradoval na 5.18-rc6 a blokové ISCSI zařízení připojil jen do této VPS:

Kód: [Vybrat]

localhost:~ # head -n 2 /etc/os-release
NAME="openSUSE Tumbleweed"
# VERSION="20220507"

localhost:~ # uname -a
Linux localhost.localdomain 5.18.0-rc6-1.ged50f8f-default #1 SMP PREEMPT_DYNAMIC Sun May 8 21:14:22 UTC 2022 (ed50f8f) x86_64 x86_64 x86_64 GNU/Linux

localhost:~ # btrfs --version
btrfs-progs v5.17

Na něm btrfs check napíše nějaké chyby a pak to vzdá:

Kód: [Vybrat]

localhost:~ # btrfs check /dev/star1/backups
Opening filesystem to check...
parent transid verify failed on 6086151716864 wanted 487495 found 487500
parent transid verify failed on 6086151716864 wanted 487495 found 487500
parent transid verify failed on 6086151716864 wanted 487495 found 487500
Ignoring transid failure
ERROR: child eb corrupted: parent bytenr=6086151536640 item=223 parent level=1 child bytenr=6086151716864 child level=1
ERROR: failed to read block groups: Input/output error
ERROR: cannot open file system

Zkusil jsem btrfs rescue zero-log a btrfs rescue clear-uuid-tree, ale nepomohlo to.

Zkusil jsem na konec ještě btrfs rescue chunk-recover, ale to se vždy po pár hodiných přeruší s chybovou hláškou:

Kód: [Vybrat]

localhost:~ # date ; time btrfs rescue chunk-recover /dev/star1/backups ; date
Wed May 11 20:35:04 CEST 2022
Scanning: 272670670848 in dev0scan chunk headers error
Chunk tree recovery aborted

real    140m45.289s
user    4m31.873s
sys     25m25.405s
Wed May 11 22:55:49 CEST 2022

Připadá mi, že se to neustále točí dokola jen kolem následující chybové hlášky. Možná je tam jen jeden zádrhel, se kterým si neumí poradit mount a ani check. Tato chyba myslím byla také v dmesg úplně na začátku kdy ještě šel ten oddíl přimountovat a přepnul se po chvíli do read-only:

Kód: [Vybrat]

parent transid verify failed on 6086151716864 wanted 487495 found 487500

Dotaz

Máte někdo prosím nějaký nápad jak to opravit aby to šlo opět přimountovat a číst data?

Jedná se v mém případě "jen" o tisíce záloh různých strojů. Cítím to hlavně jako velkou zkoušku vyspělosti Btrfs. Protože jestli "načatý" Btrfs dokáže "btrfs check" dorozbít, že to už nic neopraví a to na stable Linuxu a kernelu, tak se začnu bát můj velmi oblíbený Btrfs používat kdekoliv.

Mohu vyzkoušet jakoukoliv Vaši radu, ten oddíl jsem právě teď snapshotnul. Bohužel naivně ne už před btrfs check. Teď mi stejně jde hlavně o to, zda se lze na Btrfs spolehnout.

4

Server / Re:Chybné čtení dat z mdadm RAID 6 (obzvláště při zápisu)

« kdy: 16. 12. 2018, 03:00:40 »

O několik hodin později v rubrice Bazar: prodám několik zánovních zdrojů: 2x1000W, 2x1,5kW, 1x3kW. Zn.: Dobrá rada nad zlato.

 

To mě pobavilo :-) Nebojte se, jakožto odborník spíše přes software než hardware hledám hardwarové řešení teprve až vyčerpám všechna možná softwarová řešení. A z nich pomohl downgrade kernelu.

• Ustrnout na 4.19.0 (bez virtuálky).
• Ustrnout na 4.19.0 a zkusit veškerou práci s Btrfs přesunout do virtuálky s akt. kernelem.
• Akt. kernel (bez virtuálky) a vypnout NCQ.
• Akt. kernel (bez virtuálky) a hned po bootu vypnout write cache příkazem hdparm -W 0.

na 4.19.0 bych nezůstával, když tak už třeba 4.14.85?

Díky vám a všem, kteří tu psali, že je lepší být trochu konzervativní, jsem se na konec rozhodl na 14 dní ustrnout na 4.14.86 (LTS) (vše nativně, bez virtuálky). Vše fungovalo perfektně bez přidávání parametrů kernelu, nevyskytly se žádné problémy se špatným čtením.

V pripade ze se jedna o bug souvisejici s NCQ, tak je vhodne pak otestovat ruzne io-schedulery. U tech se nekdy meni default, neco je lepsi pro ssd, neco je lepsi pro normalni disky, neco spoleha na ncq..

https://stackoverflow.com/questions/1009577/selecting-a-linux-i-o-scheduler

Ze ja mam vzdy takove dobre tuseni
https://www.root.cz/zpravicky/poskozeni-souboroveho-systemu-mel-na-svedomi-planovac-oprava-jde-i-do-jadra-4-19/

Přesně tak, vypadá to, že problém popsaný na druhém odkazu výše je příčina mého problému. Po 14 dnech spokojeného běhu na kernelu 4.14.86 (LTS) jsem dnes zkusil reboot na 4.19.9. Oprava byla už v 4.19.8, pro jistotu jsem to zkontroloval v changelogu kernelu 4.19.8. Provedl jsem právě teď svůj oblíbený test čtení při zápisu přímo na /dev/md0 a 50x se načetlo 10 GiB se stejným md5 kontrolním součtem. Tj. vypadá to, že opravou v 4.19.8 je problém vyřešen.

Chystám se nyní zjistit, zda bych o něco zásadního přicházel na kernelu 4.14 místo 4.19 a pokud ne, tak bych se asi na 4.14 raději ještě vrátil. Předchozích 14 dní mi na něm nic nechybělo. Připomínám, že mě nové verze kernelu zajímají kvůli funkcím a opravám souborového systému Btrfs, ale dle Btrfs changelogu to vypadá, že alespoň na funkce by mi 4.14 mělo stačit, podporuje dokonce už i kompresní algoritmus zstd a důležité opravy jsou snad backportovány do 4.14.

Děkuji Vám všem za zajímavé a poučné příspěvky, které se tu objevily. Zjistil jsem, že některé věci nenapadly nejen mě, takže se z tohoto vlákna dozvědělo nové informace o Linuxu už několik lidí.

5

Server / Re:Chybné čtení dat z mdadm RAID 6 (obzvláště při zápisu)

« kdy: 01. 12. 2018, 19:30:51 »

Závěr

Pokud nedošlo k chybě měření, tak pomáhá jedno z:

• Downgrade kernelu na 4.19.0
• Nechat vypnuté NCQ parametrem libata.force=noncq

Další postup

Která varianta je lepší, zůstat na 4.19.0 nebo vypnout NCQ?

Jak moc špatné by bylo mít trvale vypnuté NCQ?

Tipuji, že 4.19.0 bude lepší ohledně výkonu, než vypínat NCQ.

Ohledně výkonu asi lepší bude 4.19.0, ale kvůli používání Btrfs bych preferoval pravidelně aktualizovat kernel. Už nějakou dobu zvažuji přesunout mountování Btrfs do virtuálky (virtualbox, vmware, ...) a přistupovat k datům do virtuálky přes NFS a SSHFS. To by řešilo aktualizaci kernelu bez problému čtení a bez rebootu PC, jenže se obávám dopadu na výkon. Teď ještě trubicoid2 zmínil hdparm -W 0 místo vypnutí NCQ, tak ho také zahrnu jako variantu.

Kterou variantu zvolit?

• Ustrnout na 4.19.0 (bez virtuálky).
• Ustrnout na 4.19.0 a zkusit veškerou práci s Btrfs přesunout do virtuálky s akt. kernelem.
• Akt. kernel (bez virtuálky) a vypnout NCQ.
• Akt. kernel (bez virtuálky) a hned po bootu vypnout write cache příkazem hdparm -W 0.

Osobně jsem čekal, že z těch pokusů s kernelem zaberou přesně tyhle věci...

Dobrý odhad každý má, kdo to očekával.

Napadá vás nějaké lepší řešení, které by stálo za pokus?

Upgrade firmware.

Zadal jsem postupně s/n svých 4 disků Seagate Archive Exos 5E8 na webu výrobce:
https://apps1.seagate.com/downloads/request.html

Jedná se o následující s/n (kdyby někdo ze zvědavosti chtěl zkusit s odstupem času):
WCT0BQ83, WCT0BQ62, WCT0BKGX, WCT0C2EB.

Ve všech případech web ohledně firmware napsal:

• Name: "No Newer Firmware Available"
• Importance: -------
• Version: -------
• Release Date: 01-Dec-18
• Short Description: A field update is not available for this serial number. See if CERTIFICATE Firmware Update is shown below. Please help us to improve the Download Finder

Napadá vás jakými dalšími experimenty najít počáteční příčinu?

Osobně jsem si v podstatě z nových informací jist, že chyba je ve firmware některého z disků (nejspíše těch šindelových). Honbou za zlepšením výkonu mají nejspíše nějakou optimalizaci, která v běžném provozu funguje, ale ve složitější konfiguraci a s novějším kernelem naopak způsobuje bug (ve firmware), který vrátí v určitých případech za použití NCQ jiná data z cache, která si myslí, že jsou ta správná. Jiná verze kernelu to řeší nejspíše proto, že byl změněn algoritmus práce s NCQ. Možná by to stálo za prozkoumání.

Ok, klidně raďte, jak zkoumat. Zkusil jsem projít changelog kernelu 4.19.1, ale nenašel jsem tam nic na klíčová slova "ncq" či "sata":
https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.19.1

Možná nějak ověřit, zda se to skutečně týká jen těch 4 disků EXOS. Jak?

Každopádně řešení je jak jsem již psal dříve zkusit nahrát do disků nový firmware, je možné, že dost pravděpodobné, že chyba už v něm nebude, s velmi podobně chovající se věcí jsem se už setkal a firmware to řešil. A ano také to bylo v poli, se samostatným diskem se chyba neprojevila nikdy.

Zajímavá zkušenost.

Pokud se jedná o bug v kernelu, který by se mohl projevovat u dalších uživatelů, jsem ochotný i přes workaroundy výše nadále pátrat po příčině. Jen raďte, co mám dál zkusit.

Osobně si myslím, že to není bug, ale buď se změnila algoritmu při práci, která se projeví při zapnutém NCQ nebo kernel začal využívat nějakou novou featuru ohledně NCQ.

Souhlasím.

Je to podobné, jako když je v kernelu blacklist na některé featury např. SSD jednotek (pamatujete na ztrácející se data i SSD Samsungu při zapnutém Queued Trim? Ve Windows se to nedělo, protože ho neuměly. V Linuxu se chyba okamžitě projevila, protože používal featuru, kterou měly jednotky dle specifikace zvládat, protože hlásily že danou specifikaci umí).

Zajímavé.

Každopádně to vše jsou opatření dočasná. Ty šindelové disky do toho pole nepatří, hrozí jim velmi časná smrt.

Už vymýšlím, jak to provést. Vedle PC mám NAS a v něm 2x Seagate IronWolf 8TB. Pokud to nejsou šindele, tak bych je s dvěma šindeli v poli prohodil. A pak bych si raději při koupi disku vždy připlatil, např. na Western Digital WD Red 8TB. Máte někdo nějaké další doporučení na 8 TB disk (snad tím nespustím flame war)?

6

Server / Re:Chybné čtení dat z mdadm RAID 6 (obzvláště při zápisu)

« kdy: 01. 12. 2018, 10:58:21 »

Pokusím se vrátit pozornost k původnímu problému:

Následující postup

• Zítra večer zkusím starší kernely
• Vypnu HPET v BIOSu (díky za tip)
• Zkusím parametry kernelu (díky za tipy):
  
  • libata.force=noncq
  • libata.force=1.5
  • libata.force=3.0
• Pokusím se aktualizovat firmware disků (imho buď nebudou existovat nebo to bude vyžadovat Windows, uvidíme)
• Zahledám, co ještě mi na forum.root.cz radili

Včera večer a dnes v noci jsem provedl experimenty (víc jsem jich zatím nestihl) s těmito výsledky:

Experiment: Starší kernely

Pozn.: Instalované v Xubuntu 18.04 přes nástroj ukuu.

Test na /dev/md0 čtení 10x 10 GiB při kontinuálním zápisu.

Žádné parametry kernelu jsem nepřidával, pouze zkouším starší verze (a jednu novější).

• 4.17.0-041700.201806041953 ... OK
• 4.19.0-041900.201810221809 ... OK (ještě plánuji ověřit delším testováním)
• 4.19.1-041901.201811041431 ... čte chybně
• 4.19.2-041902.201811132032 ... čte chybně (na této verzi jsem si všiml problému)
• 4.19.5-041905.201811271131 ... čte chybně
• 4.20.0-042000rc4.201811252331 ... čte chybně (verze RC4)

Experiment: Parametry kernelu (aktuální stabilní = 4.19.5)

Test na /dev/md0 čtení 10x 10 GiB při kontinuálním zápisu.

Použit aktuálně nejnovější stabilní kernel, tj.: 4.19.5-041905.201811271131

• (žádný parametr nepřidán) ... čte chybně
• hpet=disable ... čte chybně
• libata.force=noncq ... OK
• libata.force=1.5 ... čte chybně
• libata.force=3.0 ... čte chybně

Závěr

Pokud nedošlo k chybě měření, tak pomáhá jedno z:

• Downgrade kernelu na 4.19.0
• Nechat vypnuté NCQ parametrem libata.force=noncq

Další postup

Která varianta je lepší, zůstat na 4.19.0 nebo vypnout NCQ?

Jak moc špatné by bylo mít trvale vypnuté NCQ?

Napadá vás nějaké lepší řešení, které by stálo za pokus?

Napadá vás jakými dalšími experimenty najít počáteční příčinu?

Pokud se jedná o bug v kernelu, který by se mohl projevovat u dalších uživatelů, jsem ochotný i přes workaroundy výše nadále pátrat po příčině. Jen raďte, co mám dál zkusit.

Jinak podotýkám, že by chtělo experimenty výše ještě ověřit přečtením více dat než 10x 10 GiB, což mám v plánu minimálně u kernelu 4.19.0 (bez přidaných parametrů) a u aktuálního kernelu s vypnutým NCQ.

7

Server / Re:Btrfs - errory při mount, btrfs rescue zero-log, ...

« kdy: 30. 11. 2018, 00:44:39 »

Ten CrashPlan vyzera nejako uzavreto, stale sa mas obratit na ich obchodne oddelenie - maju nejake minimalne mnozstvo zariadeni alebo taky nejaky crazy poziadavok? Vyzera to totiz zaujimavo....

Další výhody CrashPlan

• Komprese. Komprese se mimo jiné aplikuje při přenosu, díky čemuž se textové soubory přenáší mnohem rychleji.
• Deduplikace. Funguje na straně klienta. Pokud tedy přesunete adresář při vypnutém CrashPlanu (tj. ten se o přesunu nedozví), tak se data souborů nebudou znova přesouvat. Zřejmě podle blokových checksumů, se zjistí, že data již na serveru CrashPlanu jsou a nepřenáší se znova. Funguje obecně (a asi blokově), takže pokud zkopírujete velký soubor (nebo adresář se soubory), nebudou se data souborů přenášet znova.
• Hlídání změn souborů. CrashPlan defaultně jednou za určité období (1 týden? lze přenastavit) projde všechny určené adresáře (lze určit které adresáře či soubory se mají zálohovat a které ne, lze určit i pattern pro výjimky) a zjistí změny. Kromě toho defaultně když je spuštěný, tak hlídá změny (v Linuxu přes inotify, nefunguje na síťové disky), takže při běžné práci nic neskenuje, pouze si zaznamenává seznam změněných souborů a ty pak po uplynutí určeného časového intervalu (např. 15 minut) přenese na server.
• Lze ho používat i pro jen jeden stroj. Např.váš pracovní notebook. Zkuste klidně interval 15 minut, třeba to na výkon nebude zas tak moc vadit.
• Při obnově si pak vybíráte datum a čas zálohy, resp. lze nechat defaultní nastavení "nejnovější". Lze nastavit jak časté zálohy se mají jak dlouho uchovávat.

Závěr

Jak vidíte, CrashPlan má řadu nevýhod a výhod, je na každém, zda ho bude chtít používat. Mně se i přes nevýhody vyplatí, výhody v mém případě jasně převažují, ale jen u 2 strojů. Ostatní stroje zálohuji inkrementálně přes rsync nebo btrfs send+receive, což ale nevylučuje kombinování dvou nezávislých technologií, což je varianta, kterou mohu doporučit (někdo by třeba u notebooku zvolil např. CrashPlan+Dropbox).

CrashPlan funguje spolehlivě, má kapacitně neomezené inkrementální zálohování, ale kvůli nárokům na CPU+RAM ho používám na zálohy 1x za noc. Kromě toho zálohuji na můj server umístěný jinde rychlostí až 100 Mbit/s, ale občas mám se svým serverem dlouhodobé technické problémy, viz aktuálně problémy se čtením z diskového pole: https://forum.root.cz/index.php?topic=20161.0

8

Server / Re:Btrfs - errory při mount, btrfs rescue zero-log, ...

« kdy: 30. 11. 2018, 00:16:15 »

Ten CrashPlan vyzera nejako uzavreto, stale sa mas obratit na ich obchodne oddelenie - maju nejake minimalne mnozstvo zariadeni alebo taky nejaky crazy poziadavok? Vyzera to totiz zaujimavo....

CrashPlan

Je proprietární řešení a navíc s placením měsíčního paušálu. Používám u nich už 1 rok CrashPlan for Small Business, dříve jsem používal CrashPlan for Home za podstatně nižší peníze, ale ten bohužel zrušili.

Nevýhody CrashPlan

• Ovládání přes GUI aplikaci místo textově - je to původně určené pro PC a notebooky. Na serveru lze řešit přes X-forwarding nebo protunelování portu, jelikož GUI aplikace komunikuje se službou přes localhost TCP spojení.
• Pomalý upload, aktuálně cca tak 0,5 až 1 TB/měsíc, nutno do objemu započítat i přenášené změny.
• Pomalý download, řádově tak kolem 1 MB/s, dle mých zkušeností.
• Náročnost na CPU a RAM, služba i GUI aplikace jsou napsané v Javě a uchovávají si hodně informací. K zálohování každého 1 TB služba potřebuje cca 1 GB RAM, umí využívat i swap na úkor výkonu. Při zálohování více než 1 TB nebo hodně souborů je potřeba ručně povolit využívání více než 1 GB RAM, viz: https://support.code42.com/CrashPlan/6/Troubleshooting/Adjust_Code42_app_settings_for_memory_usage_with_large_backups
• Při obnově nevíme, zda obnovujeme konzistentní stav. Jednak zálohování nějakou dobu probíhá a při něm se mohou obsahy souborů měnit a pak pokud nám disk odešel zrovna v průběhu zálohování, tak nevíme, které soubory jsou aktuální a které z předchozí zálohy.
• Při hodně adresářích na Linuxu může dojít k vyčerpání inotify limitu.
• Není zdarma a provozovatelé se mohou kdykoliv rozhodnout službu zrušit nebo změnit podmínky.
• Některé věci lze nastavit jen přes jejich web, ne v aplikaci.
• Možná ještě něco, ještě se v příštích týdnech zamyslím.

Výhody CrashPlan

• Vše ostatní.
• Neomezené úložiště u provozovatele (bohužel je nutné na něj soukat data pomalu - cca 0,3 MB/s dle mých zkušeností, ale pokud dat není mnoho nebo se jedná o trvale zapnutý stroj, tak to i tak stojí za úvahu).
• Inkrementální zálohy. Běžně mám nastavené zálohování po 15 minutách a lze je nechat uchovávat natrvalo. Ten interval lze myslím snížit na 1 minutu, ale zatím jsem to nepotřeboval.
• Obnova odkudkoliv. Přes aplikaci (nebo i přes jejich web?) lze po přihlášení obnovit zálohu kteréhokoliv vašeho stroje. Mají i aplikaci pro smartphone.
• Obnovovat lze konkrétní soubor nebo soubory (obnovoval jsem párkrát např. otevřené taby ve webovém prohlížeči) nebo celé adresáře vč. podadresářů, např. celý server.
• Šifrování.
• Spolehlivost. Člověk neřeší hardware (a ani konfiguraci software) a nevšiml jsem si nikdy žádného výpadku jejich služeb.
• Multiplatformní. Používal jsem už jak na celý uživatelský profil ve Windows, tak na celý Linuxový server. V obou případech umí soubory obnovit včetně oprávnění.
• Možnost zálohování do složky místo k nim. Nezkoušel jsem, ale možná by tak šlo vyřešit třeba zálohování na jiný stroj nebo ke známému, kdyby se jednalo o složku na připojeném síťovém disku, třeba přes protokol NFS či Samba.
• Možná nějaké další, které mě teď nenapadly. V příštích týdnech se ještě zamyslím.

Po převodu CrashPlan for Home na CrashPlan for Small Business jsem dostal k dispozici 1 rok trial, kdy byla cena cca 2,4 USD/měsíc za každé zálohované zařízení, ale trial skončil a cena je aktuálně cca 10 USD/měsíc za každé zálohované zařízení, proto jsem zredukoval počet zařízení z 9 na 2: pracovní stroj (Linux Kubuntu) a hlavní server (Linux Xubuntu). Platím za ně aktuálně 579.25 CZK měsíčně vč. DPH. Je to cena za obě zařízení, takže za jedno by byla cca 290 Kč-měsíc.

Disclaimer na závěr: Sděluji jen své uživatelské zkušenosti. Nemám žádný pracovní vztah s firmou provozující CrashPlan a ani za vás nebudu mít žádnou provizi.

Wedos

Poslal jsem Wedosu e-mail s dotazem jak se jim daří plnit plánované změny technologií. Jakmile odpoví, dám zde vědět.

9

Server / Re:Chybné čtení dat z mdadm RAID 6 (obzvláště při zápisu)

« kdy: 29. 11. 2018, 22:48:50 »

Ještě chybí informace o tom, co tam máte za zdroj. Protože s tolika diskama potřebujete podobný zdroj, jako byste v tom počítači měl třeba výkonnou grafickou kartu.

Ok, v následujících dnech zkusím zjistit (nejsem teď u toho stroje).

Ohledně hardware

Zatím jsem ho příliš nepopisoval, protože se stejným hardware přes léto (červen až srpen) fungovalo vše perfektně.

Ukládal jsem na pole 8 TB dat do jednoho souboru na Btrfs a zároveň probíhalo spoustu jiných činností, např. CrashPlan si min. jednou prošel cca milion adresářů na celém poli, probíhalo v každé hodině ukládání záloh, počítání md5 checksum nějakých dat atd., podotýkám, že Btrfs při čtení kontroluje checksumy dat (nevypínal jsem ho), takže při prvním problému by některá z aplikací zobrazila chybu. Ale to se nestalo. Samozřejmě to nevylučuje, že mohlo nějaké hardware začít nenápadně zlobit a nebo příp. že něco přehlížím (častý jev uživatele popisujícího změny hw+sw za určité období).

10

Server / Re:Chybné čtení dat z mdadm RAID 6 (obzvláště při zápisu)

« kdy: 29. 11. 2018, 17:56:55 »

A viz vejs, kdybys tam nemel ten mdraid, ale btrfs raid, nejspis bys na to nenarazil, protoze by to snima pracovalo jako s jednotlivejma diskama. Rizika musis zvazit sam.

Opět zajímavá myšlenka. Díky i za předchozí rady.

Historie pole

Měl bych popsat historii toho pole /dev/md0. Měsíce jsou plus mínus 1 měsíc, jde hlavně o chronologii. Sry, stručněji to sepsat neumím.

• 2018 květen ... nákup 7 disků do PC s aktuálním Xubuntu, všechny prošly napoprvé plným badblocks testem. Vytvořeno md0, na něj umístěna vrstva dm-crypt/LUKS a přímo na ni jedno velké Btrfs (po starších zkušenostech jsem měl v Btrfs 100% důvěru). Od této chvíle pravidelně instalovány poslední stabilní verze kernelu (přes ukuu).
• 2018 červen - červenec ... naplnění daty = desítky milionů souborů, několik subvolumes (vč. snapshotů) a několik velkých souborů s bitovými kopiemi oddílů jiných disků (8 TB, 3 TB, 2 TB, ...).
• 2018 srpen ... ověření dat zkopírovaných z jiných disků (rsync -c na soubory a md5sum na image oddílů) ... všechny MD5 checksumy perfektně odpovídají, včetně checksumu 8 TB souboru (obsahujícího Btrfs oddíl ze staršího 8 TB disku). Vše funguje perfektně.
• 2018 září ... naimportovány tisíce subvolumes přes btrfs receive rozdílových streamů (current vs. parent subvolume), zadáno smazání několika velkých subvolume, btrfs receive dvou možná vadných streamů...
• 2018 září ... zděšení ... některé adresáře jsou nečitelné, u některých souborů nesedí checksum dat => 40 TB Btrfs volume is corrupted
• 2018 září ... přechod z Btrfs na LVM s cca dvaceti Btrfs oddílů (cenná data na read-only oddílech, nastaveno přes LVM: "lvchange -pr") a znova plnění z disků, které jsem ještě nesmazal
• 2018 říjen ... zděšení ... u některých oddílů checksum sedí, u některých ne
  
• 2018 listopad ... 1 ze 7 disků vykopnut z pole, hází chyby čtení, po restartu PC funguje normálně a nevykazuje sebemenší problém, vrátil jsem ho do pole
• 2018 listopad ... pole read-only (při testech zapisuji data na místa, odkud jsem je přečetl a nic jiného by zapisovat nemělo), snažím se najít příčinu

Moje hypotézy

• zhroucení FS v září ... nějaký Btrfs bug (nebo nedostatečná blbuvzdornost btrfs receive)? Měl jsem cca 100 milionů unikátních souborů, 2800 snapshotů, několik souborů nad 1 TB, denně jsem importoval cca 200 rozdílových btrfs streamů (inkr. zálohování btrfs send-receive), při tom jsem zadal smazání několika snapshotů velkých několik TB a naimportoval (btrfs receive) dva Btrfs streamy, ve kterých jsem se ručně povrtal (změnil parent uuid)
• vykopnutí disku v listopadu ... mohl to být následek, že se přečetla špatně nějaká důležitá data?
• chyby čtení při zápisu ... myslím si, že se změnil ovladač SATA řadiče nebo mdadm v nějaké cca říjnové verzi kernelu

Následující postup

• Zítra večer zkusím starší kernely
• Vypnu HPET v BIOSu (díky za tip)
• Zkusím parametry kernelu (díky za tipy):
  
  • libata.force=noncq
  • libata.force=1.5
  • libata.force=3.0
• Pokusím se aktualizovat firmware disků (imho buď nebudou existovat nebo to bude vyžadovat Windows, uvidíme)
• Zahledám, co ještě mi na forum.root.cz radili
• Otestuji, zda z toho lze alespoň vytáhnout data při vypnutých diskových cache. Buď to holt tak používat (btrfs by hodilo chybu kdyby se něco přečetlo špatně, neboť při čtení kontroluje checksumy dat, když se to nevypne) nebo našetřit na nové stejné pole a na něm to zkusit znova (a 2 pole pak mít na různých místech a používat jedno jako zálohu druhého)

11

Server / Re:Chybné čtení dat z mdadm RAID 6 (obzvláště při zápisu)

« kdy: 29. 11. 2018, 16:56:28 »

nevim jestli mi neco uniklo, ale cely test mi to pripada zvlastni. Jestli sem spravne pochopil, tak se pri testu 3 snazite delat md5sum bloku dat z md0 (data ktera sou zasifrovana dm-crypt-em) a zaroven do toho sameho md0 zapisujete? Tzn ze jsou pri tom zapisu a cteni vsechny storage vrstvy aktivni (dm-crypt, LVM, FS) (jinak si nedoaku predstavit jak by mohl probihat konzistentni zapis do FS).

Jestli to chápu správně já, tak řeší pouze md0 (z napsaného předpokládám, že LVM a dm-crypt jsou v tu dobu neaktivní, protože číst blok dat ze zařízení, na kterém probíhají jiné operace výš by bylo opravdu úplně špatně a to samé si můžeme nasimulovat s jedním diskem, čtením z oddílu, když máme připojen souborový systém na tomto oddílu a něco s daty na FS pracuje) a z toho co tu píše, opakovaně čte blok dat ze zařízení /dev/md0. Občas při čtení toho stejného bloku dat to vyhodí jiný checksum = přečetla se jiná data.

Naprosto správně. Zapisuji (resp. čtu) pouze přímo na blokové zařízení /dev/md0, ne do souboru.

Nějak se mi nechce věřit, že by někdo byl takový hazardér a hrál si s blokovým zařízením výše popsaným způsobem, když by byly aktivní další vyšší vrstvy (LVM, dm-crypt, FS). Osobně předpokládám, že aktivní nejsou...

Správný předpoklad. Jak jsem psal, problém nastává už před zadáním cryptsetup luksOpen. tj. při testu nebyly aktivní vrstvy dm-crypt, LVM, ... Na ty se odvážím až si /dev/md0 získá zpátky důvěru.

12

Server / Re:Chybné čtení dat z mdadm RAID 6 (obzvláště při zápisu)

« kdy: 27. 11. 2018, 17:39:48 »

No toho jsem se bál. Kombinace SMR disků (šindelový zápis) s "normálními" v poli. Myslím si, že zakopaný pes je nejspíš tady. Co můžu poradit, co by to mohlo umravnit (bez záruky) je aktualizace firmware v těch drivech. Starší kernel to může teoreticky vyřešit jako workaround taky. Ovšem nevyřeší to to, že SMR disky nejsou na takový provoz vhodné a je s tím víc problémů jak užitku. Chová se to spíš jako kazetopásková jednotka než jako random access zařízení.
Ty Archive Exos jsou SMR určitě, IronWolf si nejsem jist jestli je SMR nebo ne, WD Red jsou AFAIK "normální".

Takže jsem špatně Googlil a omylem koupil zase šindele. To už se mi stalo kdysi se Seagate Archive a dodnes mám na něj špatné vzpomínky korenspondující s tímto krásným článkem o šindelovém zápisu (SMR):
https://diit.cz/clanek/recenze-8tb-seagate-archive

Moje zkušenosti se SMR tenkrát odpovídaly přesně názvu 3. kapitoly, tj. "Zahlcení disku do bezvědomí".

Díky za informaci. Každopádně i přes SMR by teoreticky nemělo docházet ke čtení chybných dat.

Na aktualizaci firmware se o víkendu podívám. Super by bylo, kdyby pomohla.

13

Server / Re:Chybné čtení dat z mdadm RAID 6 (obzvláště při zápisu)

« kdy: 27. 11. 2018, 15:45:20 »

Jak moc je to pole plné? Výhodou ZFS je například synchronizace (resilvering) pouze obsazeného prostoru, narozdíl od mdadm. Tam resync 8TB disku na raid6 může být na hodně dlouho....

Obsazeno cca 37 z 40 TB a do budoucna se počítá s podobným obsazením pole.

Navíc pro výběr Btrfs místo ZFS jsem měl po 2 letech vybírání a testování argumenty, které by ani elegantní resilvering nepřevážil.

14

Server / Re:Chybné čtení dat z mdadm RAID 6 (obzvláště při zápisu)

« kdy: 27. 11. 2018, 13:15:42 »

Co to jsou přesně za disky?

Disky to jsou běžně dostupné mechanické všechny 8 TB, konkrétně tyto:

• 4x Seagate Archive Exos 5E8
• 1x Seagate IronWolf 8TB
• 2x Western Digital WD Red 8TB

Co to jsou přesně za disky? Fungovalo to dříve, nebo to je nové pole?

Pole je staré cca 6 měsíců (stejných 7 disků) a tyto problémy pozoruji cca 2 měsíce.

Dříve (před cca 5 měsíci) jsem na pole nakopíroval 8 TB z jiného disku, porovnal md5 checksum na původním disku a na poli a checksumy odpovídaly. A to jsem při zápisu a porovnávání normálně pole používal read-write na jiná data (zálohy serverů, ...).

Asi bych o víkendu zkusil downgrade na nějaký tak 6 měsíců starý kernel. Ale jestli problém bude stále, tak nevím. A jestli nebude, tak také nevím, zda pak zůstat na starém kernelu nebo jak najít příčinu (v changelogs a commitech kernelu?).

Může nás někam dovést ta souvislost problému s cache v disku?

Navíc mě trochu děsí, že pokud je příčina někde mezi disk-cache, řadič a kernelem, tak se totéž teoreticky může stát každému běžnému uživateli s jedním diskem. Akorát se o tom ani nedozví, pokud nepoužívá FS s checksumy dat (Btrfs, ZFS, ...).

15

Server / Re:Chybné čtení dat z mdadm RAID 6 (obzvláště při zápisu)

« kdy: 27. 11. 2018, 12:58:17 »

Jako chova se ti to hodne divne.

Zkus namisto cteni pouzit kopirovani (do RAM - /dev/shm) a nad tim md5, pokud je stejny jako predesla kopie tak se udela cteni znova. Jen musis mit v ram dve kopie stejneho regionu. Az ti to zahlasi ze md5 nesouhlasi, tak ty dva soubory porovnas.. a zjistis co se s tim vlastne stalo - bud se zmeni 1 bit, nejaky sektor, nebo cely raid stripe.

Tip pro porovnani dvou X GB souboru: udelej si skript co projede pres 1M bloky md5 a pak diff tech dvou seznamu md5. Vadnej chunk pak extrahuj, hexdump -Cv a pak diff 1.hex 2.hex (takto jsem nasel 1 flipnuty bit v 18G instalacce).

Díky za tip a donucení k testu, který na konec nebylo zas tak složité vytvořit. Výsledek prozatím jednoho nalezení rozdílu:

Rozdíl ve dvou po sobě jdoucích načteních je na offsetu 830,5 MiB a je dlouhý přesně 160 KiB (liší se celý tento blok). Když vydělíme velikost rozdílu číslem 5 (protože je 7 disků z RAIDu 6 => 7-2=5), vyjde nám hezké IT-kulaté číslo:

160 KiB / 5 = 32 KiB

Což může, ale nemusí být náhoda.

Podle příkazu mdadm -E /dev/sdb1 | grep "Chunk Size" je mdadm chunk size na mdadm disku: 256 KiB

Co z toho vyplývá?

O víkendu mohu zkusit downgrade kernelu (což bych už jen kvůli Btrfs nerad natrvalo).