Question

对于到达这里的人;不幸的是，我无法恢复数据，经过各种尝试并重现问题，这太累了，不能继续尝试，所以我们只是使用过去的备份来重新创建所需的信息

人为错误破坏了150G UFS文件系统（Solaris）。

尝试备份filesytem（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

UFS - 0字节文件如何破坏文件系统头？

0 个答案: