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.
 
We have not yet upgraded to the latest version of Confluence (we are using 2.2.7), but this is pretty disturbing. Out of 21,896 rows in the BODYCONTENT table, 1659 of them refer to a CONTENTID that is not valid (see below). We are using an external MySQL database and our backups have been failing since November. Of course, we didn't realize this problem until it was too late. 
I was following the instructions on this page to manually fix the records until I realized the extent of the problem. How am I supposed to fix this data? I could just delete these 1700 rows from BODYCONTENT, but we will lose a lot of data and I have to believe there is other data corruption that will cause problems after this is fixed. Is this a known issue that is being addressed in an upcoming release?
mysql> use confluencedb;
Database changed
mysql> select count from BODYCONTENT;
+----------+
| count |
+----------+
| 21896 |
+----------+
1 row in set (0.00 sec)
mysql> select COUNT FROM BODYCONTENT bc LEFT OUTER JOIN CONTENT c ON c.CONTENTID = bc.CONTENTID where c.CONTENTID is NULL;
+----------+
| COUNT |
+----------+
| 1659 |
+----------+
1 row in set (0.13 sec)

Posted by shanecruz at Feb 14, 2007 15:56
|
Hi Shane,
can you open a support case at http://support.atlassian.com so that we can deal with your situation more easily.
Can you add some information to your support case:
- What does the content of the unreferenced rows looks like? Are they pages, mail, news?
- Which version of MySQL are you using?
- Which driver for your MySQL database are you using?
- When did you last upgrade your Confluence install? What version was it prior to that?
- What could have happened around November 06? Did you add any plugin? Did you import any new spaces? Did you upgrade Confluence?
Add any more information that you can think of that could help us.
Thanks,
SaM.

Posted by sleberrigaud at Feb 18, 2007 22:27
|
|