Fórum Root.cz
Hlavní témata => Server => Téma založeno: Petr Kratochvíl 25. 07. 2018, 12:42:10
-
Zdravím,
mám VPS u jednoho hostingu, ten mi vlivem jeho chyby smazal celý 370 GB virtuální disk, obnovili mi ho z jejich zálohy, ale Btrfs na šifrovaném LVM při pokusu o mount píše chybu. Zkoušel jsem opravit, ale marně, viz níže. Nenapadne někoho něco jak to opravit?
Verze software
root@krato-space:~# lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 18.04 LTS
Release: 18.04
Codename: bionic
root@krato-space:~# uname -a
Linux krato-space 4.17.8-041708-generic #201807180730 SMP Wed Jul 18 07:32:29 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
root@krato-space:~# btrfs --version
btrfs-progs v4.15.1
Chyba při mount
root@xubuntu:/media# mount /dev/mapper/linux-system linux-system
mount: /media/linux-system: wrong fs type, bad option, bad superblock on /dev/mapper/linux-system, missing codepage or helper program, or other error.
root@xubuntu:/media# tail /var/log/syslog
Jul 24 18:56:57 xubuntu dhclient[2686]: DHCPDISCOVER on ens3 to 255.255.255.255 port 67 interval 6 (xid=0x823cbd3d)
Jul 24 18:57:03 xubuntu dhclient[2686]: DHCPDISCOVER on ens3 to 255.255.255.255 port 67 interval 9 (xid=0x823cbd3d)
Jul 24 18:57:24 xubuntu kernel: [ 2019.510859] BTRFS info (device dm-1): disk space caching is enabled
Jul 24 18:57:24 xubuntu kernel: [ 2019.510861] BTRFS info (device dm-1): has skinny extents
Jul 24 18:57:24 xubuntu kernel: [ 2019.515375] BTRFS error (device dm-1): parent transid verify failed on 290030944256 wanted 685941 found 686068
Jul 24 18:57:24 xubuntu kernel: [ 2019.516184] BTRFS error (device dm-1): parent transid verify failed on 290030944256 wanted 685941 found 686068
Jul 24 18:57:24 xubuntu kernel: [ 2019.516188] BTRFS warning (device dm-1): failed to read tree root
Jul 24 18:57:24 xubuntu kernel: [ 2019.576034] BTRFS error (device dm-1): open_ctree failed
Jul 24 18:57:21 xubuntu dhclient[2686]: message repeated 2 times: [ DHCPDISCOVER on ens3 to 255.255.255.255 port 67 interval 9 (xid=0x823cbd3d)]
Jul 24 18:57:30 xubuntu dhclient[2686]: DHCPDISCOVER on ens3 to 255.255.255.255 port 67 interval 12 (xid=0x823cbd3d)
Marné pokusy o opravu
root@xubuntu:/media# mount /dev/mapper/linux-system linux-system -o ro,usebackuproot
mount: /media/linux-system: wrong fs type, bad option, bad superblock on /dev/mapper/linux-system, missing codepage or helper program, or other error.
root@xubuntu:/media# btrfs rescue zero-log /dev/mapper/linux-system
parent transid verify failed on 290030944256 wanted 685941 found 686068
parent transid verify failed on 290030944256 wanted 685941 found 686068
parent transid verify failed on 290030944256 wanted 685941 found 686068
parent transid verify failed on 290030944256 wanted 685941 found 686068
Ignoring transid failure
Couldn't setup extent tree
Couldn't setup device tree
ERROR: could not open ctree
root@xubuntu:/media# btrfs check /dev/mapper/linux-system
parent transid verify failed on 290030944256 wanted 685941 found 686068
parent transid verify failed on 290030944256 wanted 685941 found 686068
parent transid verify failed on 290030944256 wanted 685941 found 686068
parent transid verify failed on 290030944256 wanted 685941 found 686068
Ignoring transid failure
Couldn't setup extent tree
ERROR: cannot open file system
root@xubuntu:/media# mount /dev/mapper/linux-system linux-system -o ro
mount: /media/linux-system: wrong fs type, bad option, bad superblock on /dev/mapper/linux-system, missing codepage or helper program, or other error.
Dodatek: Zkusil jsem i mount -o recovery, ale také bez úspěchu.
-
btrfsck --init-extent-tree a nezapomen na modleni.
-
To vypadá, že zálohy nedělají snapshoty, ale zkopírováním za běhu. To jsou teda odborníci :D
Zkusil bych nejdříve btrfsck --repair, pokud to nepomůže, tak btrfsck --init-extent-tree. Ale tím druhým se to neopraví, jen dostane do stavu, kdy to lze namountovat a většinu dat zachránit.
Mimochodem nemají starší zálohy?
-
Diky velmi za dosavadni rady, ale asi jsem se modlil malo a nebo ten hosting zalohuje opravdu hodne spatne.
Co by se dalo zkusit dal?
repair.sh
#!/bin/sh
set -x
DIR="/dev/mapper/linux-system"
btrfsck --repair "$DIR"
btrfsck --init-extent-tree "$DIR"
btrfsck --repair --init-extent-tree "$DIR"
btrfs check --repair --init-extent-tree "$DIR"
mount "$DIR" /media/linux-system -o recovery
stdout + stderr
Stejne errory a stejne mount chyby.
+ DIR=/dev/mapper/linux-system
+ btrfsck --repair /dev/mapper/linux-system
parent transid verify failed on 316823060480 wanted 669201 found 669285
parent transid verify failed on 316823060480 wanted 669201 found 669285
parent transid verify failed on 316823060480 wanted 669201 found 669285
parent transid verify failed on 316823060480 wanted 669201 found 669285
Ignoring transid failure
Couldn't setup extent tree
Couldn't setup device tree
ERROR: cannot open file system
enabling repair mode
+ btrfsck --init-extent-tree /dev/mapper/linux-system
parent transid verify failed on 316823060480 wanted 669201 found 669285
parent transid verify failed on 316823060480 wanted 669201 found 669285
parent transid verify failed on 316823060480 wanted 669201 found 669285
parent transid verify failed on 316823060480 wanted 669201 found 669285
Ignoring transid failure
Couldn't setup extent tree
Couldn't setup device tree
ERROR: cannot open file system
+ btrfsck --repair --init-extent-tree /dev/mapper/linux-system
parent transid verify failed on 316823060480 wanted 669201 found 669285
parent transid verify failed on 316823060480 wanted 669201 found 669285
parent transid verify failed on 316823060480 wanted 669201 found 669285
parent transid verify failed on 316823060480 wanted 669201 found 669285
Ignoring transid failure
Couldn't setup extent tree
Couldn't setup device tree
ERROR: cannot open file system
enabling repair mode
+ btrfs check --repair --init-extent-tree /dev/mapper/linux-system
parent transid verify failed on 316823060480 wanted 669201 found 669285
parent transid verify failed on 316823060480 wanted 669201 found 669285
parent transid verify failed on 316823060480 wanted 669201 found 669285
parent transid verify failed on 316823060480 wanted 669201 found 669285
Ignoring transid failure
Couldn't setup extent tree
Couldn't setup device tree
ERROR: cannot open file system
enabling repair mode
+ mount /dev/mapper/linux-system /media/linux-system -o recovery
mount: /media/linux-system: wrong fs type, bad option, bad superblock on /dev/mapper/linux-system, missing codepage or helper program, or other error.
root@xubuntu:~# tail /var/log/syslog
Jul 25 11:47:17 xubuntu kernel: [ 8526.538193] BTRFS error (device dm-1): parent transid verify failed on 316779692032 wanted 669200 found 669282
Jul 25 11:47:17 xubuntu kernel: [ 8526.539002] BTRFS error (device dm-1): parent transid verify failed on 316779692032 wanted 669200 found 669282
Jul 25 11:47:17 xubuntu kernel: [ 8526.539006] BTRFS warning (device dm-1): failed to read tree root
Jul 25 11:47:17 xubuntu kernel: [ 8526.546243] BTRFS error (device dm-1): parent transid verify failed on 316689694720 wanted 669199 found 669282
Jul 25 11:47:17 xubuntu kernel: [ 8526.548020] BTRFS error (device dm-1): parent transid verify failed on 316689694720 wanted 669199 found 669282
Jul 25 11:47:17 xubuntu kernel: [ 8526.548026] BTRFS warning (device dm-1): failed to read tree root
Jul 25 11:47:17 xubuntu kernel: [ 8526.549930] BTRFS error (device dm-1): parent transid verify failed on 316629712896 wanted 669198 found 669277
Jul 25 11:47:17 xubuntu kernel: [ 8526.551346] BTRFS error (device dm-1): parent transid verify failed on 316629712896 wanted 669198 found 669277
Jul 25 11:47:17 xubuntu kernel: [ 8526.551351] BTRFS warning (device dm-1): failed to read tree root
Jul 25 11:47:17 xubuntu kernel: [ 8526.589922] BTRFS error (device dm-1): open_ctree failed
-
Co by se dalo zkusit dal?
Jinou zálohu a zveřejnit a opustit tento dementní hosting.
-
Vy nemate zalohy jinde nez na tom samem hostingu kde mate data? Ne ze by Vam to ted pomohlo, ale do budoucna Vam to pomuze urcite.
-
Vyřešeno.
Dlužím zde ještě pár odpovědí Vám a případným náhodným kolemjdoucím.
Jinou zálohu
Na konec jsem obnovil zálohu z CrashPlan, což trvalo snad den a byla shodou okolností stará asi 2 měsíce, proto jsem se tomu chtěl za každou cenu vyhnout, ale na konec tato záloha kupodivu stačila (nová data byla jinde v Git repozitářích apod.).
a zveřejnit
Wedos a jejich moderní VPS ON.
Což zde asi řadu lidí nepřekvapí. Ale čtěte dál, prosím.
a opustit tento dementní hosting.
Wedos rozeslal e-mail s omluvou a popisem ze kterých technologií (FS, ...) přejdou na které, aby se to již neopakovalo.
Navíc mi jako omluvu prodloužili VPS o 3 měsíce čímž ušetřili tisíce Kč a navíc jsem je přemluvil k navýšení RAM zdarma u jiné VPS u nich, což je drobná polehčující okolnost.
Dnes mám uptime své VPS ON přesně 100 dní, což cca odpovídá době obnovy z mojí zálohy u služby CrashPlan, tj. co tím chci říct: od té doby s VPS již nebyl žádný problém.
Jelikož mění používané technologie, tak je velká šance, že se problém již nebude opakovat a proto jim dávám druhou šanci a zůstávám u nich (ale s inkrementálním zálohováním každých 15 minut všech VPS ke mně, zálohuji rozdíly snapshotů přes btrfs send a btrfs receive a k tomu paralelně přes CrashPlan, když už mě jednou zachránil).
-
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....
-
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.
-
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
-
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
Crashplan jsem pouzival 2 roky. Na prvni pohled genialni reseni, libila se mi moznost zalohovat mezi vicero stroju. Prvni vetsi pruser - jednoho dne mi aplikace tvrdila ze mam znovu zadat sifrovaci klic. Chyba u upgrade. Zadal jsem sifrovaci klic (copy&paste ze zalohy), aplikace zacala uploadovat vse odznova. Meli tam bug, support jenom potvrdil ze x uzivatelu prislo o data. Druhy pruser byl po roce a neco kdyz jsem chtel obnovit data ze zalohy a hlasilo to nejakou srandovni chybu. Support potvrdil ze jsem o data prisel. Dalsi pruser co jsem s nimi zazil byl problem s rychlosti - u inicializace dostanete pridelene nejake datove centrum, ktere mate na dozivoti. Zmenite ISP a zjistite ze misto x mega upload mate 300kilo upload. Reseni supportu bylo ze mi to manualne presunou ale ze data musim nahrat znova, ze zalohy neni mozne presunout. Takze jsem je poslal do sipku.
-
Prvni vetsi pruser ... support jenom potvrdil ze x uzivatelu prislo o data. Druhy pruser ... Support potvrdil ze jsem o data prisel. Dalsi pruser ... data musim nahrat znova, ze zalohy neni mozne presunout.
To zní lákavě. ;D Už několikrát jsem měl nutkání to vyzkoušet, ale nikdy jsem se k tomu zatím nedostal. No, definitivně škrtám, díky za ušetřený čas.
-
hm, na domaci server + time machine ako cold storage to stale znie zaujimavo. len si asi prepocitam, kolko by ma stal Glacier pri mojom pocte dat...