通常，我们有两种方法来恢复QMGR。一个是 backup and restore QMGR data&log ，另一个是 create backup QMGR 。我的问题是哪一个更适合QMGR恢复情况？或者他们都有自己的使用场景？请帮忙回答这个问题。
由于
答案 0 :(得分：1)
从究竟的恢复？使用recovery time objective或什么recovery point objective?最佳答案答案取决于这些要求以及应用程序的编写方式。从架构的角度来看，最佳方式是将消息传递视为传输。当您备份网络路由器时，您不会备份恰好在路由器上传输的消息，您只需备份路由器配置即可。与队列管理器相同。如果备份对象定义，授权，ini文件，退出和退出参数，则可以重新创建QMgr的空版本，并从旧版本中断处继续。
不幸的是，大多数应用程序的设计好像消息传递层是数据库而不是传输。这意味着他们希望从被击落的QMgr中恢复消息。这就是Backup QMgr的用途。它的工作方式是主QMgr使用线性日志文件。随着时间的推移，活动日志文件会前进，而旧文件不再需要用于恢复＆＃34;滚动＆＃34;日志集的结尾。然后将这些文件发送到备份QMgr所在和应用的位置。然后，备份QMgr将具有该日志文件最后一次激活时队列中的消息的精确副本。
主队列管理器上的消息与备份队列管理器上的消息之间始终存在滞后，滞后由主活动日志扩展区和辅助活动日志扩展区占用的空间表示。如果主日志范围和辅助日志范围的大小和数量保持较小，则可以最小化故障转移中丢失的消息数。无法通过这种方式实现零恢复点，但它比时间点备份要好很多。
这引导我们使用您提到的其他备份方法。如果在QMgr运行时进行备份，则时间点备份（即备份QMgr的队列和日志文件）将无法工作。在繁忙的QMgr上，日志和队列不断写入并且必须同步。但是，在活动时备份这些文件几乎可以保证备份日志不会与备份队列同步。 QMgr可能会在损坏的队列中恢复，或者QMgr在恢复后甚至不会启动。
此备份策略的仅时间是指QMgr是否已停止，然后最好在升级后用于恢复选项，而不是用于活动系统。例如，假设您在周日早上凌晨1点进行了有效的时间点备份。然后在一周内有人从QMgr下面删除一个队列文件，你需要恢复它。恢复onbe文件不会起作用，因为它与日志不同步并显示为损坏的对象。您必须恢复整个QMgr。你得到的是截至上周日凌晨1点所有队列中的所有消息。更糟糕的是，如果QMgr参与群集，将其恢复到先前的时间点会重置群集命令消息上的序列号，因此即使看起来像QMgr恢复且健康，群集也可能忽略它或你对它做出的任何改变。
最常见但在帖子中未提及的一种备份策略是备份QMgr配置。这包括：
通过这些，您可以重新创建队列管理器配置，并且可以在QMgr运行时完成所有这些备份。恢复时会生成一个空QMgr，应用程序可以像以前一样连接到该QMgr。主要要求是应用程序（或人工进程）必须协调任何丢失的消息。
有一种灾难恢复方法可以实现零恢复点 - 即不丢失任何消息。它使用QMgr文件下的同步磁盘复制。对队列或日志文件的每次更新都会实时复制到灾难恢复站点，因此DR QMgr具有主QMgr的精确副本。当主服务器出现故障时，您将中断复制并启动DR QMgr。假设您的DNS配置为也进行故障转移，则所有远程QMgrs和程序都将使用DR QMgr，就好像它是主要的一样。
还有一些HA选项。使用PowerHA或Veritas Cluster Server等硬件集群可以将QMgr从一台服务器故障转移到另一台服务器，前提是QMgr的文件托管在高可用性磁盘（如SAN）上。多实例QMgr可以在没有硬件集群软件的情况下执行类似的故障转移，并且基于高可用性NFS存储。这些都是HA解决方案而不是DR解决方案，因为两个QMgr实例都看到相同的磁盘存储。因此，它们必须与该磁盘存储器的距离相近（在网络方面），否则最远的QMgr上的性能将受到延迟和吞吐量的影响，这可能是不可接受的。
其他信息可在信息中心的Availability, recovery and restart主题中找到。