1

对于那些到达这里的人；不幸的是，我无法恢复数据，经过多次尝试和重现问题，继续尝试成本太高，所以我们只是使用过去的备份来重新创建所需的信息

人为错误破坏了 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

这是一个不好的用法，所以它创建了一个名为 output_1 的文件，其大小为 0 字节：

# 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 的每个超级块信息吗？

编辑：关于显示超级块信息的分区 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
4

0 回答 0