Cannot restore XML backup from Cloud due to unpurged trash
Platform Notice: Cloud and Data Center - This article applies equally to both cloud and data center platforms.
Support for Server* products ended on February 15th 2024. If you are running a Server product, you can visit the Atlassian Server end of support announcement to review your migration options.
*Except Fisheye and Crucible
Summary
Problem
Restoring an XML site backup from a Cloud instance (e.g., when migrating from Cloud to Server) fails to complete with an undisclosed error. The process appears to hang.
Diagnosis
Symptoms
CPU spikes during the process
Heap is fully utilized
Diagnostic Steps
Did you have to allocate more memory to the heap for the restore? For example, you allocated an unusually high amount of memory, like 4x-5x the size of the actual (compressed) backup file, and the whole heap is utilized. There's also a corresponding increase in full garbage collections.
The following query returns an unusually high number of entries marked for deletion (possibly numbering in the millions):
1
SELECT COUNT(*) FROM CONTENT WHERE CONTENTTYPE = 'PAGE' AND CONTENT_STATUS = 'deleted';
Cause
A space (or multiple spaces) in your Cloud instance has a high amount of un-purged trash. That is, content items that were deleted but the trash was not purged. This trash is included in the backup file, and during the restore process all of it is loaded into memory with the rest of the instance entities before being written to the database. This quickly eats up memory and triggers full garbage collections, which halts all processes while the collection occurs. However, the garbage collection cannot free up space, causing the process to hang indefinitely.
Solution
Resolution
Find out which spaces have trash that should be purged, and purge that trash through the UI
Create a new site backup
If a space's trash has a large amount of trash (we've seen spaces with more than 1.7 million items), the Trash page in Confluence will be inaccessible and could crash your instance because of the amount of data being requested from the database. To determine if this is the case, please create a support request to have the Cloud team query the database for the existence of such trash. If we find that there are indeed spaces like this, we will have to purge the trash through the database. Once that trash is purged, you can create a new site backup.
Was this helpful?