This page last changed on Mar 22, 2007 by dave@atlassian.com.
Seeing an error when creating or importing a backup?
Resolve Errors With Creating An XML Backup
The errors may be caused by a slightly corrupt database. If you're seeing errors such as 'Couldn't backup database data' in your logs, this guide will help you correct the error on your own. We strongly recommend that you backup your database and your Confluence home directory beforehand, so that you can restore your site from those if required. If you are unfamiliar with SQL, we suggest you contact your database administrator for assistance.
To Identify And Correct The Problem
To work out where the data corruption or problems are, increase the status information reported during backup, then edit the invalid database entry:
- Stop Confluence.
- If you have an external database, use a database administration tool to create a manual database backup.
- Backup your Confluence home directory. You will be able to restore your whole site using this and the database backup.
- Open the my_confluence_install/confluence/WEB-INF/classes/log4j.properties and add this to the bottom and save:
log4j.logger.com.atlassian.confluence.importexport.impl.XMLDatabinder=DEBUG, confluencelog
log4j.additivity.com.atlassian.confluence.importexport.impl.XMLDatabinder=false
- Find your Confluence output logs. On standalone, this is the /logs directory under your Confluence install. Move or delete all existing Confluence logs to makes it easier to find the relevant logging output.
- Restart Confluence and login.
- Begin a backup so that the error reoccurs.
- You must now check your log files to find out what object could not be converted into XML format. Open my_confluence_install/logs/catalina.out. Scroll to the bottom of the file.
- Do a search for 'ObjectNotFoundException'. You should see an error similar to this:
- Open a DBA tool such as DbVisualizer and connect to your database instance. Scan the table names in the schema. You will have to modify a row in one of these tables.
- To work out which table, open catalina.out, check the first line of the exception. This says there was an error writing the ContentPermission object with id 5 into XML. This translates as the row with primary key 5 in the CONTENTLOCK table needs fixing. To work out what table an object maps to in the database, here's a rough guide:
- Pages, blogposts, comments --> CONTENT table
- attachments --> ATTACHMENTS table
- Now you must find the primary key of the incorrect row in this table. In this case, you can check the first line and see that the row has a primary key of 5.
- Each property is written to a column, so the last property that was being written has the incorrect value. The row being written to when the exception was thrown was CONTENT (line 5) with a value of 2535 (line 6). Now you know the column and value. This value 2535 is the id of an entry that no longer exists.
- Using a database administrative tool, login ot the Confluence database. Locate the row in the relevant table and correct the entry. Check other rows in the table for the default column value, which may be null, 0 or blank. Overwrite the invalid row value with the default.
- Restart Confluence.
- Attempt the backup again. If the backup fails and you are stuck, please lodge a support request with your latest logs.
To Help Prevent This Issue From Reoccuring
- If you are using the embedded database, be aware that it is bundled for evaluation purposes and does not offer full transactional integrity in the event of sudden power loss, which is why an external database is recommended for production use. You should migrate to an external database.
- If you are using an older version of Confluence than the latest, you should consider upgrading at this point.
 
|