Troubleshooting failed XML site backups

XML site backups are only necessary for migrating to a new database. Setting up a test server or Establishing a reliable backup strategy is better done with an SQL dump.


Seeing an error when creating or importing a backup?

Problem

Solution

Exception while creating backup

Follow instructions below

Exception while importing backup

Follow Troubleshooting XML backups that fail on restore instead

Common problems

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.

Preferable solution

The Production Backup Strategy is a very reliable and more efficient way to do backups. If you are running into problems with XML backups - whether memory related or because of problems like the one described here - use the native backup tool as an alternate solution.

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:

  1. Stop Confluence.
  2. If you have an external database, use a database administration tool to create a manual database backup.
  3. Backup your Confluence home directory. You will be able to restore your whole site using this and the database backup.
  4. Open the my_confluence_install/confluence/WEB-INF/classes/log4j.properties and add this to the bottom and save:

    log4j.logger.com.atlassian.hibernate.extras.XMLDatabinder=DEBUG, confluencelog
    log4j.additivity.com.atlassian.hibernate.extras.XMLDatabinder=false
  5. Find your atlassian-confluence.log. Move or delete all existing Confluence logs to make it easier to find the relevant logging output.
  6. Restart Confluence and login.
  7. Begin a backup so that the error reoccurs.
  8. You must now check your log files to find out what object could not be converted into XML format. Open confluence-home/logs/atlassian-confluence.log. Scroll to the bottom of the file.
  9. Do a search for 'ObjectNotFoundException'. You should see an error similar to this:

    01 2005-08-24 00:00:33,743 DEBUG [DOCPRIV2:confluence.importexport.impl.XMLDatabinder] Writing object: com.atlassian.confluence.core.ContentPermission with ID: 5 to XML.
    02 2005-08-24 00:00:33,743 DEBUG [DOCPRIV2:confluence.importexport.impl.XMLDatabinder] Writing property: type
    03 2005-08-24 00:00:33,743 DEBUG [DOCPRIV2:confluence.importexport.impl.XMLDatabinder] Writing property: group
    04 2005-08-24 00:00:33,743 DEBUG [DOCPRIV2:confluence.importexport.impl.XMLDatabinder] Writing property: expiry
    05 2005-08-24 00:00:33,743 DEBUG [DOCPRIV2:confluence.importexport.impl.XMLDatabinder] Writing property: content
    06 [DOCPRIV2:ERROR] LazyInitializer - Exception initializing proxy <net.sf.hibernate.ObjectNotFoundException: No row with the given identifier exists: 2535,
    07 of class: com.atlassian.confluence.core.ContentEntityObject>net.sf.hibernate.ObjectNotFoundException:
    08 No row with the given identifier exists: 2535, of class: com.atlassian.confluence.core.ContentEntityObject
    09	at net.sf.hibernate.ObjectNotFoundException.throwIfNull(ObjectNotFoundException.java:24)
    10	at net.sf.hibernate.impl.SessionImpl.immediateLoad(SessionImpl.java:1946)
    11	at net.sf.hibernate.proxy.LazyInitializer.initialize(LazyInitializer.java:53)
    12	at net.sf.hibernate.proxy.LazyInitializer.initializeWrapExceptions(LazyInitializer.java:60)
    13	at net.sf.hibernate.proxy.LazyInitializer.getImplementation(LazyInitializer.java:164)
    14	at net.sf.hibernate.proxy.CGLIBLazyInitializer.intercept(CGLIBLazyInitializer.java:108)
    15	at com.atlassian.confluence.core.ContentEntityObject$$EnhancerByCGLIB$$cc2f5557.hashCode(<generated>)
    16	at java.util.HashMap.hash(HashMap.java:261)
    17	at java.util.HashMap.containsKey(HashMap.java:339)
    18	at com.atlassian.confluence.importexport.impl.XMLDatabinder.toGenericXML(XMLDatabinder.java:155)
    
  10. 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.
  11. To work out which table, open atlassian-confluence.log, 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
    • More information can be found in the schema documentation
  12. 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.
  13. 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.
  14. Using a database administrative tool, login to 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.
  15. Restart Confluence.
  16. Attempt the backup again. If the backup fails and you are stuck, please lodge a support request with your latest logs.

Troubleshooting "Duplicate Key" related problems

If you are encountering an error message such as:

could not insert: [bucket.user.propertyset.BucketPropertySetItem#bucket.user.propertyset.BucketPropertySetItem@a70067d3]; SQL []; Violation of PRIMARY KEY constraint 'PK_OS_PROPERTYENTRY314D4EA8'. Cannot insert duplicate key in object 'OS_PROPERTYENTRY'.; nested exception is java.sql.SQLException: Violation of PRIMARY KEY constraint 'PKOS_PROPERTYENTRY_314D4EA8'. Cannot insert duplicate key in object 'OS_PROPERTYENTRY'.

this indicates that the Primary Key constraint 'PK_OS_PROPERTYENTRY_314D4EA8' has duplicate entries in table 'OS_PROPERTYENTRY'.
You can locate the constraint key referring to 'PK_OS_PROPERTYENTRY_314D4EA8' in your table 'OS_PROPERTYENTRY' and locate any duplicate values in it and remove them, to ensure the "PRIMARY KEY" remains unique. An example query to list duplicate entries in the 'OS_PROPERTYENTRY' table is:

SELECT ENTITY_NAME,ENTITY_ID,ENTITY_KEY,COUNT(*) FROM OS_PROPERTYENTRY GROUP BY ENTITY_NAME,ENTITY_ID,ENTITY_KEY HAVING COUNT(*)>1

To Help Prevent This Issue From Reoccurring

  1. 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.
  2. If you are using an older version of Confluence than the latest, you should consider upgrading at this point.
Last modified on May 30, 2019

Was this helpful?

Yes
No
Provide feedback about this article
Powered by Confluence and Scroll Viewport.