This article discusses the problems associated with a corrupted PaperCut database. It is designed to help you understand what may cause corruption, and how to reduce the risks associated with experiencing corruption.
Symptoms of database corruption If you are unable to start the PaperCut Application Server service, you may be experiencing database corruption. You can check your server logs files (i.e. server.log, server.log.1 etc.) to confirm. These are found in [app-path]\PaperCut NG/MF\server\logs. The PaperCut interface is loading to a page that contains one of the error messages found in the table below. Error MessagesFailed to start database ‘derby’, see the next exception for details.The conglomerate (X,Y) requested does not exist.Recovery failed unexpected problem log record is not first but transaction is not in transaction table: XContainer Container(X,Y) cannot be opened; it either has been dropped or does not exist.Page Page(X,Container(0,Y)) is at version V, the log file contains change version W, either there are log records of this page missing, or this page did not get written out to disk properly.Invalid checksum on Page Page(x,Container(0,Y)).Container X not found Potential causes of database corruption Full hard drive: If a hard drive hits it’s capacity in the middle of a database write process, the records will be committed to the database in an incomplete state. The incomplete records will offset all future records and can cause issues with all subsequent database activity.
Files were tampered or changed: A user or application has modified the files that PaperCut is trying to use in a way that PaperCut does not understand.
Other read/write failure: Sometimes, data just gets corrupted- this can be because of an OS-level or hardware error, or by an unexpected system stop (system crash, power loss, etc)
Resolving database corruption The only way to fix a database with corruption is to restore the database to a point before the corruption was introduced. Keep in mind, you may need to go back farther than you think. For example, if your server’s hard drive filled two weeks ago, and the problem is only just now showing itself, you will likely have to revert to a backup from before the drive filled.
Backups taken after the corrupting event will contain the corruption in their data. For more information regarding the backup and restore process, check out our manual page here.
Managing and reducing risk Detect corruption early PaperCut will run integrity checks on its database once every Friday. Set up system notifications to receive messages regarding integrity violations and performance warnings. Check out our manual for more information on how to set this up over here.
Use the maximum tolerable data loss to determine backup frequency By default, PaperCut will back itself up once a week (after the above mentioned integrity check). If a week of data loss is too much for your organization to tolerate, consider increasing the backup frequency or implementing a third-party backup solution. You can find out more about our weekly automatic backups here.
Comments
0 comments
Please sign in to leave a comment.