逻辑日志备份是把一个或多个逻辑日志文件复制到磁盘或磁带的过程。逻辑日志文件记录了检查点、DDL语句以及数据库的插入更新等操作。每个数据库服务器的逻辑日志文件是有限的，这些逻辑日志文件并不是一个个单独的操作系统文件，而是一个dbspace的连续的一块空间，一般在安装Informix时，最初的几个逻辑日志文件都在rootdbs上，在生产系统中，需要将逻辑日志移动到一个单独的dbspace上。这些逻辑日志文件是循环使用的，日志文件按顺序进行写，当第一个逻辑日志文件用完之后，会接着写第二个日志文件，以此类推，当所有的日志文件都被使用后，服务器又开始写第一个日志文件。因此，在一个日志文件被重用之前，它必须已经备份。

1．逻辑日志何时被备份

可以通过两种方式来备份逻辑日志文件，显示的备份或者使用连续日志备份。

（1）按需备份（ondemand backup）：如果是使用ontape，也称做自动备份。它会备份所有没有备份的逻辑日志，但不备份当前的逻辑日志。如果选用了这种备份方式，需要多次备份逻辑日志，并确保在两次备份之间，数据库日志不会被用完。

（2）连续日志备份：如果备份数据和日志的磁带或文件是分开的，则适合使用连续日志备份，当用这种方式备份时，一个逻辑日志写满后就会被备份。

恢复很多的逻辑日志比从备份中恢复数据页面要慢，因此，为了最小化恢复时前滚的日志文件数目，需要更频繁地做dbspace的备份。

2．逻辑日志文件备份的重要性

下面是需要连续做逻辑日志备份的重要性。

（1）提供了所有事务的恢复能力。

恢复有两个阶段：物理恢复和逻辑恢复。物理恢复从备份中获得数据，逻辑恢复前滚备份之后发生的日志，这些事务保存在逻辑日志中，如果没有备份逻辑日志并且逻辑日志不在硬盘上，你将不能重放那些事务，会导致交易丢失。

（2）避免因逻辑日志写满阻塞了数据库服务器。

为了避免逻辑日志文件中的事务信息丢失，日志文件在重用之前需要被标记已经做了备份，如果所有的日志文件都已经使用，并且没有被备份过，服务器将被阻塞住直到逻辑日志备份已经完成。

如果将配置参数LTAPEDEV设置为/dev/null，此时，即使你没有做日志的备份，当一个日志文件写满之后，它将被标记为已经备份过。在Informix 11.7版本之前，可以通过onmonitor动态修改LTAPEDEV参数，onmonitor将修改的变化保存在保留页中；在Informix 11.7版本中，可以通过onmode wf和onmode wm动态修改LTAPEDEV参数。

（3）包含日志文件的磁盘可能会失败。

如果日志文件所在的磁盘失败，你将不能恢复没有备份的那些日志文件所包含的交易，通过使用连续日志恢复的策略，你将可以最小化事务的丢失量。避免这种问题最好的方法是使用HDR技术或者RSS技术来建立一个备份系统。

也可以选择对日志文件的chunk做镜像，当主chunk失败时，镜像的chunk仍可以使用。
（4）许多类型的恢复需要追加逻辑日志。

当使用的恢复工具不同或者恢复方法不同时，你也许需要逻辑日志来完成一个完整的恢复。例如，恢复单个dbspace时（热恢复），逻辑日志需要从备份的时间点追加到当前的时间。

每个工具有一些特定的场景是不需要恢复逻辑日志的，当选择不备份逻辑日志时，需要了解可能带来的坏影响。