Backups fail after workaround for bug 10827

[warbirdcharles]

I was hit with this bug and after doing the prescribed fix:

Bug 18027
Bug 18027 - tomcat didn't stop cleanly during the upgrade:

III. Solution
Move /opt/zimbra/redolog/redo.log aside and start Tomcat.

$ mv /opt/zimbra/redolog/redo.log /tmp/redo.bak
$ tomcat start

Please run a full backup after starting Tomcat and discard old backups. Bug 18027 has been fixed and will be integrated into the next release.

...

I get these backup failures and they make me nervous. The full backup I did right after implementing the fix appeared to go just fine. Help.

Subject: ZCS Backup Report: FAIL

Server: myserver.mydomain.com

Label: incr-20070712.080003.908
Type: incremental
Status: completed (with errors)
Started: Thu, 2007/07/12 01:00:03.908 PDT
Ended: Thu, 2007/07/12 01:00:04.483 PDT
Redo log sequence range: 2 .. 3
Number of accounts: <correct number of accounts>
Number of errors: 1


ERRORS

system: Detected possible redo log sequence reset; expected sequence 22, but found 2 through 3; To avoid future restore problems, discard all existing backups and take a full backup of all accounts; If this error occurred during restore, try the --ignoreRedoErrors option
com.zimbra.cs.backup.BackupServiceException: Detected possible redo log sequence reset; expected sequence 22, but found 2 through 3; To avoid future restore problems, discard all existing backups and take a full backup of all accounts; If this error occurred during restore, try the --ignoreRedoErrors option
at com.zimbra.cs.backup.BackupServiceException.REDOLO G_RESET_DETECTED(BackupServiceException.java:101)
at com.zimbra.cs.backup.util.Utils.splitRedoLogsAtSeq (Utils.java:403)
at com.zimbra.cs.backup.FileBackupTarget$FileBackupSe t.backupRedoLogs(FileBackupTarget.java:1034)
at com.zimbra.cs.backup.BackupSet.startIncrementalBac kup(BackupSet.java:636)
at com.zimbra.cs.backup.FileBackupTarget$FileBackupSe t.startIncrementalBackup(FileBackupTarget.java:836 )
at com.zimbra.cs.backup.BackupManager.backupIncrement al(BackupManager.java:324)
at com.zimbra.cs.service.backup.Backup.handleNetworkR equest(Backup.java:116)
at com.zimbra.cs.service.NetworkDocumentHandler.handl e(Unknown Source)
at com.zimbra.soap.SoapEngine.dispatchRequest(SoapEng ine.java:270)
at com.zimbra.soap.SoapEngine.dispatch(SoapEngine.jav a:168)
at com.zimbra.soap.SoapEngine.dispatch(SoapEngine.jav a:90)
at com.zimbra.soap.SoapServlet.doPost(SoapServlet.jav a:223)
at javax.servlet.http.HttpServlet.service(HttpServlet .java:709)
at com.zimbra.cs.servlet.ZimbraServlet.service(Zimbra Servlet.java:162)
at javax.servlet.http.HttpServlet.service(HttpServlet .java:802)
at org.apache.catalina.core.ApplicationFilterChain.in ternalDoFilter(ApplicationFilterChain.java:252)
at org.apache.catalina.core.ApplicationFilterChain.do Filter(ApplicationFilterChain.java:173)
at org.apache.catalina.core.StandardWrapperValve.invo ke(StandardWrapperValve.java:213)
at org.apache.catalina.core.StandardContextValve.invo ke(StandardContextValve.java:178)
at org.apache.catalina.core.StandardHostValve.invoke( StandardHostValve.java:126)
at org.apache.catalina.valves.ErrorReportValve.invoke (ErrorReportValve.java:105)
at org.apache.catalina.core.StandardEngineValve.invok e(StandardEngineValve.java:107)
at org.apache.catalina.valves.AccessLogValve.invoke(A ccessLogValve.java:541)
at org.apache.catalina.connector.CoyoteAdapter.servic e(CoyoteAdapter.java:148)
at org.apache.coyote.http11.Http11Processor.process(H ttp11Processor.java:869)
at org.apache.coyote.http11.Http11BaseProtocol$Http11 ConnectionHandler.processConnection(Http11BaseProt ocol.java:667)
at org.apache.tomcat.util.net.PoolTcpEndpoint.process Socket(PoolTcpEndpoint.java:527)
at org.apache.tomcat.util.net.LeaderFollowerWorkerThr ead.runIt(LeaderFollowerWorkerThread.java:80)
at org.apache.tomcat.util.threads.ThreadPool$ControlR unnable.run(ThreadPool.java:684)
at java.lang.Thread.run(Thread.java:595)

[warbirdcharles]

subsequent backups were clean and happy.