entities.xml exportDescriptor.properties are missing from automated backups causing failed restores
Asked by Jason Heywood:

OS: CentOS 7

Confluence: 6.6.1

When I attempt to restore confluence through the frontend UI and select a staged backup file, the restore fails with the error:

com.atlassian.confluence.importexport.actions.RestoreLocalFileAction.action.name

The zip file did not contain an entry 'exportDescriptor.properties'.

Then lists the thousands of attachments.

I am not doing anything with Mac unzip/zip.

The zip backup file is 8.3 GB compressed. Browsing the contents with vim, in addition to actually unzipping the file in linux - the files exportDescriptor.properties and entities.xml are both missing. I can see the files present in an old zipped backup from months ago.

1. Is this a setting to reenable, that may have somehow got disabled? (to have the files be in the backup.zip

2. Can I get these files from somewhere? Where? I assume then I can rezip in linux with the new files and should be good to restore again?


Answers:
author: Shannon S
body: Jason,

Welcome to Community! Thank you for reaching out.

To clarify, you're restoring Confluence and not Jira, correct? You mentioned Jira so I want to be sure.

Could you tell me more about how you obtained the backup file? Where did it come from, and how was it generated? You don't see the exportDescriptor.properties file at all? It's automatically included when the backup is generated from Confluence.

Regards,

Shannon

comments: author: Jason Heywood
body: Correct. Apologies - it was a long day of troubleshooting.

The backup file itself is a result of the daily scheduled backup through cron - configured in confluence's admin interface.

Backup Administration:

![backup-admin-config.png](https://community.atlassian.com/t5/image/serverpage/image-id/50885i3019ACD384C0C3F0/image-size/large?v=v2&px=999 "backup-admin-config.png")

Scheduled Cron:

![backup-scheduled-job.png](https://community.atlassian.com/t5/image/serverpage/image-id/50886iCC28EB365AF9A090/image-size/large?v=v2&px=999 "backup-scheduled-job.png")

History:

![backup-history.png](https://community.atlassian.com/t5/image/serverpage/image-id/50887i67678A2FFD96D2CA/image-size/large?v=v2&px=999 "backup-history.png")

Correct, the exportDescriptor.properties file is completely missing from the zipped backup, and I'm as confused as you are.


author: Shannon S
body: Thanks, Jason.

We'll get to the bottom of this!

1. This can also be caused by insufficient disk space, were you able to [confirm your disk space on your server](https://www.linux.com/blog/linux-101-check-disk-space-command)?
2. Second, can you try manually creating a backup but without the attachments? I want to see if it includes the exportDescriptor.properties file when it doesn't backup the attachments.
3. You want to make sure the backups are actually completing, so we want to troubleshoot them. [Troubleshooting Failed XML Site Backups](https://confluence.atlassian.com/doc/troubleshooting-failed-xml-site-backups-149212.html). Make sure to set DEBUGGING on, per step # 4 in the article.

Let me know how that goes.

Regards,

Shannon


author: Jason Heywood
body: Thank you for your help Shannon. I was able to figure out the problem. The Confluence instance we have is large, and the scheduled backup would not be completed before the scheduled cleanup would begin. Thus while the temp directory was being used as a staging place for the backup bits, the scheduled housekeeping started deleting files from the temp directory. So when the backup process finished, it was missing files from the zipped file.


author: Shannon S
body: Jason,

Thank you for providing that update! Happy to hear you were able to resolve it.

Take care, and have a pleasant weekend.

Regards,

Shannon


author: Andreas Kroschel
body: Hi Jason,

I just want to thank you very much, as your hint was able to turn a long, frustrating week of troubleshooting into success. Cheers to you!

Best regards,

Andreas


author: F K
body: Jason,

thanks a ton for sharing your solution. We had the exact same issue during a periodic restore test and this forum thread came up in a Google search.

I don't want to imagine how many Confluence installations out there are **unsuspectingly**running without a working backup just because at one point, the backup started to take more than 2 hours every night and gets constantly sabotaged by the cleanup cron job since then. This is the stuff of nightmares.

[@Shannon S](/t5/user/viewprofilepage/user-id/510046)   
Has this ever been addressed by Atlassian in recent releases? E.g. by making the backup job more robust and by issuing notifications in case of an incomplete XML backup?  
Or by restricting the scheduled cleanup task to files older than - say - 6 hours?

Best regards,  
Florian


Tags: confluence-server

server