Solaris Volume Manager 管理指南

第 25 章对 Solaris Volume Manager 进行疑难解答（任务）

本章介绍如何解决与 Solaris Volume Manager 相关的问题。除提供一般的疑难解答原则以外，本章还提供用来解决某些已知问题的特定过程。

本章包括以下信息：

本章介绍 Solaris Volume Manager 的一些问题及其相应的解决方案。本章无意面面俱到，仅提供一些常用的方案和恢复过程。

对 Solaris Volume Manager 进行疑难解答（任务列表）

以下任务列表列出了对 Solaris Volume Manager 进行疑难解答所必需的一些过程。

任务	说明	参考
替换出现故障的磁盘	替换磁盘，然后更新新磁盘上的状态数据库副本和逻辑卷。	如何替换出现故障的磁盘
从磁盘移动问题中恢复	将磁盘恢复到原始位置或者与产品支持人员联系。	从磁盘移动问题中恢复
从错误的 `/etc/vfstab` 项中恢复	针对镜像执行 `fsck` 命令，然后编辑 `/etc/vfstab` 文件，以便系统能够正确引导。	如何从错误的 `/etc/vfstab` 项中恢复
从引导设备故障中恢复	从另一个子镜像引导。	如何从引导设备故障中恢复
从状态数据库副本不足中恢复	使用 `metadb` 命令删除不可用的副本。	如何从状态数据库副本不足中恢复
恢复已丢失软分区的配置数据	使用 `metarecover` 命令恢复软分区的配置数据。	如何恢复软分区的配置数据
从修复的磁盘中恢复 Solaris Volume Manager 配置	将磁盘连接到新系统，并让 Solaris Volume Manager 从现有的状态数据库副本重新生成配置。	如何从本地磁盘集恢复存储
从另一个系统中恢复存储	将存储从已知磁盘集导入另一个系统。	从另一个系统中恢复存储
清除不可访问的磁盘集。	使用 `metaset` 命令清除不能获取或使用的磁盘集的内容。	从磁盘集问题中恢复
恢复存储在 Solaris Volume Manager 卷上的系统配置。	使用 Solaris OS 安装介质恢复存储在 Solaris Volume Manager 卷上的系统配置。	执行系统恢复

系统疑难解答概述

对系统进行疑难解答的先决条件

要解决与 Solaris Volume Manager 相关的存储管理问题，需要具备以下条件：

具有超级用户权限
拥有所有数据的最新备份

对 Solaris Volume Manager 进行疑难解答的一般原则

在解决 Solaris Volume Manager 问题时，应当准备好以下信息：

metadb 命令的输出
metastat 命令的输出
metastat -p 命令的输出
/etc/vfstab 文件的备份副本
/etc/lvm/mddb.cf 文件的备份副本
prtvtoc 命令（SPARC® 系统）或 fdisk 命令（基于 x86 的系统）的磁盘分区信息
系统上 Solaris 的版本
已安装的 Solaris 修补程序的列表
已安装的 Solaris Volume Manager 修补程序的列表

提示 –

无论何时更新 Solaris Volume Manager 配置或者对系统进行其他与存储或操作系统相关的更改，都会生成此配置信息的新副本。还可以使用 cron 作业自动生成此信息。

一般疑难解答方法

尽管无法通过一个过程来评估所有的 Solaris Volume Manager 问题，但是以下过程提供的一般方法可能会有所帮助。

收集有关当前配置的信息。
查看当前状态的指示器（包括 metastat 和 metadb 命令的输出）。此信息应指示哪个组件存在故障。
检查硬件是否存在明显的故障点：
- 所有电缆的连接是否正确？
- 最近是否停过电？
- 是否曾经更改或添加过设备？

替换磁盘

本节介绍如何在 Solaris Volume Manager 环境中替换磁盘。

注意 –

如果出现故障的磁盘上有软分区，或者在出现故障的磁盘上构建的卷上有软分区，则必须将新磁盘放在相同的物理位置中。而且，还要将相同的 cntndn 编号用作要替换的磁盘。

如何替换出现故障的磁盘

通过检查 /var/adm/messages 文件以及 metastat 命令的输出，确定要替换的出现故障的磁盘。

查找可能放在出现故障的磁盘上的所有状态数据库副本。

可使用 metadb 命令查找这些副本。

metadb 命令会报告出现故障的磁盘上状态数据库副本的错误。在此示例中，c0t1d0 是有问题的设备。

# metadb

   flags       first blk        block count

  a m     u        16               1034            /dev/dsk/c0t0d0s4

  a       u        1050             1034            /dev/dsk/c0t0d0s4

  a       u        2084             1034            /dev/dsk/c0t0d0s4

  W   pc luo       16               1034            /dev/dsk/c0t1d0s4

  W   pc luo       1050             1034            /dev/dsk/c0t1d0s4

  W   pc luo       2084             1034            /dev/dsk/c0t1d0s4

输出显示，在每个本地磁盘（c0t0d0 和 c0t1d0）的片 4 上都有三个状态数据库副本。c0t1d0s4 片的标志字段中的 W 指示设备有写入错误。c0t0d0s4 片上的三个副本仍处于良好状态。

记录状态数据库副本所在片的名称以及状态数据库副本的数量。然后删除状态数据库副本。

状态数据库副本的数量可通过计算某个片在 metadb 命令输出中出现的次数来获得。在此示例中，删除了 c0t1d0s4 上存在的三个状态数据库副本。
# metadb -d c0t1d0s4
注意 –
在删除有问题的状态数据库副本之后，如果只剩下三个或更少的副本，请先添加更多的状态数据库副本，然后再继续执行操作。这样有助于确保配置信息保持不变。

查找和删除出现故障的磁盘上的所有热备件。

可使用 metastat 命令来查找热备件。在此示例中，热备用池 hsp000 包括 c0t1d0s6，该片随后将从热备用池中删除。
# metahs -d hsp000 c0t1d0s6 hsp000: Hotspare is deleted

替换出现故障的磁盘。

此步骤可能需要使用 cfgadm 命令、luxadm 命令或其他适用于您的硬件和环境的命令。在执行此步骤时，请确保按照硬件文档中的过程正确地处理该磁盘的 Solaris 状态。

对新磁盘重新分区。

使用 format 命令或 fmthard 命令，用与出现故障的磁盘相同的片信息对新磁盘进行分区。如果拥有出现故障的磁盘的 prtvtoc 输出，则可以用 fmthard -s /tmp/failed-disk-prtvtoc-output 命令格式化替换磁盘。

如果删除了状态数据库副本，请向相应的片中重新添加相同的编号。

此示例中使用的是 /dev/dsk/c0t1d0s4。
# metadb -a -c 3 c0t1d0s4

如果磁盘上的所有片都是 RAID-5 卷或 RAID-0 卷的组件，而这些卷又是 RAID-1 卷的子镜像，请针对每个片运行 metareplace -e 命令。

此示例中使用的是 /dev/dsk/c0t1d0s4 和镜像 d10。
# metareplace -e d10 c0t1d0s4

如果直接在替换磁盘的片上构建软分区，请针对每个包含软分区的片运行 metarecover -m -p 命令。此命令会在磁盘上重新生成分区扩展表头。

