Bağlanmayan bir BTRFS bölümünü nasıl kurtarabilirim?


13

12.04 yüklemesi başarısız oldu ve çözüm, yükleyicinin daha önce / home için kullandığım btrfs bölümünü yoksaymasını sağlamaktı.

Yüklü olduğuna göre, 70GB'lık dosyalara erişebilmem için btrfs bölümünü monte etmeye çalışıyorum. Bağlanmaz ve btrfsck aşağıdaki üç satırla hata verir:

parent transid verify failed on 31302336512 wanted 62455 found 62456
parent transid verify failed on 31302336512 wanted 62455 found 62456
parent transid verify failed on 31302336512 wanted 62455 found 62456

Birisi bana bu bölümün nasıl çalışacağını söyleyebilir mi? Çevrimiçi olarak muhtemelen btrfs-restore kullanarak verileri kurtarabileceğimi okudum, ancak bu programı hiçbir yerde bulamıyorum.

Yanıtlar:


10

En kolay yol

btrfs-zero-log /dev/sda5

Günlük günlüğünde bir işlem (yazma veya silme) sıkıştığından ve diskle eşleşmediğinden bu sorunu alıyorsunuz.

Nasıl çalışır:

Bu yüzden veri 1 yazıldığında günlüğe sonra diske yazılır (veya aynı zamanda, ancak dergi sadece yaklaşan yazma hakkında meta verileri kaydeder - emin değilim ... bu kısımda daha fazla araştırmaya ihtiyaç duyar) ...

Bu yazma ortasında sistemini kapatmak neyse eğer / montaj o döner o (başarısız olur çalışmaz zaman bir şey daha sonra sistem (sizin btrfs bağlama noktası tutan USB sökmek), hickups silmek veya yapmak dmesg ve btrfsck irade hataları daha ayrıntılı olarak gösterir) ...

Dmesg'e baktığınızda aynı transit mesajları göreceksiniz.

Bunun gibi bir şey göreceksiniz:

parent transid verify failed on 109973766144 wanted 1823 found 1821

Bu, btrfs'nin transif 1826 (Bu dergide olduğu) istediğini, ancak diskte 1821'i gördüğü anlamına gelir. Yani disk, günlükle senkronize olmaktan 2 işlem uzaktaydı. Şahsen burada sadece 2 işlem nedeniyle bir brtfs-zero-log risk olacaktır. Ancak bu sadece verilerinizse% 100 güvenli olmak için (kritik verileriniz varsa, ASLA hiç bir zaman sadece 1 kopyasına sahip olmamalısınız, her zaman güvenli başka bir yerde bir kopya / yedek almalısınız - btrfs yaratıcılarını suçlamak olmaz kişilerin yedekleme yapma sorumluluğu eksikliğine karşı haklı çıkar - btrfs yedekleme çözümü değildir, onun bir dosya sistemidir - hiçbir şey başka bir kopyasına sahip olmanın yanı sıra gerçek bir yedekleme çözümü değildir - hatta eşlik veya yansıtılmış sürücüler değil, gerçek bir yedekleme aktif kopyası Teksas'taki ofisinizdeyken Alpler'in yeraltında bir yerde oturuyor)

parent transid verify failed on 31302336512 wanted 62455 found 62456

Burada dergi 62455 istiyor ama disk 62456'da bir önde, yani senin durumunda dergi temizlerdim. Journal bu sefer güncellenmedi. Yine size güvenli bir şey olduğunu söyledim, eğer onun tek veri ve mega kritik (utanç size), ve ben güvenli olmak için ilk önce aşağıdaki işlemleri yapmak istiyorum.

Bir btrfsck / dev / sda5 çalıştırmak (bu arada salt okunur bir kontrol yapar, böylece tamamen güvenlidir, endişelenmeniz gereken tek btrfsck seçenekleri) size bu mesajları gösterir.

Ancak bu verilerin kritik olması durumunda dikkatli olun, ilk önce yapardım (Diğer cinsiyetlerin söylediği gibi)

mount -t btrfs -o rootflags=recovery,nospace_cache /dev/sda3 /mnt/sda3

mount -t btrfs -o rootflags=recovery,nospace_cache,clear_cache /dev/sda3 /mnt/sda3

mount -t btrfs -o recovery,nospace_cache,nospace_cache /dev/sda3 /mnt/sda3

Sonra cp veya rsync tüm dosyalarınızı güvenli konuma getirin, o zaman güvenli olduğunda btrfs-zero-log yapın, başarılı bir işlem ise sisteminizi yedeklemek için çok fazla zaman harcadınız (ancak başarılı değilse, eşek)

Sonra bağlar başarısız olursa bir btrfs geri yükleme yapın (sistemin bir dökümü, devam ettirilebilir bir işlem olduğunu anladığım için, ancak her seferinde Y veya y sormaya devam ediyor, bu yüzden çıkışı izleyin)

btrfs restore /dev/sda5 /USB

Sonra güvenli olduğunda (btrfs geri yükleme tamamlandığında) btrfs-zero-log yapın, eğer başarılı bir işlem ise sisteminizi yedeklemek için çok fazla zaman harcadınız (ancak başarılı değilse, kıçınızı kurtardınız)

