Details
-
Suggestion
-
Resolution: Unresolved
-
None
-
None
-
5
-
3
-
Description
Hi everyone,
In Confluence 8.3, the backup and restore system underwent a complete upgrade with visible improvements to performance, stability, functionality, and appearance. The benefits of the upgrade include:
- faster XML backup and restore operations with performance that is up to 10 to 50 times faster, based on the instance size
- the ability to backup and restore multiple spaces, instead of the entire site
- more visibility and control with the ability to cancel backup and restore jobs
- improved reliability and reduced resource consumption
Confluence will save your XML backup zip file in the home directory. The backup will be deleted from this location after 72 hours if you did not choose to save it permanently during the back up process. You can change the storage time by configuring the system property confluence.backuprestore.backup.ttl-in-hours. See Configuring System Properties to learn how.
Learn more about these changes in the Confluence 8.3 Release Notes.
As part of Confluence 9.0, we plan to remove the legacy backup and restore system. This means that scheduled backups, which still uses our legacy system, will be no longer available. Scheduled XML backups have been disabled by default in Confluence Data Center since the release of Confluence 6.11.
We don't recommend relying on XML backups as a main backup method. Instead, we recommend regularly backing up the database, installation directory, and home directories. See Production Backup Strategy for recommended methods.
For backups of test sites, or in addition to database and directory backups, we recommend using the upgraded backup and restore system’s documented API that makes managing these tasks easier and also allows for the automation of heavy or large site merges and space migrations.
Kind regards,
Jacqueline Bietz
Product Manager
Confluence Data Center
Problem Definition
Confluence generates daily XML backups, which fill up disk space in the <confluence-home> backups folder. Left unchecked, this can grow and become large with outdated backup information.
Suggested Solution
Implement functionality that has Confluence auto-delete older backup files.
Workarounds
Workaround 1: Use production backup strategy (recommended)
As the XML backup can become less efficient as the content grows, Atlassian does not recommend using the XML backup for production disaster recovery. Instead, you can create a more complete, efficient backup using the recommended Production Backup Strategy.
Workaround 2: Use Java's date format
You can use a date format in the filename to name the file with the day of the week, month or year, so when Confluence tries to do this again, it is overwritten the next time Confluence needs to use the file name (e.g. "backup-Fri.zip" will be overwritten on Friday each week):
- Go to
> General Configuration > Backup Administration - Click Edit
- Replace the information in the Backup File Date Pattern with a single letter:
- Overwrite after a week: E
- Overwrite after a month: d
- Overwrite after a year: D
- Click Submit
CAUTION
As this is not a native feature of Confluence, any issues caused by this workaround may fall outside the scope of Atlssian Support Offerings. Be sure to test and validate this change in a test instance before applying to production.
Attachments
Issue Links
- duplicates
-
- Gathering Interest
- relates to
-
- Gathering Interest
- mentioned in
-
Page Loading...