在此示例中，/dev/dsk/c0t1d0s4 需要在磁盘上重新生成软分区标记。系统会扫描该片并基于状态数据库副本中的信息重新应用这些标记。
# metarecover c0t1d0s4 -m -p

如果磁盘上的所有软分区都是 RAID-5 卷或 RAID-0 卷的组件，而这些卷又是 RAID-1 卷的子镜像，请针对每个片运行 metareplace -e 命令。

此示例中使用的是 /dev/dsk/c0t1d0s4 和镜像 d10。
# metareplace -e d10 c0t1d0s4

如果在 RAID-0 卷上构建了软分区，请针对每个 RAID-0 卷运行 metarecover 命令。

在此示例中，在 RAID-0 卷 d17 上构建了软分区。
# metarecover d17 -m -p

替换已删除的热备件，然后将它们添加到适当的热备用池中。

在此示例中，热备用池 hsp000 包括 c0t1d0s6，该片随后添加到该热备用池中。
# metahs -a hsp000 c0t1d0s6hsp000: Hotspare is added

如果软分区或非冗余卷受到磁盘故障的影响，请从备份中恢复数据。如果只有冗余卷受到影响，请对数据进行验证。

检查所有卷上的用户和应用程序数据。可能必须运行应用程序级一致性检查器或者使用某种其他方法来检查数据。

从磁盘移动问题中恢复

本节介绍在 Solaris Volume Manager 环境中移动磁盘之后如何从意外的问题中恢复。

磁盘移动和设备 ID 概述

Solaris Volume Manager 使用与特定磁盘相关联的设备 ID 来跟踪在 Solaris Volume Manager 配置中使用的所有磁盘。当将磁盘移到另一个控制器时，或者 SCSI 目标编号发生变化时，Solaris Volume Manager 通常可正确地识别移动，并相应地更新所有相关的 Solaris Volume Manager 记录。此时无需系统管理员介入。在个别情况下，Solaris Volume Manager 无法完全更新这些记录并在系统引导时报告错误。

解决未命名设备错误

如果您添加新硬件或者移动硬件（例如，将一组磁盘从一个控制器移到另一个控制器），Solaris Volume Manager 会检查与所移动磁盘相关联的设备 ID，并相应地更新内部 Solaris Volume Manager 记录中的 cntndn 名称。如果无法更新这些记录，那么，在系统引导时，由 svc:/system/mdmonitor 服务产生的引导过程会向控制台报告一个错误：

Unable to resolve unnamed devices for volume management.

Please refer to the Solaris Volume Manager documentation,

Troubleshooting section, at http://docs.sun.com or from

your local copy.

该问题既不会导致数据丢失，也不会直接产生任何负面影响。此错误消息表明 Solaris Volume Manager 名称记录只进行了部分更新。metastat 命令的输出中显示了一些以前使用过的 cntndn 名称，还显示了一些反映移动后状态的 cntndn 名称。

在这种情况下，如果需要更新 Solaris Volume Manager 配置，则在发出任何 meta* 命令时，必须使用由 metastat 命令报告的 cntndn 名称。

如果出现此错误状态，可以执行以下操作之一来解决此问题：

将所有的磁盘都恢复到其原来的位置。接着，对重新配置执行重新引导，或者运行以下命令（作为单个命令）：
/usr/sbin/devfsadm && /usr/sbin/metadevadm -r
在完成这些命令之后，错误状态将得以解决。
请与技术支持代表联系以寻求帮助。

注 –
此错误状态极少出现。如果确实出现了，则很有可能会影响与光纤通道连接的存储器。

升级到 Solaris 10 发行版之后设备 ID 的改变

从 Solaris 10 发行版开始，设备 ID 的输出以新格式显示。Solaris Volume Manager 可以用新旧两种格式显示设备 ID 输出，具体情况取决于设备 ID 信息是何时添加到状态数据库副本中的。

以前，设备 ID 显示为十六进制值。新的格式将设备 ID 显示为 ASCII 字符串。在许多情况下，这种变化极其微小，如以下示例所示：

旧格式：: id1,ssd@w600c0ff00000000007ecd255a9336d00
新格式：: id1,ssd@n600c0ff00000000007ecd255a9336d00

在其他情况下，这种变化较为显著，如以下示例所示：

旧格式：: id1,sd@w4849544143484920444b3332454a2d33364e4320202020203433334239383939
新格式：: id1,ssd@n600c0ff00000000007ecd255a9336d00

在升级到 Solaris 10 发行版时，与以前的 Solaris 发行版中创建的现存磁盘集相关联的设备 ID 的格式，在 Solaris Volume Manager 配置中不会进行更新。如果需要恢复到以前的 Solaris 发行版，那么，在升级之后对磁盘集进行的配置更改在以前的发行版中可能会不可用。这些配置更改包括：

向升级之前存在的磁盘集内添加新磁盘
创建新磁盘集
创建状态数据库副本

这些配置更改可能会影响所有能够在 Solaris Volume Manager 中创建的磁盘集，包括本地集。例如，如果对 Solaris 10 发行版中创建的磁盘集进行了上述任何更改，就不能将该磁盘集导入到以前的 Solaris 发行版中。另一个示例是，您可能会将镜像根的一面升级到 Solaris 10 发行版，然后对本地集进行配置更改。如果随后将该子镜像又重新合并到以前的 Solaris 发行版中，系统将无法识别这些更改。

Solaris 10 OS 配置总是以新格式显示设备 ID，即便是在升级期间也是如此。可以使用 prtconf -v 命令来显示此信息。而 Solaris Volume Manager 会以旧格式或新格式显示，具体情况取决于在开始使用该磁盘时所运行的 Solaris OS 的版本。要确定 Solaris Volume Manager 所显示的设备 ID 是否与 Solaris OS 配置中的设备 ID 格式不同但等效，请将 metastat 命令的输出与 prtconf -v 命令的输出进行比较。

在以下示例中，对于同一个磁盘 c1t6d0，metastat 命令输出中显示的设备 ID 与 prtconf -v 命令输出中的设备 ID 格式不同但等效。

# metastat

d127: Concat/Stripe

    Size: 17629184 blocks (8.4 GB)

    Stripe 0:

        Device     Start Block  Dbase   Reloc

        c1t6d0s2      32768     Yes     Yes



Device Relocation Information:

Device   Reloc  Device ID c1t6d0   Yes    id1,sd@w4849544143484920444b3332454a2d33364e4320202020203433334239383939

# prtconf -v

.(output truncated)



.

.

sd, instance #6

         System properties:

              name='lun' type=int items=1

                 value=00000000

              name='target' type=int items=1

                 value=00000006

              name='class' type=string items=1

                 value='scsi'

         Driver properties:

              name='pm-components' type=string items=3 dev=none

                 value='NAME=spindle-motor' + '0=off' + '1=on'

              name='pm-hardware-state' type=string items=1 dev=none

                 value='needs-suspend-resume'

              name='ddi-failfast-supported' type=boolean dev=none

              name='ddi-kernel-ioctl' type=boolean dev=none

              Hardware properties:

              name='devid' type=string items=1

                 value='id1,@THITACHI_DK32EJ-36NC_____433B9899'

.

.

.

(output truncated)