Önce ekranı çalıştırabilirsiniz

screen /bin/bash

btrfs restore /dev/sda5 /USB

EKRAN YAN NOTU

Sökmek için (komut yine de çalışır): CONTROL-a sonra tırnak işaretleri olmadan ": detach" yazın ve ENTER tuşuna basın

Ayırmanın başka bir yolu: Daha sonra macun veya terminalinizi kapatın ve ayrılır (komut / geri yükleme yine de çalışır).

Kontrol etmek için ekrana geri dönün:

screen -x

screen -x, ayrılmış olsa bile oturumlara eklenecek ve -h'nin aksine, zaten eklenmiş olsa bile eklenecektir)

Birden fazla ekranınız varsa, screen -x, oturuma eklemek için daha belirgin olmanız gerektiğini söyler:

screen -ls

Tüm oturumları listelemek için, bunu hatırlamak kolay.

PID'yi görmek için şunları da yapabilirsiniz:

ps aux | grep screen

PID'nizi bulduktan sonra ekranı şu şekilde çalıştırın:

screen -x PID

Bu belirli bir oturuma eklenecektir. Aynı ekrana birkaç oturum / macun bağlayabilirsiniz (aynı metni çıktılar, komutları bir arada yazabilirsiniz ve diğer macun üzerinde yansıtılacaktır)


7

Kök fs bağlama seçeneklerini kullanarak önyüklemeye monte edin:

rootflags=recovery,nospace_cache

veya

rootflags=recovery,nospace_cache,clear_cache

Btrfs mount seçeneklerinin tam listesi burada olmalıdır https://btrfs.wiki.kernel.org/index.php/Mount_options böyle noatime olarak, nodatacow (beni bir verdiği için bir çekirdek hata düzeltildi ve başka şeyler de yararlı olabilir dosyalarımı kopyalama şansı).

Grub.cfg / menu.lst dosyasına ekleyin veya önyükleme yaparken yazın.

Nospace_cache şeyler işleri çok yavaşlatacaktır. Sadece başlat, bekle (uzun), kapat ve normal şekilde başlat.

Birkaç gün önce aynı şeyi yaşadım ve yukarıdakiler bunu düzeltti. Ancak daha sonra, bazı uzay sorunları vardı ... bildirilen alan% 100 değil, ancak yine de alan dışında diyebilir.

==

Aynı seçenekleri fstab'nıza da ekleyebilirsiniz, örneğin:

UUID=0237alksfadg-lhdfkj3624-4fdfjb-9dsfe2d-dfddaf /home btrfs defaults,recovery,nospace_cache,clear_cache,subvol=@home 0  
 2

Bir bölümün üzerine monte edilmiş bir / home dizinini kurtarmaya çalışıyorsanız UUID=0237alksfadg-lhdfkj3624-4fdfjb-9dsfe2d-dfddaf.


Neden iki nospace_cache?
CVn

bir yazım hatasıydı, clear_cache olması gerekiyordu
Peter

:) Sadece yedekleme ile kurtardın!
derflocki

1

Peter'ın cevabı Ubuntu'da olmasa da benim için sorunu çözdü. /homeTabii ki bozuk btrfs'd bir bölüm vardı . Sistem açık olduğu için önyükleme yapmaz fstab. Bakım moduna girdim, bu bölümle çizgiyi ayırdım ve normal olarak önyükledim (kullanabileceğim yedek bir ext4 bölümüm vardı/home ).

Bölümü aşağıdaki komutla manuel olarak monte ettim:

mount -t btrfs -o recovery,nospace_cache,nospace_cache /dev/sda3 /mnt/sda3ve verilerimi kaydedebildim. Montajı bu kadar uzun sürmese de. Yani TEŞEKKÜRLER Peter.


3
Bunu peter'in cevabına 'Bu işe yaradı' diyerek bir yorum olarak göndermek ve daha sonra bunu gerçek cevap olarak işaretlemek isteyebilirsiniz. Aksi Peter herhangi bir "gerçek" kredi (rep puan) almazsınız
Thomas Ward

1
mount -t btrfs -o ro,nospace_cache,nospace_cache /dev/sda3 /mnt/sda3

ro = salt okunur

Bu iş benim için


1
Cevap olarak eklenen benzer zamanın @ Zaman Efendisi'nin yorumunu okudunuz mu? İşte yine böyle bir şey yapmazsanız - "Bunu sadece peter'in cevabına 'Bu işe yaradı' diyerek bir yorum olarak göndermek ve daha sonra bunu doğru cevap olarak işaretlemek isteyebilirsiniz. kredi (rep puan) "
geezanansa

1

Ben de aynı problemi yaşadım. Yeniden başlattıktan sonra artık btrfs bölümümü bağlayamadım. Ancak burada belirtilen çözümlerin hiçbiri bunu çözemedi.

Benim için ne düzeltti çekirdek 3.10 3.12 için yükseltme oldu. Yeniden başlatıldıktan sonra btrfs bölümü yeniden bağlanabilir.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.