Detecting and Resolving Database Corruption

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.

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.