prtconf -v 命令输出中包含 "instance #6" 的行与 metastat 命令输出中的磁盘 c1t6d0 相关联。prtconf -v 命令输出中的设备 ID (id1,@THITACHI_DK32EJ-36NC_____433B9899) 与 metastat 命令输出中的设备 ID (id1,sd@w4849544143484920444b3332454a2d33364e4320202020203433334239383939) 相关联。这两个命令输出之间的区别表明，Solaris Volume Manager 在 metastat 命令的输出中以十六进制格式显示设备 ID，而 Solaris 10 OS 配置在 prtconf 命令的输出中以 ASCII 字符串的形式显示设备 ID。

从引导问题中恢复

由于 Solaris Volume Manager 允许您镜像根 (/)、swap 和 /usr 目录，因此在引导系统时可能会出现特殊问题。硬件故障或操作员错误都有可能引起这些问题。本节中的过程提供了针对类似潜在问题的解决方案。

下表描述了这些问题并介绍了相应的解决方案。

表 25–1 Solaris Volume Manager 的常见引导问题


出现引导问题的原因	参考
`/etc/vfstab` 文件中包含错误的信息。	如何从错误的 `/etc/vfstab` 项中恢复
未定义足够的状态数据库副本。	如何从状态数据库副本不足中恢复
引导设备（磁盘）出现故障。	如何从引导设备故障中恢复

有关引导问题的背景信息

如果 Solaris Volume Manager 由于错误而使卷脱机，请取消挂载出现故障的磁盘上的所有文件系统。

由于磁盘上的每个片都是相互独立的，因此可以在一个磁盘上挂载多个文件系统。如果软件遇到了故障，则同一个磁盘上的其他片将有可能很快遇到故障。直接在磁盘片上挂载的文件系统不具有 Solaris Volume Manager 错误处理保护功能。如果使这样的文件系统保持挂载，则很可能会出现系统崩溃和数据丢失的情况。
请尽可能缩短使用已禁用或处于脱机状态的子镜像运行的时间。在重新同步过程中和联机备份间隔期间，镜像将失去所有的保护。

如何从错误的 `/etc/vfstab` 项中恢复

如果在 /etc/vfstab 文件中创建了一个错误的项（例如，在镜像根 (/) 文件系统时），系统最初看起来在正确引导，但随后会失败。要解决此问题，需要在单用户模式下编辑 /etc/vfstab 文件。

下面是从 /etc/vfstab 文件中错误的项进行恢复所需的概括性步骤：

在单用户模式下引导系统
针对镜像卷运行 fsck 命令
重新挂载文件系统并启用读写选项
可选：针对根 (/) 镜像运行 metaroot 命令
验证 /etc/vfstab 文件是否能够正确地引用与该文件系统项相对应的卷
重新引导系统

从根 (`/`) RAID-1（镜像）卷中恢复

在以下示例中，根 (/) 文件系统是用双向镜像 d0 镜像的。/etc/vfstab 文件中的根 (/) 项由于某种原因而恢复到文件系统的原始片。但是，/etc/system 文件中的信息仍显示为从镜像 d0 引导。最有可能的原因就是，没有使用 metaroot 命令来维护 /etc/system 和 /etc/vfstab 文件。另一个可能的原因就是，将 /etc/vfstab 文件的旧副本又重新复制到当前的 /etc/vfstab 文件中。

错误的 /etc/vfstab 文件与以下信息类似：

#device        device          mount          FS      fsck   mount    mount

#to mount      to fsck         point          type    pass   at boot  options

#

/dev/dsk/c0t3d0s0 /dev/rdsk/c0t3d0s0  /       ufs      1     no       -

/dev/dsk/c0t3d0s1 -                   -       swap     -     no       -

/dev/dsk/c0t3d0s6 /dev/rdsk/c0t3d0s6  /usr    ufs      2     no       -

#

/proc             -                  /proc    proc     -     no       -

swap              -                  /tmp     tmpfs    -     yes      -

由于出现错误，您将在系统引导时自动进入单用户模式：

ok boot

...

configuring network interfaces: hme0.

Hostname: host1

mount: /dev/dsk/c0t3d0s0 is not this fstype.

setmnt: Cannot open /etc/mnttab for writing



INIT: Cannot create /var/adm/utmp or /var/adm/utmpx



INIT: failed write of utmpx entry:"  "



INIT: failed write of utmpx entry:"  "



INIT: SINGLE USER MODE



Type Ctrl-d to proceed with normal startup,

(or give root password for system maintenance): <root-password>

此时，根 (/) 和 /usr 文件系统都以只读方式挂载。请按照以下步骤操作：

针对根 (/) 镜像运行 fsck 命令。

注 –

注意使用根 (/) 镜像的正确的卷。

# fsck /dev/md/rdsk/d0

** /dev/md/rdsk/d0

** Currently Mounted on /

** Phase 1 - Check Blocks and Sizes

** Phase 2 - Check Pathnames

** Phase 3 - Check Connectivity

** Phase 4 - Check Reference Counts

** Phase 5 - Check Cyl groups

2274 files, 11815 used, 10302 free (158 frags, 1268 blocks,

0.7% fragmentation)

重新以读/写方式挂载根 (/) 文件系统，以便您可以编辑 /etc/vfstab 文件。

# mount -o rw,remount /dev/md/dsk/d0 /

mount: warning: cannot lock temp file </etc/.mnt.lock>

运行 metaroot 命令。
# metaroot d0
此命令会编辑 /etc/system 和 /etc/vfstab 文件，以便指定根 (/) 文件系统现在位于 d0 卷上。

验证 /etc/vfstab 文件是否包含正确的卷项。

/etc/vfstab 文件中的根 (/) 项应如下所示，从而使文件系统的项可以正确地引用 RAID-1 卷：

#device           device              mount    FS      fsck   mount   mount

#to mount         to fsck             point    type    pass   at boot options

#

/dev/md/dsk/d0    /dev/md/rdsk/d0     /        ufs     1      no      -

/dev/dsk/c0t3d0s1 -                   -        swap    -      no      -

/dev/dsk/c0t3d0s6 /dev/rdsk/c0t3d0s6  /usr     ufs     2      no      -

#

/proc             -                  /proc     proc    -      no      -

swap              -                  /tmp      tmpfs   -      yes     -

重新引导系统。

系统将恢复到正常的运行状态。

如何从引导设备故障中恢复

如果您有一个根 (/) 镜像，那么，当引导设备出现故障时，您需要设置备用引导设备。

以下是此任务的概括性步骤：

从备用根 (/) 子镜像中引导
确定出现错误的状态数据库副本和卷
修理出现故障的磁盘
将状态数据库副本和卷恢复到其原始状态

最初，当引导设备出现故障时，您将看到一条与以下示例类似的消息。该消息可能会因体系结构而异。

Rebooting with command:

Boot device: /iommu/sbus/dma@f,81000/esp@f,80000/sd@3,0   

The selected SCSI device is not responding

Can't open boot device

...

在看到此消息时，请记下该设备。然后按照以下步骤操作：

从另一个根 (/) 子镜像引导。

此示例中共有六个状态数据库副本，由于只有两个副本出现错误，因此仍可以引导系统。如果不是这种情况，则需要在单用户模式下删除不可访问的状态数据库副本。此过程在如何从状态数据库副本不足中恢复中介绍。

