Uploaded image for project: 'Confluence Data Center'
  1. Confluence Data Center
  2. CONFSERVER-6134

space restore from XML backup

    XMLWordPrintable

Details

    Description

      Got this problem from a customer in email. I've sent him the ticket so he can track the status:

      Hi Ernest (and Jon),

      No problem on any delay: Jon Silvers (in San Francisco) was very helpful in arranging XML backups of the two spaces as well (thank you again, Jon!). It is good news that JIRA supports local online docs, thanks for checking on that for me.

      Unfortunately, I have a problem to report. It would appear the space restore from XML backup is broken in some way, with respect to attachments. Comments appear intact, but all attachments are inaccessible.

      We are using the standalone build#512 (v2.2), on an Apple XServ running Mac OS X Server 10.4.6 (Tiger), communicating to a remote PostgreSQL 7.4.7 (debian "sarge") using the latest JDBC driver (501) from jdbc.postgresql.org. We are using the default configuration for attachments, storing them on the fs.

      I can fetch the "system information" page for our configuration if needed. By the way, our next eval phase is planned to deploy the WAR/ EAR lash-up alongside a JIRA eval, using the Mac OS X Server LDAP for authentication.

      **After restoring either the CONF20 or DOC spaces, and indexing:

      • (OK) all pages/hierarchies appear intact – even the confluence "Team" name showed up;
      • (OK) all attachments LIST under the spaces' attachment tabs
      • (FAIL) ALL inline images display as broken icons within any page that contains them;
      • (FAIL) ALL attachments cannot be found;
      • (FAIL) accessing any attachment produces server ERROR page (~ "attachment not found where expected")
      • (FAIL) /var/confluence/attachments/ contains no new items/directories

      I have tried to import the CONF20 and DOC spaces numerous times now with XML exports obtained by directly accessing the confluence.atlassian.com website as well as those exports provided by you and Jon. I've utilized both restore space methods of uploading backup via browser as well as a "local restore" after transferring the backups to the configured confluence "restore" directory (under / var/confluence/ in my case).

      During the various restore attempts I could see the backups were unzipped into "/var/confluence/temp/import

      {name_varies}/" where I can find the "attachments" subdir, containing the usual hash dirs.

      At the end of the restore process I briefly saw that a new directory, "/var/confluence/temp/import{name_varies}

      /new.attachments" (or similar) was created, containing the same hash dirs as the apparently- to-be-restored attachments dir. Once the restore completed the the entire "/var/confluence/temp/import

      {name_varies}

      /" was removed, as I would expect.

      No changes are ever made to /var/confluence/attachments/. However, during normal use of confluence, making NEW attachments in other spaces does work and does change the contents of /var/confluence/ attachments, both before and after the restore process.

      Any suggestions you have would be greatly appreciated.

      John L.

      Attachments

        1. 00conf-overview.pdf
          61 kB
        2. 01conf-import_log.pdf
          645 kB
        3. 02conf-index_log.pdf
          401 kB
        4. 03conf-access_log.pdf
          133 kB
        5. CONF20-20060516-18_52_38.zip-aa
          6.00 MB
        6. CONF20-20060516-18_52_38.zip-ab
          4.84 MB
        7. error.pdf
          195 kB
        8. notes.pdf
          63 kB
        9. system_info.pdf
          28 kB

        Issue Links

          Activity

            People

              confluencesupportuser Confluence Support Mailbox
              jon@atlassian.com Jon Silvers [Atlassian]
              Votes:
              3 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: