nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Error when trying to importing existing data (OnDemand > OnSite)

Thomas Krag1

Hey guys,

I'm currently getting this error when trying to importing my old data.

Error importing from zip file: "X:\backup\JIRA-backup-20131028.zip". Error: central directory is empty, can't expand corrupt archive.

The zip file is quite huge (5GB) and while I'm not able to open it in Windows' built-in ZIP software I am able to open it in 7-zip.

Would you know what the problem could be?

Accepted answers

All comments

RicardoA_8cz081

Hi Thomas

Try uncompressing the file again, and compressing it with winzip. When importing don't forget to write up the full file. For ex: Backup2013.zip Or try to create a new backup of the old instance.

Hope it helps,

Ricardo Carracedo

Thomas Krag1

Hey Ricardo,

Thanks for your reply.

It seems that my archive actually was corrupted. 7zip at least crashed while unpacking it as I left it to unpack it over night. The odd thing is that I've tried downloading it twice now on different machines with the same result.

Is 5GB of data an abnormal archive size to have in Jira? And do you (or anyone) have any suggestions to the best way of downloading this file without it breaking?

RicardoA_8cz081

Hi Thomas

5GB is a really big instance, but this should not be a problem, I believe the problem is at the file being corrupted. When you say you downloaded it twice, were you are downloading it from?

Thomas Krag1

Just to cover all possible answers:

I'm located in the Netherlands on a 100mbit line.
I tried downloading it on 2 different machines that are located in different LANs.
One VM one physical machine.
I'm downloading it from the OnDemand site under 'Backup Management' or something similar. So an HTTP download.

I did notice that the download was quite slow. We're talking 3 hours to download 5GB. Is it possible for support to transfer it to an FTP or simply a European server?

If you need more information feel free to ask.

Thomas Krag1

The real issue seemed to be downloading the archive without the HTTP connection breaking. As our archive in Jira was 5GB+ Atlassian split the archive into several files.

Downloading these files using Firefox + DownThemAll! seemed to download all files without corruption.

I'll give it another shot today at installing it, but for issues related to this it's best to try to download your archive using a download manager. If you still experience issues contact Atlassian support directly.

Answers are quick, knowledgable and very helpful!

Bruce Reed2

Hi,

ran into the exact same error message. Our backup is 11GB large. It is indeed true that downloads sometimes become corrupt. That happens. However, for the most part of the time I know what I'm doing and checking the archive, if it is corrupt was the first thing I did. I also told Atlassian support so, but nevertheless they pointed me to this useless post here. I sure hope Thomas Krag found a solution for his problem. I went back and forth with Atlassian support on this with me actually coming up with next steps and actually finding the solution, while they provided great moral support.

Long story short, you have to extract the folders in the data folder and move them manually to your server to the right location. You actually restore only your configuration and data that lives in the database. The steps I've undertaken to restore my OnDemand backup locally can be found below.

I am pretty sure the actual root cause of this issue is ZIP library used by the importer. The size of ZIP archives is limited to 4GB unless compiled with 64-bit support. There is tons of information about that out there so I won't go into this. What surprise me though, is the fact that JIRA is capable of creating archives that are larger than 4GB, but can't extract them. I suppose, another team worked on the importer...

Anyhow, hopefully the steps below will save a lot of people time and nerves to get a large backup restored again:

Download the backup file with wget or some other means that prevent the a timeout

wget -t 0 --no-check-certificate --user=your_user --password="your super secret password that has to be enclosed by double quotes" &lt;URL_TO_BACKUP_FILE&gt;

Unzip the backup file on your local computer with either Finder on Mac OS or the Windows built-in unpacker
Re-zip the files entities.xml and activeobjects.xml in the data folder and copy them to the server into the import directory. Obviously, you need to use a user that has either access to that folder or you copy it to /tmp and then move it on the server as root to the import directory
```
zip -9 jira_backup.zip entities.xml activeobjects.xml
scp jira_backup.zip user@jira-server:/var/atlassian/application-data/jira/import/
```

Copy now the subfolders attachments and avatars in the data folder to the data folder on the server. You installation may have other or more subfolders under data

scp -r data/attachments/* user@jira-server:/var/atlassian/application-data/jira/data/attachments/
scp -r data/avatars user@jira-server:/var/atlassian/application-data/jira/data/

Make sure that the attachments and avatars folders are owned or are accessible by the same user under which the JIRA server runs. In my case this is a dedicated user named jira. Adjust on the server the permissions of attachments and avatars
```
chown -R jira:jira /var/atlassian/application-data/jira/data/*
```
Restore now through the web interface your modified backup file. In this case it's named jira_backup.zip
Change default sysadmin password from sysadmin to something more secure
Enjoy the fruits of your labor

Bryan Karsh

Thanks for the tips. I am running into this issue as well. our download is a whopping 41GB -- and I am only able to get 5.9GB out of it.

I have a ticket with atlassian to see if they can tarball my attachments instead.

But from the errors I see, and my testing.. it seems releated to the 4GB/64-bit support issue.

Bruce Reed2

That's a large backup indeed. Out attachments folder is uncompressed only 25GB. The two XML files containing the configuration and database data were together only 150MB uncompressed. So you should be OK when compressing only the two XML files.

In case you are running Windows and have issues with the download interrupting, you can get the wget program also for Windows as part of this package here: http://unxutils.sourceforge.net/<br< a="">>It contains also some other useful tools, too.

In case your large download gets interrupted for any reason you should be able to restart it again by adding the -c option:

wget -c -t 0 --no-check-certificate --user=your_user --password="password" &lt;URL_TO_BACKUP_FILE&gt;

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

jira-administration