在为根 (/) 文件系统创建镜像时，应在执行过程时记录备用根设备。在此示例中，disk2 是需要记录的备用根设备。

ok boot disk2

SunOS Release 5.9 Version s81_51 64-bit

Copyright 1983-2001 Sun Microsystems, Inc.  All rights reserved.

Hostname: demo

...

demo console login: root

Password: <root-password>

Dec 16 12:22:09 host1 login: ROOT LOGIN /dev/console

Last login: Wed Dec 12 10:55:16 on console

Sun Microsystems Inc.   SunOS 5.9       s81_51  May 2002

...

使用 metadb 命令来确定有多少个状态数据库副本失败。

# metadb

       flags         first blk    block count

    M     p          unknown      unknown      /dev/dsk/c0t3d0s3

    M     p          unknown      unknown      /dev/dsk/c0t3d0s3

    a m  p  luo      16           1034         /dev/dsk/c0t2d0s3

    a    p  luo      1050         1034         /dev/dsk/c0t2d0s3

    a    p  luo      16           1034         /dev/dsk/c0t1d0s3

    a    p  luo      1050         1034         /dev/dsk/c0t1d0s3

在此示例中，系统无法再在 /dev/dsk/c0t3d0s3 片上检测状态数据库副本，该片位于出现故障的磁盘上。

使用 metastat 命令确定根 (/)、swap 和 /usr 镜像的一半是否已失败。

# metastat

d0: Mirror

    Submirror 0: d10

      State: Needs maintenance

    Submirror 1: d20

      State: Okay

...

 

d10: Submirror of d0

    State: Needs maintenance

    Invoke: "metareplace d0 /dev/dsk/c0t3d0s0 <new device>"

    Size: 47628 blocks

    Stripe 0:

	Device              Start Block  Dbase State        Hot Spare

	/dev/dsk/c0t3d0s0          0     No    Maintenance 

 

d20: Submirror of d0

    State: Okay

    Size: 47628 blocks

    Stripe 0:

	Device              Start Block  Dbase State        Hot Spare

	/dev/dsk/c0t2d0s0          0     No    Okay  

 

d1: Mirror

    Submirror 0: d11

      State: Needs maintenance

    Submirror 1: d21

      State: Okay

...

 

d11: Submirror of d1

    State: Needs maintenance

    Invoke: "metareplace d1 /dev/dsk/c0t3d0s1 <new device>"

    Size: 69660 blocks

    Stripe 0:

	Device              Start Block  Dbase State        Hot Spare

	/dev/dsk/c0t3d0s1          0     No    Maintenance 

 

d21: Submirror of d1

    State: Okay

    Size: 69660 blocks

    Stripe 0:

	Device              Start Block  Dbase State        Hot Spare

	/dev/dsk/c0t2d0s1          0     No    Okay        

 

d2: Mirror

    Submirror 0: d12

      State: Needs maintenance

    Submirror 1: d22

      State: Okay

...

 

d12: Submirror of d2

    State: Needs maintenance

    Invoke: "metareplace d2 /dev/dsk/c0t3d0s6 <new device>"

    Size: 286740 blocks

    Stripe 0:

	Device              Start Block  Dbase State        Hot Spare

	/dev/dsk/c0t3d0s6          0     No    Maintenance 

 

 

d22: Submirror of d2

    State: Okay

    Size: 286740 blocks

    Stripe 0:

	Device              Start Block  Dbase State        Hot Spare

	/dev/dsk/c0t2d0s6          0     No    Okay

在此示例中，metastat 命令显示以下子镜像需要维护：

位于设备 c0t3d0s0 上的子镜像 d10
位于设备 c0t3d0s1 上的子镜像 d11
位于设备 c0t3d0s6 上的子镜像 d12

停止系统，然后替换磁盘。使用 format 命令或 fmthard 命令按照磁盘在出现故障之前的状态对磁盘进行分区。

提示 –
如果新磁盘与现有的磁盘相同（在此示例中为镜像中保持不变的一面），请快速格式化新磁盘。为此，请使用 prtvtoc /dev/rdsk/c0t2d0s2 | fmthard -s - /dev/rdsk/c0t3d0s2 命令（在此示例中为 c0t3d0）。
# halt ... Halted ... ok boot ... # format /dev/rdsk/c0t3d0s0

重新引导系统。

请注意，必须从根 (/) 镜像的另一半重新引导。在创建镜像时，应当已经记录了备用根设备。
# halt ... ok boot disk2

要删除失败的状态数据库副本并重新添加它们，请使用 metadb 命令。

# metadb

       flags         first blk    block count

    M     p          unknown      unknown      /dev/dsk/c0t3d0s3

    M     p          unknown      unknown      /dev/dsk/c0t3d0s3

    a m  p  luo      16           1034         /dev/dsk/c0t2d0s3

    a    p  luo      1050         1034         /dev/dsk/c0t2d0s3

    a    p  luo      16           1034         /dev/dsk/c0t1d0s3

    a    p  luo      1050         1034         /dev/dsk/c0t1d0s3

# metadb -d c0t3d0s3

# metadb -c 2 -a c0t3d0s3

# metadb

       flags         first blk    block count

     a m  p  luo     16           1034         /dev/dsk/c0t2d0s3

     a    p  luo     1050         1034         /dev/dsk/c0t2d0s3

     a    p  luo     16           1034         /dev/dsk/c0t1d0s3

     a    p  luo     1050         1034         /dev/dsk/c0t1d0s3

     a        u      16           1034         /dev/dsk/c0t3d0s3

     a        u      1050         1034         /dev/dsk/c0t3d0s3

使用 metareplace 命令重新启用子镜像。

# metareplace -e d0 c0t3d0s0

Device /dev/dsk/c0t3d0s0 is enabled

 

# metareplace -e d1 c0t3d0s1

Device /dev/dsk/c0t3d0s1 is enabled

 

# metareplace -e d2 c0t3d0s6

Device /dev/dsk/c0t3d0s6 is enabled

在一段时间之后，重新同步将完成。现在可以返回到从原始设备引导。

从状态数据库副本故障中恢复

如果无法满足状态数据库副本定额（例如，由于驱动器故障），则系统无法重新引导到多用户模式下。当 Solaris Volume Manager 发现可用的状态数据库副本不足一半时，则会崩溃。如果系统是使用恰好一半或者少于一半的功能状态数据库副本重新引导的，也可能会出现这种情况。在 Solaris Volume Manager 术语中，状态数据库已变得“过时”。此过程解释如何从该问题中恢复。

如何从状态数据库副本不足中恢复

引导系统。

确定哪些状态数据库副本不可用。
# metadb -i

如果已知有一个或多个磁盘不可用，请删除这些磁盘上的状态数据库副本。否则，请删除足够数量的错误的状态数据库副本（由 metadb 报告的标有 W、M、D、F 或 R 状态标志的数据库副本），以确保现有状态数据库副本中的大多数都没有错误。
# metadb -d disk-slice
提示 –
带有大写状态标志的状态数据库副本有错误，带有小写状态标志的状态数据库副本可以正常工作。

验证副本是否已删除。
# metadb

重新引导系统。
# reboot

