ここにたどり着いた方へ。残念ながら、データを回復できませんでした。さまざまな試行と問題の再現の後、試行を続けるにはコストがかかりすぎたため、必要な情報を再作成するために過去のバックアップを使用しました
人的ミスにより、150G UFS ファイルシステム (Solaris) が破損しました。
ファイルシステム (c0t0d0s3) のバックアップを試みたときに、ufsdump(1M) が正しく使用されていません。これに至った背景を説明します...
管理者が使用したもの:
# ufsdump 0f /dev/dsk/c0t0d0s3 > output_1
root@ats-br000432 # ufsdump 0f /dev/dsk/c0t0d0s3 > output_1
Usage: ufsdump [0123456789fustdWwnNDCcbavloS [argument]] filesystem
これは悪い使い方なので、0 バイトの output_1 というファイルを作成しました。
# ls -la output_1
-rw-r--r-- 1 root root 0 abr 12 14:12 output_1
次に、使用された構文は次のとおりです。
# ufsdump 0f /dev/rdsk/c0t0d0s3 output_1
0 バイトのファイルoutput_1を/dev/rdsk/c0t0d0s3に書き込みました - これはパーティション スライスでした
興味深いことに、ファイルが 0 バイトであるため、ファイルシステムに害はないと考えていましたが、実際にそうなりました。マウントポイントで ls を実行しようとすると、I/O エラーが発生したとパーティションが主張しました。マウントを解除して再度マウントすると、ファイルシステムにはコンテンツが表示されませんでしたが、ディスク領域は以前と同じように使用済みとして表示されていました。
ある時点で、ファイルシステムの「ヘッダー」が影響を受けたと思いますよね？それともスライス情報ですか？
fsck を少し試すと、次のようになります。
** /dev/rdsk/c0t0d0s3
** Last Mounted on /database
** Phase 1 - Check Blocks and Sizes
INCORRECT DISK BLOCK COUNT I=11 (400 should be 208)
CORRECT?
ディスクブロック数 / I=11
- これは、コマンドが自身の内容に関するファイルシステム情報を壊したようですよね? fsck -y -F ufs /dev/dsk..を試みたとき、さまざまなファイルが復元されましたが、目的の dbf ファイル (GB サイズ) は復元されませんでした。
今できることは？newfs -N からのすべてのスーパーブロック情報を試す必要がありますか?
EDIT : スーパーブロック情報を示すパーティション newfs 出力に関する新しい情報
# newfs -N /dev/rdsk/c0t0d0s3
Warning: 2826 sector(s) in last cylinder unallocated
/dev/rdsk/c0t0d0s3: 265104630 sectors in 43149 cylinders of 48 tracks, 128 sectors
129445,6MB in 2697 cyl groups (16 c/g, 48,00MB/g, 5824 i/g)
super-block backups (for fsck -F ufs -o b=#) at:
98464, 196896, 295328, 393760, 492192, 590624, 689056, 787488, 885920,
Initializing cylinder groups:
.....................................................
super-block backups for last 10 cylinder groups at:
264150944, 264241184, 264339616, 264438048, 264536480, 264634912, 264733344,
264831776, 264930208, 265028640