LUKS地下室のサイズを変更しようとしています。https://wiki.archlinux.org/index.php/Resizing_LVM-on-LUKSパーティションのサイズ変更を開始し、状況が真剣に混乱しました。新しい寸法を入力しましたが、870
最後にGを追加するのを忘れました。870M
すぐにサイズを変更できるようにパーティションを縮小しましたが、870G
その頃はすでに損傷が発生していました。幸いなことに、LUKSパスワードを復号化することはできますが、システムにデバイスファイルを含む論理ボリュームをインポートすることはできません。 LVM は、ボリュームがすでに存在することを認識し、ボリュームに接続されたデバイスファイルを表示しますが、ファイルは存在せず、ファイルシステムを表示しません。これで、vgscan --mknodes
デバイスファイルが正常に作成されましたが、testdisk
まだ表示されません。ボリュームを再作成し、ここに新しいext4ファイルシステムを追加すると、testdisk
ドライブが表示されますが、スキャン結果は生成されません。 ext4 のエントリがたくさん表示されますが、「ファイルシステムを開けません」または「ファイルが見つかりません」というメッセージが表示されます。ディスク上のファイルシステムを復元できますか?不可能でない限り、コンテンツをインポートする前にデータを書きたくありません。
編集:本当に助けが必要なことを調べた後、助けが必要なのは、古いext4ファイルシステムからファイルを回復することです。ドライブにext4システムがありましたが、新しいシステムはそれを上書きしましたが、以前のシステムのすべてのデータは表示されているとおりに残りますsudo dd if=/dev/Storage/Storage bs=1M | strings -fn 16
。問題を解決した後に私がした唯一のことは、新しいext4 FSをマウントするだけでした。このデータを回復する必要があります。
pvdisplay
以下を表示します
--- Physical volume ---
PV Name /dev/mapper/Storage
VG Name Storage
PV Size 931.51 GiB / not usable 3.68 MiB
Allocatable yes (but full)
PE Size 4.00 MiB
Total PE 238466
Free PE 0
Allocated PE 238466
PV UUID CAueGx-Glzx-zCd0-H00m-R8d5-KTRc-9Ff7ay
--- Physical volume ---
PV Name /dev/mapper/sda3_crypt
VG Name mint-vg
PV Size 118.50 GiB / not usable 0
Allocatable yes
PE Size 4.00 MiB
Total PE 30336
Free PE 10
Allocated PE 30326
PV UUID UJJfu8-S2Ac-pEZl-PlPa-uUzJ-axEs-ckbDWG
私のバックアップショー
# Generated by LVM2 version 2.02.98(2) (2012-10-15): Thu Aug 13 20:45:52 2015
contents = "Text Format Volume Group"
version = 1
description = "Created *before* executing '/sbin/lvreduce --config log{command_names=0} -f -l 217600 /dev/Storage/Storage'"
creation_host = "desktop" # Linux desktop 3.19.0-25-generic #26~14.04.1-Ubuntu SMP Fri Jul 24 21:16:20 UTC 2015 x86_64
creation_time = 1439523952 # Thu Aug 13 20:45:52 2015
Storage {
id = "lM3S9T-inH1-mKsq-5doN-H8hT-zO3F-LF9jDx"
seqno = 2
format = "lvm2" # informational
status = ["RESIZEABLE", "READ", "WRITE"]
flags = []
extent_size = 8192 # 4 Megabytes
max_lv = 256
max_pv = 256
metadata_copies = 0
physical_volumes {
pv0 {
id = "nH1Axo-5nBo-WcyA-Xc4E-KwRt-K0Ib-ScK8Ch"
device = "/dev/mapper/Storage" # Hint only
status = ["ALLOCATABLE"]
flags = []
dev_size = 1953520999 # 931.511 Gigabytes
pe_start = 2048
pe_count = 238466 # 931.508 Gigabytes
}
}
logical_volumes {
Storage {
id = "Qb01kz-y1RG-PVQp-cGjB-sj77-xgnJ-w9kn3n"
status = ["READ", "WRITE", "VISIBLE"]
flags = []
creation_host = "desktop"
creation_time = 1436247513 # 2015-07-06 22:38:33 -0700
segment_count = 1
segment1 {
start_extent = 0
extent_count = 238466 # 931.508 Gigabytes
type = "striped"
stripe_count = 1 # linear
stripes = [
"pv0", 0
]
}
}
}
}
答え1
非常に幸運で、以前のサイズ変更のためにLVに断片化がない場合を除き、LVMのサイズを元のサイズに戻してLVMを変更することはできません。新しいLVは20G
元のファイルシステムの最初の程度を持つ可能性が高いですが、残り780G
(または何でも)はスクランブルエッグ(間違ったデータ、誤ったオフセット、誤った順序)です。
HDDメディアを使用しているとします。 SSDの場合、データは消えるissue_discards=1
ためlvm.conf
、このオプションは決して使用されません。
/etc/lvm/{archive,backup}/
以前のバージョンのメタデータを確認する必要があります。ここにあるすべてのファイルは生成された日付を表します。たとえば、次のようになります。
description = "Created *before* executing 'lvremove HDD/mdtest1'"
Created before lvresize 850
あなたは行方不明だと言った人を探していますG
。その後、vgcfgrestore
LVMメタデータは正常に動作することを望み、そのバックアップを使用します。
このデータが失われたLive CDでこれを実行したか、ルートLVが破損しているためにそのファイルが存在しない場合は、/etc/lvm
LVMメタデータを復元する必要があるため、状況がさらに複雑になります。正常に。循環バッファーにこの記録を含めます。
内部に何があるかを確認するためのおおよその方法は次のとおりです。
dd if=/dev/pvdevice bs=1M count=1 | strings -w -n 16
答え2
以前のext4を破棄していない場合は、fsck
いくつかの修復を実行し、破損していないディレクトリ構造を見つけることができるという希望がまだあるかもしれません。
実際には、あなたが扱っていないディスク部分に余分なスーパーブロックを使用することで、まだ希望があるかもしれませんmkfs
。または、以前のFSに現在空のFSとは異なる数のバックアップスーパーブロックがある場合は、上書きされていない部分がある可能性があります。
e2fsck -b some-offset
これは、LVが以前のLVと同じバイトにマッピングされている場合にのみ適用されます(Frostschultzは回答でこれについて話します)。
バイナリストリームで選択したさまざまな種類のファイルを回復できます。 (ファイル名をバイト範囲にマップするメタデータがないためです。)一部のファイルには認識されるヘッダーがあり、ファイルの終わりがどこにあるかがわかります。ファイルが断片化されている限り、名前のない一部のファイルを回復できることを願っています。
最も重要なことこれを行うツールです。 jpg、gif、png、bmp、avi、exe、mpg、wav、riff、wmv、mov、pdf、ole、doc、zip、rar、htm、cppファイルを探していると主張します.