如有必要，请替换磁盘，正确格式化该磁盘，然后添加该磁盘所需的任何状态数据库副本。

请按照创建状态数据库副本中的说明操作。

在拥有替换磁盘之后，停止系统，替换出现故障的磁盘，然后再次重新引导系统。使用 format 命令或 fmthard 命令按照磁盘在出现故障之前的状态对磁盘进行分区。

示例 25–1 从过时的状态数据库副本中恢复

在以下示例中，包含七个副本的磁盘已经出现错误。因此，系统只有三个良好的副本。系统将崩溃，因而无法重新引导到多用户模式下。

panic[cpu0]/thread=70a41e00: md: state database problem



403238a8 md:mddb_commitrec_wrapper+6c (2, 1, 70a66ca0, 40323964, 70a66ca0, 3c)

  %l0-7: 0000000a 00000000 00000001 70bbcce0 70bbcd04 70995400 00000002 00000000

40323908 md:alloc_entry+c4 (70b00844, 1, 9, 0, 403239e4, ff00)

  %l0-7: 70b796a4 00000001 00000000 705064cc 70a66ca0 00000002 00000024 00000000

40323968 md:md_setdevname+2d4 (7003b988, 6, 0, 63, 70a71618, 10)

  %l0-7: 70a71620 00000000 705064cc 70b00844 00000010 00000000 00000000 00000000

403239f8 md:setnm_ioctl+134 (7003b968, 100003, 64, 0, 0, ffbffc00)

  %l0-7: 7003b988 00000000 70a71618 00000000 00000000 000225f0 00000000 00000000

40323a58 md:md_base_ioctl+9b4 (157ffff, 5605, ffbffa3c, 100003, 40323ba8, ff1b5470)

  %l0-7: ff3f2208 ff3f2138 ff3f26a0 00000000 00000000 00000064 ff1396e9 00000000

40323ad0 md:md_admin_ioctl+24 (157ffff, 5605, ffbffa3c, 100003, 40323ba8, 0)

  %l0-7: 00005605 ffbffa3c 00100003 0157ffff 0aa64245 00000000 7efefeff 81010100

40323b48 md:mdioctl+e4 (157ffff, 5605, ffbffa3c, 100003, 7016db60, 40323c7c)

  %l0-7: 0157ffff 00005605 ffbffa3c 00100003 0003ffff 70995598 70995570 0147c800

40323bb0 genunix:ioctl+1dc (3, 5605, ffbffa3c, fffffff8, ffffffe0, ffbffa65)

  %l0-7: 0114c57c 70937428 ff3f26a0 00000000 00000001 ff3b10d4 0aa64245 00000000



panic: 

stopped at      edd000d8:       ta      %icc,%g0 + 125

Type  'go' to resume



ok boot -s

Resetting ... 



Sun Ultra 5/10 UPA/PCI (UltraSPARC-IIi 270MHz), No Keyboard

OpenBoot 3.11, 128 MB memory installed, Serial #9841776.

Ethernet address 8:0:20:96:2c:70, Host ID: 80962c70.







Rebooting with command: boot -s                                       

Boot device: /pci@1f,0/pci@1,1/ide@3/disk@0,0:a  File and args: -s

SunOS Release 5.9 Version s81_39 64-bit



Copyright 1983-2001 Sun Microsystems, Inc.  All rights reserved.

configuring IPv4 interfaces: hme0.

Hostname: dodo



metainit: dodo: stale databases



Insufficient metadevice database replicas located.



Use metadb to delete databases which are broken.

Ignore any "Read-only file system" error messages.

Reboot the system when finished to reload the metadevice database.

After reboot, repair any broken database replicas which were deleted.



Type control-d to proceed with normal startup,

(or give root password for system maintenance): root-password

single-user privilege assigned to /dev/console.

Entering System Maintenance Mode



Jun  7 08:57:25 su: 'su root' succeeded for root on /dev/console

Sun Microsystems Inc.   SunOS 5.9       s81_39  May 2002

# metadb -i

        flags           first blk       block count

     a m  p  lu         16              8192            /dev/dsk/c0t0d0s7

     a    p  l          8208            8192            /dev/dsk/c0t0d0s7

     a    p  l          16400           8192            /dev/dsk/c0t0d0s7

    M     p             16              unknown         /dev/dsk/c1t1d0s0

    M     p             8208            unknown         /dev/dsk/c1t1d0s0

    M     p             16400           unknown         /dev/dsk/c1t1d0s0

    M     p             24592           unknown         /dev/dsk/c1t1d0s0

    M     p             32784           unknown         /dev/dsk/c1t1d0s0

    M     p             40976           unknown         /dev/dsk/c1t1d0s0

    M     p             49168           unknown         /dev/dsk/c1t1d0s0

# metadb -d c1t1d0s0

# metadb

        flags           first blk       block count

     a m  p  lu         16              8192            /dev/dsk/c0t0d0s7

     a    p  l          8208            8192            /dev/dsk/c0t0d0s7

     a    p  l          16400           8192            /dev/dsk/c0t0d0s7

#

系统之所以会崩溃，是因为它无法再检查 /dev/dsk/c1t1d0s0 片上的状态数据库副本。该片位于出现故障的磁盘上或者该片已附加到出现故障的控制器。第一个 metadb - i 命令将该片上的副本标识为主块有问题。

当您删除过时的状态数据库副本时，根 (/) 文件系统是只读的。可以忽略所显示的 mddb.cf 错误消息。

此时，系统将重新正常工作，尽管它的状态数据库副本数目有可能比应有的少。如果卷使用已出现故障的存储器的一部分，则其状态同样为有故障的、有错误的或热备用的。这些问题应当立即解决。

从软分区问题中恢复

本节介绍如何恢复软分区的配置信息。只有当所有的状态数据库副本已丢失，而且没有下列信息之一时，才应当使用以下过程：

metastat -p 输出的当前副本或准确副本
md.cf 文件的当前副本或准确副本
最新的 md.tab 文件

如何恢复软分区的配置数据

在每个软分区扩展盘区的开头，有一个用于标记软分区扩展盘区的开头的扇区。这些隐藏的扇区称为分区扩展表头。软分区的用户看不到这些标头。如果所有的 Solaris Volume Manager 配置数据已丢失，则可以对磁盘进行扫描以尝试生成配置数据。

不到万不得已，不要使用此过程来恢复所丢失的软分区配置信息。只有当 metadb 和 md.cf 文件均丢失，而且 md.tab 文件已过时或者已丢失时，才应当使用 metarecover 命令。

注 –

此过程仅适用于恢复软分区信息，而不适用于从丢失其他配置中进行恢复或者恢复其他 Solaris Volume Manager 卷的配置信息。

注 –

如果配置中包括在软分区之上构建的其他 Solaris Volume Manager 卷，则应当在尝试恢复其他卷之前恢复软分区。

有关软分区的配置信息存储在设备上和状态数据库中。由于这两个源都有可能会损坏，因此必须向 metarecover 命令指示哪个源可靠。

首先，使用 metarecover 命令来确定这两个源是否一致。如果它们一致，就不能使用 metarecover 命令进行任何更改。但是，如果 metarecover 命令报告存在不一致，则必须认真检查它的输出，以确定磁盘或状态数据库是否已经损坏。然后，应当使用 metarecover 命令来基于适当的源重新构建配置。

