-
Bug
-
Resolution: Won't Fix
-
Low
-
None
-
4.3.7, 5.0-OD-27, 5.0.3, 6.3.4, 6.4.0
-
None
NOTE: This bug report is for Confluence Server. Using Confluence Cloud? See the corresponding bug report.
Steps to reproduce
1. Perform a full site export of a Confluence instance
2. Set up an instance with a different home directory (this is so that the backup path will differ from the export)
3. Check the backup path of your instance on the Backup Administration screen (/admin/dailybackupadmin.action)
4. Now import the backup you created in step 1
5. Check the backup path of your instance on the Backup Administration screen - 
it still shows what it did in step 3
6. Perform another site backup, with the option to archive a copy of the backup checked
7. You'll see that the temporary backup is created where you would expect (in the location that matches the backup path you saw in steps 3 and 5), but the archived backup is created in the home directory that was specified in the instance you imported from
In cases where that location doesn't exist anymore, a stacktrace will appear instead:
java.io.IOException: No such file or directory at java.io.UnixFileSystem.createFileExclusively(Native Method) at java.io.File.createNewFile(File.java:883) at com.atlassian.core.util.FileUtils.copyFile(FileUtils.java:465) at com.atlassian.core.util.FileUtils.copyFile(FileUtils.java:401)
See attached files for full stack trace.
I think the desired behaviour in this case is that the existing backup path of the instance is used, instead of the path from the import. This will ensure that the location always exists (since the home directory of this instance has to!).
Workaround
On the Backup Administration screen, click to edit the backup settings. You won't be able to change the backup path, but once you submit the form Confluence will go back to using the backup path that's specified on this screen.
- is related to
-
-
- Gathering Impact
-
- relates to
-
-
- Closed
-
- mentioned in
-
![[Atlassian Documentation] Page](/images/icons/generic_link_16.png "[Atlassian Documentation] Page")
Page
No Confluence page found with the given URL.
-
Page
No Confluence page found with the given URL.
-
Page
No Confluence page found with the given URL.
-
Page Loading...
-
-
[CONFSERVER-28575] Wrong backup path is used for archived backups after performing a site import
This is an evil bug! Especially in combination with https://jira.atlassian.com/browse/CONF-26943
Took me nearly 2 days to figure out.
Please reconsider fixing it.
At least the Backup Configuration Screen should show the wrong path.
Hi There
Thanks for taking the time to raise this issue. As you are no doubt aware this has been on our backlog now for over 2 years with very little movement and no resolution in that time. As it is unlikely that this issue will be resolved I'm going to close this out as won't fix.
Regards
Steve Haffenden
Confluence Bugmaster
melanie zhang
added a comment - I found this problem too. this is my solution:
1. edit the file confluence.cfg.xml, change false to true at this two lines, such as
<property name="admin.ui.allow.daily.backup.custom.location">true</property>
<property name="admin.ui.allow.manual.backup.download">true</property>
save it.
2. restart confluence
3.edit "Backup Administration" , set the right backups path.
4. backups will work.
melanie zhang
added a comment - I found this problem too. this is my solution:
1. edit the file confluence.cfg.xml, change false to true at this two lines, such as
<property name="admin.ui.allow.daily.backup.custom.location">true</property>
<property name="admin.ui.allow.manual.backup.download">true</property>
save it.
2. restart confluence
3.edit "Backup Administration" , set the right backups path.
4. backups will work. I just want to notify you of the fact that I have just discovered the same problem on a 4.3.7 installation that was upgraded from 4.2.4 back in February. The upgrade procedure used, however, was the one with copying the home-dir and database and edit a few files and not the procedure involving an XML Backup.
+1 for seeing this fixed - I just encountered it, and had I not found this bug report with a suggested workaround, I'm not sure I ever would have figured out what was going on...