Пару лет назад данная проблема обсуждалась в ukr.comp.dbms.informix
http://groups.google.com/groups?hl=uk&lr=&ie=UTF-8&oe=UTF-8&threadm=9ibi6h%242snv%241%40ns.cbsd.donetsk.ua&rnum=1&prev=/groups%3Fhl%3Duk%26lr%3D%26ie%3DUTF-8%26oe%3DUTF-8%26q%3Dukr.comp.dbms.informix%2B%2B01%253A24%253A43
В качестве предположения, было высказано, что причина кроется в переходе timestamp в область отрицательных значений.

Я делаю level-0 своих 30Гб раз в неделю, при этом обычно он укладывается в 40 минут, но в некоторых случаях время достигает 1:30, при этом действительно ведется активная запись-чтение, и основные задержки в том, что очистели просто не справляются с буфферами. Манипулирования с timestamp ни к чему не привели (на моей системе перевести его из "-" в "+" можно за пару часов). По моим подозрениям, время зависит от частоты формирования level-"0", я специально попробовал делать бекап реже (раз в 10 дней), как результат вероятность длительного бекапа возросла. Кроме того, в пользу этого так же говорит следующий эксперимент - производится архив "0" (длительный), обрываем его на 60%, начинаем снова, до 60% он отрабатывает нормально, далее опять начинаются "тормоза". Возможно, может помочь предварительный "level-0" в /dev/null, но как говорилось в приведенной ранее ссылке, человеку не помогло :-(.

IMHO, "LTAPEDEV /dev/null" страшнее :-) Мой недельный Logical Logs раскручивается за полчаса, так что раз в неделю level-0 можно пережить.
У меня закончился оплаченный саппорт, поэтому версию от Informix сказать не могу :-(. Есть еще одна версия, про то, что надо вставить новую ленту и волосы станут мягкими и пушистыми, но мне она не помогла.