请阅读软分区的配置指南。

使用 metarecover 命令检查软分区的恢复信息。
# metarecover component-p -d
component

指定原始组件的 cntndnsn 名称

-p

指定要重新生成软分区

-d

指定要扫描软分区上分区扩展表头的物理片

示例 25–2 从磁盘上的分区扩展表头中恢复软分区

# metarecover c1t1d0s1 -p -d

The following soft partitions were found and will be added to

your metadevice configuration.

 Name            Size     No. of Extents

    d10           10240         1

    d11           10240         1

    d12           10240         1

# metarecover c1t1d0s1 -p -d

The following soft partitions were found and will be added to

your metadevice configuration.

 Name            Size     No. of Extents

    d10           10240         1

    d11           10240         1

    d12           10240         1

WARNING: You are about to add one or more soft partition

metadevices to your metadevice configuration.  If there

appears to be an error in the soft partition(s) displayed

above, do NOT proceed with this recovery operation.

Are you sure you want to do this (yes/no)?yes

c1t1d0s1: Soft Partitions recovered from device.

bash-2.05# metastat

d10: Soft Partition

    Device: c1t1d0s1

    State: Okay

    Size: 10240 blocks

        Device              Start Block  Dbase Reloc

        c1t1d0s1                   0     No    Yes



        Extent              Start Block              Block count

             0                        1                    10240



d11: Soft Partition

    Device: c1t1d0s1

    State: Okay

    Size: 10240 blocks

        Device              Start Block  Dbase Reloc

        c1t1d0s1                   0     No    Yes



        Extent              Start Block              Block count

             0                    10242                    10240



d12: Soft Partition

    Device: c1t1d0s1

    State: Okay

    Size: 10240 blocks

        Device              Start Block  Dbase Reloc

        c1t1d0s1                   0     No    Yes



        Extent              Start Block              Block count

             0                    20483                    10240

在此示例中，在意外删除状态数据库副本之后，从磁盘中恢复三个软分区。

从另一个系统中恢复存储

甚至可以将 Solaris Volume Manager 配置从原始系统恢复到另一个系统上。

如何从本地磁盘集恢复存储

如果遇到系统故障，则可以将存储器连接到另一个系统，并从本地磁盘集恢复完整的配置。例如，假设系统中有一个由六个磁盘组成的外部磁盘组，某些磁盘上具有 Solaris Volume Manager 配置（至少包括一个状态数据库副本）。如果系统出现故障，则可以将这个磁盘组以物理方式移到新系统中，并使新系统能够识别该配置。此过程说明如何将磁盘移到另一个系统以及如何从本地磁盘集恢复配置。

注 –

此恢复过程仅适用于 Solaris 9 和更高版本的 Solaris Volume Manager 卷。

将包含 Solaris Volume Manager 配置的磁盘连接到原本没有 Solaris Volume Manager 配置的系统。

执行重新配置重新引导，以确保系统能够识别新添加的磁盘。
# reboot -- -r

确定新添加磁盘上包含状态数据库副本的片的主设备号/从设备号。

运行 ls -lL，并记下组名和日期之间的两个数字。这些数字就是该片的主设备号/从设备号。
# ls -Ll /dev/dsk/c1t9d0s7 brw-r----- 1 root sys 32, 71 Dec 5 10:05 /dev/dsk/c1t9d0s7

如有必要，请通过在 /etc/name_to_major 中查找主设备号来确定与主设备号相对应的主设备名称。
# grep " 32" /etc/name_to_major sd 32

用指示 Solaris Volume Manager 在新磁盘上查找有效状态数据库副本的位置信息来更新 /kernel/drv/md.conf 文件。

例如，在以 mddb_bootlist1 开头的行中，用在步骤 4 中找到的主设备名称替换 sd。在此示例中，用在步骤 3 中标识的从设备号替换 71。

#pragma ident   "@(#)md.conf    2.2     04/04/02 SMI"

#

# Copyright 2004 Sun Microsystems, Inc.  All rights reserved.

# Use is subject to license terms.

#

# The parameters nmd and md_nsets are obsolete.  The values for these

# parameters no longer have any meaning.

name="md" parent="pseudo" nmd=128 md_nsets=4;



# Begin MDD database info (do not edit)

mddb_bootlist1="sd:71:16:id0";

# End MDD database info (do not edit)

重新引导以强制 Solaris Volume Manager 重新装入配置。

将看到的消息与在控制台上显示的以下消息类似：

volume management starting.

Dec  5 10:11:53 host1 metadevadm: Disk movement detected

Dec  5 10:11:53 host1 metadevadm: Updating device names in 

Solaris Volume Manager

The system is ready.

检验您的配置。使用 metadb 命令检验状态数据库副本的状态，使用 metastat 命令查看每个卷的状态。

# metadb

        flags           first blk       block count

     a m  p  luo        16              8192            /dev/dsk/c1t9d0s7

     a       luo        16              8192            /dev/dsk/c1t10d0s7

     a       luo        16              8192            /dev/dsk/c1t11d0s7

     a       luo        16              8192            /dev/dsk/c1t12d0s7

     a       luo        16              8192            /dev/dsk/c1t13d0s7

# metastat

d12: RAID

    State: Okay         

    Interlace: 32 blocks

    Size: 125685 blocks

Original device:

    Size: 128576 blocks

        Device              Start Block  Dbase State        Reloc  Hot Spare

        c1t11d0s3                330     No    Okay         Yes    

        c1t12d0s3                330     No    Okay         Yes    

        c1t13d0s3                330     No    Okay         Yes    



d20: Soft Partition

    Device: d10

    State: Okay

    Size: 8192 blocks

        Extent              Start Block              Block count

             0                     3592                     8192



d21: Soft Partition

    Device: d10

    State: Okay

    Size: 8192 blocks

        Extent              Start Block              Block count

             0                    11785                     8192



d22: Soft Partition

    Device: d10

    State: Okay

    Size: 8192 blocks

        Extent              Start Block              Block count

             0                    19978                     8192



d10: Mirror

    Submirror 0: d0

      State: Okay         

    Submirror 1: d1

      State: Okay         

    Pass: 1

    Read option: roundrobin (default)

    Write option: parallel (default)

    Size: 82593 blocks



d0: Submirror of d10

    State: Okay         

    Size: 118503 blocks

    Stripe 0: (interlace: 32 blocks)

        Device              Start Block  Dbase State        Reloc  Hot Spare

        c1t9d0s0                   0     No    Okay         Yes    

        c1t10d0s0               3591     No    Okay         Yes    





d1: Submirror of d10

    State: Okay         

    Size: 82593 blocks

    Stripe 0: (interlace: 32 blocks)

        Device              Start Block  Dbase State        Reloc  Hot Spare

        c1t9d0s1                   0     No    Okay         Yes    

        c1t10d0s1                  0     No    Okay         Yes    





Device Relocation Information:

Device       Reloc    Device ID

c1t9d0       Yes      id1,sd@SSEAGATE_ST39103LCSUN9.0GLS3487980000U00907AZ

c1t10d0      Yes      id1,sd@SSEAGATE_ST39103LCSUN9.0GLS3397070000W0090A8Q

