aix中mksysb怎么用？要备份到本地盘的。

你可以用这伍明个命令模式来把系统以文件方式裂饥备份到磁盘上：mksysb -i /dirname/filename，只要你准备用来存放文件的目腔源告录文件系统和/tmp空间都足够就可以了，当然，建立专门的文件系统也可以，lv就选jfs2，挂上去

磁盘错误分类

我使用两个主要的度量值来分类 AIX 系统上的磁盘错误：影响和持续时间。影响 所量度的是磁盘错误的影响力及其对服务器的冲击。换言之，就是 “这会造成何程度的伤害？”。持续时间 所量度的是磁盘错误持续的时长和恢复时间，即 “这伤害将持续多久？”。

影响可分为四个主要级别：

可用性丧失：当存储资源离线或断开与其管理服务器的连接时就会发生可用性丧失。虽然磁盘上的数据没有损失，但是无法访问该磁盘。例如：文件系统遭卸装或光纤通道适配器被断开连接。

数据丢失：由于逻辑或物理问题，数据无法写入磁盘或无法从磁盘读取。例如：LVM 写入错误。

跨多个磁盘的数据丢失：在这种情况下，不仅一个磁盘而庆李或是多个磁盘均遭遇了数据丢失。当逻辑卷跨磁盘条带化且其中一个磁盘故障时，常常会发生这种情况。

跨多个服务器的数据丢失：随着 SAN 技术的广泛应用，一个磁盘硬件可能受损到这样的程度：多个服务器均受到了数据丢失的影响。

同样地，持续时间也可用分为四个主要级别：

暂时：这类磁盘错误不常见且只发生一次，不会带来誉伍真正的威胁。它只在服务器的 errpt 内出现一次，然后即消失。例如：一次糟糕的块重分配。

间歇：间歇错误的出现很不规律，可以由初期问题推断，比如若硬盘记录了一系列写入错误时，往往表明此驱动器可能会出现故障。

经常：就像是由一个 cron 作业定期安排的那样，以周、天、小时或分钟为间隔发生问题，这会对服务器形成严重威胁并具有广泛的有害影响。

永久：不太容易或者根本不可能从这类错误中恢复。缺乏可替换硬件，将不能从这种情况中恢复。

通过交叉参考表中的这两个度量指标，您就能够更好地了解磁盘错误的危急程度以及它们对服务器的影响

恢复步骤

磁盘故障的影响程度不一，从轻微的中断到整个的服务器故障。那么，当遇到故障时该怎么做呢？

第一步是检查磁盘资源的可访问性，从最高可用级别开始一直往下，在需要时使用 errpt 作为指导。如果服务器仍在正常运行，那么使用 df 或 mount 命令进行查看时文件系统是否仍然存在？如果没有，是否能用 lsvg 或 varyonvg 访问卷组，或是它已丢失了配额（quorum）？磁盘本身是否仍处在 Available 状态，或者使用 lsdev –Ccdisk 命令后，是否显示它们处于的是 Defined 状态？像执行 lspath 或 pcmpath query adapter 这样的 SAN 存储命令后，这些光纤通道设备显示的是离线还是丢失？当通过 Hardware Management Console 查看时，服务器仅是宕机并处于 Not Activated 状态？大型的 System p 机器或 SAN 子系统宕机了？不要只是因为某一类资源可用而贸然做这样的假扰源设；所有类似资源都必须处于可用状态，所以务必全面检查。

第二步是检查资源的完整性，从最低的可用性等级开始向上检查。服务器是否成功引导？系统启动时是否出现故障，如带有数字 552、554、 或 556 的 LED 消息（毁坏的文件系统、JFS 或 Object Data Manager [ODM]）？如果系统仍在正常运行，那么执行 cfgmgr 命令后，磁盘资源是否会重新联机并回到 Available 状态？卷组是否可由 varyonvg 命令激活？文件系统是否完全载入？想要查看的数据是否能出现在文件系统内，还是丢失了？

第三步是按具体情况具体分析的方式解决资源问题。以下是我在多年的修复问题过程中常常使用的一些技巧：

文件系统。以我的经验，这是最常见的一种磁盘错误。无需多费劲就可以让超块变脏、造成存储碎片、搞乱存储节点或引起 errpt 反复出现 JFS 错误。即便是一个完整的文件系统也可能会把事情搞砸。修复文件系统问题最好的策略也是最简单的：利用文件系统检查命令 (fsck)。在这些情况下，我会卸载文件系统并针对它们运行 fsck –y ，直至不再出现错误，然后再重新载入它们。有时，我会格外彻底地卸载一个卷组内所有的文件系统，并使用外壳脚本中的循环脚本来完成此项任务以防出现潜在问题。

卷组。问题若超出了文件系统的范畴时，通常会转向卷组级别。有时，问题是 ODM 级的，可以通过 syncvg 或 synclvodm 进行纠正。在紧要关头，我曾用 varyoffvg 关闭卷组，用 exportvg 导出它们，然后用 importvg 重新导入它们以使其能被正确识别。但我总是会提前备份好 /etc/filesystems 文件并记录下磁盘端口 VLAN ID (PVID) 以保存载入的顺序。

物理卷。谈到 PVID，我看到过磁盘丢失，然后再以不同的 PVID 重新回到服务器。一个有帮助的做法是定期在别处记录下磁盘信息作为比照以防这类事情发生。如果真的发生了，我通常会用 rmdev –dl 从服务器删除这些磁盘，再用 cfgmgr 重新检测它们，然后再导出并重新导入卷组。

SAN 连接。有时全局名称 (WWN) 并不跨 SAN 网络进行端对端的传播，比如 VIO 服务器上的 NPIV。我有时会通过运行 pcmpath set adapter offline 禁用光纤通道适配器并手动定义或检查 WWN，然后再重新开启适配器。我也做过最极端的事，就是探查电缆并检查另一端是否有灯亮以确保没有物理问题存在。

引导问题。如果想要判断一个服务器为何在磁盘故障后不能引导，我通常会做的第一件事情是从服务器（根卷组除外），断开所有磁盘的映射和连接。如果为了找到一两个 rootvg 磁盘而探查数百个磁盘，那么将花去 Software Management System (SMS) 大量的时间。因此，我会在维护模式从一个 NIM 服务器引导系统来运行诊断并修复文件系统，用 bosboot 命令重新创建引导逻辑卷或访问此根卷组来修复诸如 /etc/filesystems 的配置文件。而且，在服务器启动后，有问题的文件系统通常都是那些本身处于关闭状态而它们旁边其他的文件系统则载入正常的文件系统。

恢复。最后，如果有东西损坏并确实需要修复，就要确保新更换的部件尽量接近于原始设备。这样一来，就可以最大限制地减少处理像文件系统大小或软件驱动器这类占用修复时间的 *** 作。我一直建议要为做好系统备份（mksysb 映像和使用诸如 IBM Tivoli® Storage Manager 的产品）来应对数据丢失和无法恢复的最坏情况。

---