c1t11d0      Yes      id1,sd@SSEAGATE_ST39103LCSUN9.0GLS3449660000U00904NZ

c1t12d0      Yes      id1,sd@SSEAGATE_ST39103LCSUN9.0GLS32655400007010H04J

c1t13d0      Yes      id1,sd@SSEAGATE_ST39103LCSUN9.0GLS3461190000701001T0

# 

# metadb         

        flags           first blk       block count

     a m  p  luo        16              8192            /dev/dsk/c1t9d0s7

     a       luo        16              8192            /dev/dsk/c1t10d0s7

     a       luo        16              8192            /dev/dsk/c1t11d0s7

     a       luo        16              8192            /dev/dsk/c1t12d0s7

     a       luo        16              8192            /dev/dsk/c1t13d0s7

# metastat 

d12: RAID

    State: Okay         

    Interlace: 32 blocks

    Size: 125685 blocks

Original device:

    Size: 128576 blocks

        Device              Start Block  Dbase State        Reloc  Hot Spare

        c1t11d0s3                330     No    Okay         Yes    

        c1t12d0s3                330     No    Okay         Yes    

        c1t13d0s3                330     No    Okay         Yes    



d20: Soft Partition

    Device: d10

    State: Okay

    Size: 8192 blocks

        Extent              Start Block              Block count

             0                     3592                     8192



d21: Soft Partition

    Device: d10

    State: Okay

    Size: 8192 blocks

        Extent              Start Block              Block count

             0                    11785                     8192



d22: Soft Partition

    Device: d10

    State: Okay

    Size: 8192 blocks

        Extent              Start Block              Block count

             0                    19978                     8192



d10: Mirror

    Submirror 0: d0

      State: Okay         

    Submirror 1: d1

      State: Okay         

    Pass: 1

    Read option: roundrobin (default)

    Write option: parallel (default)

    Size: 82593 blocks



d0: Submirror of d10

    State: Okay         

    Size: 118503 blocks

    Stripe 0: (interlace: 32 blocks)

        Device              Start Block  Dbase State        Reloc  Hot Spare

        c1t9d0s0                   0     No    Okay         Yes    

        c1t10d0s0               3591     No    Okay         Yes    





d1: Submirror of d10

    State: Okay         

    Size: 82593 blocks

    Stripe 0: (interlace: 32 blocks)

        Device              Start Block  Dbase State        Reloc  Hot Spare

        c1t9d0s1                   0     No    Okay         Yes    

        c1t10d0s1                  0     No    Okay         Yes    





Device Relocation Information:

Device         Reloc    Device ID

c1t9d0         Yes     id1,sd@SSEAGATE_ST39103LCSUN9.0GLS3487980000U00907AZ1

c1t10d0        Yes     id1,sd@SSEAGATE_ST39103LCSUN9.0GLS3397070000W0090A8Q

c1t11d0        Yes     id1,sd@SSEAGATE_ST39103LCSUN9.0GLS3449660000U00904NZ

c1t12d0        Yes     id1,sd@SSEAGATE_ST39103LCSUN9.0GLS32655400007010H04J

c1t13d0        Yes     id1,sd@SSEAGATE_ST39103LCSUN9.0GLS3461190000701001T0

# metastat -p

d12 -r c1t11d0s3 c1t12d0s3 c1t13d0s3 -k -i 32b

d20 -p d10 -o 3592 -b 8192 

d21 -p d10 -o 11785 -b 8192 

d22 -p d10 -o 19978 -b 8192 

d10 -m d0 d1 1

d0 1 2 c1t9d0s0 c1t10d0s0 -i 32b

d1 1 2 c1t9d0s1 c1t10d0s1 -i 32b

#

从已知的磁盘集恢复存储

在 Solaris Volume Manager 中引入了对磁盘集设备 ID 的支持，这允许您从已知的磁盘集恢复存储并将该磁盘集导入到其他系统。使用 metaimport 命令，可以将已知的磁盘集从一个系统导入到另一个系统。这两个系统都必须包含现有的 Solaris Volume Manager 配置（包括设备 ID 支持）。有关设备 ID 支持的更多信息，请参见磁盘集中的异步共享存储。有关 metaimport 命令的更多信息，请参见 metaimport(1M) 手册页。

如何列显有关可导入的磁盘集的报告

成为超级用户。

获取有关要导入的磁盘集的报告。
# metaimport -r -v
-r

提供可导入到系统上的未配置磁盘集的报告。

-v

提供有关以下内容的详细信息：状态数据库副本的位置；可导入到系统上的未配置磁盘集的磁盘状态。

示例 25–3 报告可导入的磁盘集

以下示例说明如何列显有关可导入的磁盘集的报告。

# metaimport -r

 Drives in regular diskset including disk c1t2d0:

   c1t2d0

   c1t3d0

 More info:

   metaimport -r -v c1t2d0 

Import:   metaimport -s <newsetname> c1t2d0 

 Drives in replicated diskset including disk c1t4d0:

   c1t4d0

   c1t5d0

 More info:

   metaimport -r -v c1t4d0 

Import:   metaimport -s <newsetname> c1t4d0




# metaimport -r -v c1t2d0

Import: metaimport -s <newsetname> c1t2d0

Last update: Mon Dec 29 14:13:35 2003

Device       offset       length replica flags

c1t2d0           16         8192      a        u     

c1t3d0           16         8192      a        u     

c1t8d0           16         8192      a        u

如何将磁盘集从一个系统导入到另一个系统

成为超级用户。

验证磁盘集是否可以导入。
# metaimport -r -v

导入可用的磁盘集。
# metaimport -s diskset-name drive-name
- s diskset-name

指定所创建的磁盘集的名称。

drive-name

标识正在导入的磁盘集中包含状态数据库副本的磁盘 (c#t#d#)。

验证该磁盘集是否已导入。
# metaset -s diskset-name

示例 25–4 导入磁盘集

以下示例说明如何导入磁盘集。

# metaimport -s red c1t2d0

Drives in diskset including disk c1t2d0:

  c1t2d0

  c1t3d0

  c1t8d0

More info:   metaimport -r -v c1t2d0# metaset -s red





Set name = red, Set number = 1



Host                Owner

  host1            Yes



Drive    Dbase



c1t2d0   Yes  



c1t3d0   Yes  



c1t8d0   Yes

从磁盘集问题中恢复

本节详述如何从与特定的磁盘集相关的问题中恢复。

无法获取磁盘集拥有权时应执行的操作

如果无法从任何节点获取磁盘集拥有权（可能由于系统故障、磁盘故障或通信链路故障），从而无法删除磁盘集记录，则可以从当前主机上的 Solaris Volume Manager 状态数据库副本记录中清除磁盘集。

清除磁盘集记录不会影响包含在磁盘集中的状态数据库信息，因此，可以在以后导入磁盘集（使用 metaimport 命令，如导入磁盘集中所述）。

如果需要从 Sun Cluster 配置中清除磁盘集，请使用以下过程，但是，在没有 Sun Cluster 配置时，应使用 -C 选项，而不要使用 -P 选项。

如何清除磁盘集

尝试使用 metaset 命令来获取磁盘集。
# metaset -s setname -t -f
此命令会尝试强制 (-f) 获取 (-t) 名为 setname 的磁盘集。如果可以获取该磁盘集，则此命令将成功。如果在运行此命令时，该磁盘集由另一个主机拥有，则另一个主机将崩溃，以防止数据损坏或丢失。如果此命令成功，则可以彻底删除该磁盘集，而无需清除它。

如果无法获取该磁盘集，则可以清除拥有权记录。

使用带 -P 的 metaset 命令从当前的主机中清除磁盘集。
# metaset -s setname -P
此命令将从运行该命令的主机中清除 (-P) 名为 setname 的磁盘集。

使用 metaset 命令验证该磁盘集是否已清除。
# metaset

示例 25–5 清除磁盘集

host1# metaset -s red -t -f

metaset: host1: setname "red": no such set

host2# metaset



Set name = red, Set number = 1



Host                Owner

  host2        



Drive    Dbase



c1t2d0   Yes  



c1t3d0   Yes  



c1t8d0   Yes  



host2# metaset -s red -P

host2# metaset

另请参见

第 18 章，磁盘集（概述）（介绍有关磁盘集的概念信息）。
第 19 章，磁盘集（任务）（介绍有关与磁盘集相关联的任务的信息）。

使用 `ufsdump` 命令对已挂载的文件系统执行备份

以下过程说明在使用 ufsdump 命令来备份 RAID-1 卷上的已挂载文件系统时，如何提高该命令的性能。

如何针对 RAID-1 卷上的已挂载文件系统执行备份

可以使用 ufsdump 命令来备份 RAID-1 卷上已挂载文件系统的文件。当备份实用程序是 ufsdump 时，请将该卷上的读取策略设置为“first（优先）”。这样可以提高备份的执行速率。

成为超级用户。

运行 metastat 命令以确保镜像处于“Okay（正常）”状态。

# metastat d40

d40: Mirror

    Submirror 0: d41

      State: Okay

    Submirror 1: d42

      State: Okay

    Pass: 1

    Read option: roundrobin (default)

    Write option: parallel (default)

    Size: 20484288 blocks (9.8 GB)

应首先修复处于“Maintenance（维护）”状态的镜像。

将镜像的读取策略设置为“first（优先）”。

# metaparam -r first d40

# metastat d40

d40: Mirror

    Submirror 0: d41

      State: Okay

    Submirror 1: d42

      State: Okay

    Pass: 1

    Read option: first

    Write option: parallel (default)

    Size: 20484288 blocks (9.8 GB)

对文件系统执行备份。
# ufsdump 0f /dev/backup /opt/test

在 ufsdump 命令完成之后，将镜像的读取策略设置为 "roundrobin"。

# metaparam -r roundrobin d40

# metastat d40

d40: Mirror

    Submirror 0: d41

      State: Okay

    Submirror 1: d42

      State: Okay

    Pass: 1

    Read option: roundrobin

    Write option: parallel (default)

    Size: 20484288 blocks (9.8 GB)

执行系统恢复

有时，从 DVD 或 CD 介质上的 Solaris OS 安装映像引导以执行系统恢复非常有用，重置 root 口令就是使用安装映像非常有用的一个示例。

如果使用的是 Solaris Volume Manager 配置，则需要挂载 Solaris Volume Manager 卷（而非基础磁盘）。如果对根 (/) 文件系统进行了镜像，则此步骤尤其重要。由于 Solaris Volume Manager 是 Solaris OS 的一部分，因此挂载 Solaris Volume Manager 卷将确保所做的更改在镜像的两面都反映出来。

使用以下过程，可以使 Solaris Volume Manager 卷能够从 Solaris OS DVD 或 CD-ROM 安装映像访问。

如何使用 Solaris Volume Manager 配置来恢复系统

从 Solaris OS 安装 DVD 或 CD 介质引导系统。从 Solaris miniroot 的 root 提示符执行此过程。

以只读方式挂载包含 Solaris Volume Manager 配置的基础磁盘。
# mount -o ro /dev/dsk/c0t0d0s0 /a

将 md.conf 文件复制到 /kernel/drv 目录中。

# cp /a/kernel/drv/md.conf /kernel/drv/md.conf

从 miniroot 挂载文件系统。
# umount /a

更新 Solaris Volume Manager 驱动程序以装入该配置。忽略由 update_drv 命令列显的任何警告消息。
# update_drv -f md

配置系统卷。
# metainit -r

如果在 Solaris Volume Manager 配置中有多个 RAID-1 卷，请将其重新同步。
# metasync mirror-name

Solaris Volume Manager 卷应当能够使用 mount 命令来访问。
# mount /dev/md/dsk/volume-name /a

示例 25–6 使用 Solaris Volume Manager 配置恢复系统

# mount -o ro /dev/dsk/c0t0d0s0 /a

# cp /a/kernel/drv/md.conf /kernel/drv/md.conf

# umount /a

# update_drv -f md

Cannot unload module: md

Will be unloaded upon reboot.

Forcing update of md.conf.

devfsadm: mkdir fialed for /dev 0xled: Read-only file system

devfsadm: inst_sync failed for /etc/path_to_inst.1359: Read-only file system

devfsadm: WARNING: failed to update /etc/path_to_inst

# metainit -r

# metasync d0

# mount /dev/md/dsk/d0 /a

第 25 章 对 Solaris Volume Manager 进行疑难解答（任务）

对 Solaris Volume Manager 进行疑难解答（任务列表）

系统疑难解答概述

对系统进行疑难解答的先决条件

对 Solaris Volume Manager 进行疑难解答的一般原则

一般疑难解答方法

替换磁盘

如何替换出现故障的磁盘

从磁盘移动问题中恢复

磁盘移动和设备 ID 概述

解决未命名设备错误

升级到 Solaris 10 发行版之后设备 ID 的改变

从引导问题中恢复

有关引导问题的背景信息

如何从错误的 /etc/vfstab 项中恢复

从根 (/) RAID-1（镜像）卷中恢复

如何从引导设备故障中恢复

从状态数据库副本故障中恢复

如何从状态数据库副本不足中恢复

示例 25–1 从过时的状态数据库副本中恢复

从软分区问题中恢复

如何恢复软分区的配置数据

示例 25–2 从磁盘上的分区扩展表头中恢复软分区

从另一个系统中恢复存储

如何从本地磁盘集恢复存储

从已知的磁盘集恢复存储

如何列显有关可导入的磁盘集的报告

示例 25–3 报告可导入的磁盘集

如何将磁盘集从一个系统导入到另一个系统

示例 25–4 导入磁盘集

从磁盘集问题中恢复

无法获取磁盘集拥有权时应执行的操作

如何清除磁盘集

示例 25–5 清除磁盘集

另请参见

使用 ufsdump 命令对已挂载的文件系统执行备份

如何针对 RAID-1 卷上的已挂载文件系统执行备份

执行系统恢复

如何使用 Solaris Volume Manager 配置来恢复系统

示例 25–6 使用 Solaris Volume Manager 配置恢复系统

第 25 章对 Solaris Volume Manager 进行疑难解答（任务）

如何从错误的 `/etc/vfstab` 项中恢复

从根 (`/`) RAID-1（镜像）卷中恢复

使用 `ufsdump` 命令对已挂载的文件系统执行备份