Support

 I'm moving a site from a dev domain, to the new domain, and the restore has failed. My backup jpa file was copied to the new root, along with kickstart, but when I run the restore (I've done this 2 times now, I have tried doing a restore using two different methods after searching the Akeeba site), I have gotten the same error message each time:

Invalid header in archive file, part 0, offset 12496643

In looking through tickets in Akeeba, I see this indicates a corrupt backup, but I have no idea why it is corrupted. I'm attaching the backup log to see if you can help me figure this out.

In the meantime, I'm going to try another route, uploading a zip backup, uncompressing it on the new domain, and then doing a restore. I don't know what else to try.

Thank you,
Pat Vanden Bosche

Pat,

There are no warnings in the log file. You did a test extract as part of the backup and the archive passed that check. That indicates that the archive was good at that point.

You need to move the archive to your live site via FTP in binary mode. ASCII mode WILL corrupt the file, Auto mode makes your FTP client guess which mode to use.

Akeeba Backup sometimes skips the CRC value on large files. This is a compromise to prevent timeouts in PHP while the backup is in process. Calculating the CRC on a large file takes too long, so we skip it. Not all zip clients can extract such an archive. Kickstart should ignore the error and not even tell you about it. It understands the issue. With other zip extract clients you may need to skip errors, some just won't extract it because it thinks the archive is bad. Will the zip archive extract on your local machine?

It sounds like the zip file was your second try, did it extract successfully?

EDIT: Akeeba skips the CRC calculation on large files for zip format archives. The jpa and jps formats do not use CRC values.

I just tried the zip file, and it failed, with errors so only a portion of the file unzipped (probably more info than you wanted, sorry). So only a portion of the file unzipped, even after modifying the name of the zip file. I will try the binary backup method next:

Archive: /home2/patvb/public_html/site-patdevelopment.com-20161228-014253.zip
warning: filename too long--truncating.
skipping: ??I???? unsupported compression method 513
error: expected central file header signature not found (file #3428).
(please check that you have transferred or created the zipfile in the
appropriate BINARY mode and that you have compiled UnZip properly)
inflating: installation/README.html
inflating: installation/extrainfo.ini
inflating: installation/angie/application.php
inflating: installation/angie/assets/runscripts.php
inflating: installation/angie/autoloader.php
(and then a series of this type of error messages:)
file #3426: bad zipfile offset (local header sig): 26179066
file #3427: bad zipfile offset (local header sig): 26180387

Pat,

What happens with that file if you try to extract it with Kickstart? (Kickstart does zip files too.)

I didn't try using Kickstart! Good to know it does zip files too. I was just decompressing it once I had it uploaded to the new server. I've downloaded/uploaded the jpa file as binary now, and will try it again to see if all works well, and will let you know what happens.

Thanks,
Pat

I created a jpa backup file, downloaded it from the dev site, patdevelopment.com, and then uploaded it to patvb.com, both done as binary transfers using cuteftp, making sure both domains in my directory were set to binary transfers. Then I uploaded kickstart.php to the patvb.com domain, renaming it kickme.php. The decompression started fine, but a bit slow, then finished rapidly, but once the blue progress line was all the way across, the page hung up and didn't go any further. I've attached a screen shot to demonstrate what I mean when it hung up.

My speed is really slow, since I'm confined to using satellite out here in the woods of Tennessee. I have another network using a DSL line, but it's even slower. The price I pay for living in paradise.

I've tried to transfer from one domain to the other when the backup was created, but that failed. It would have been a lifesaver considering the speed I have available. I'm attaching the backup log again for your use, as well as the image of the screen shot.

What am I doing wrong now?

Oh, the problem is, all the files were not decompressed after all this. (Sorry, I'm a bit fuzzy right now.) I've attached a screen shot of the files opened in cPanel.

Dale, I got the restore to work! I had to break it up into smaller size zip files, based on something I read in here, and it worked. I do have a problem with the administrator login page, it is a blank page, but I'm uploading the latest files for Joomla 3.6.5, replacing the files I have unpacked since I think there is a file that's corrupted from the whole process.

The site shows correctly now, www.patvb.com, and I am so happy it's done! Only two days! LOL

Thank you for all the help you've given me.

Pat

Clear your browser cache when you're done with the Joomla! update. That will cause the blank page.

I'm thinkin' about how we can do this differently. You can probably smell the smoke from there. :-) I'll let you know what I figure out.

My brother's family had a house rented near Pigeon Forge for their vacation next year. Sadly, they will not be going to that house, it no longer exists. "Paradise" is a pretty good description though.

OK, to business! There are normally two things that go wrong with the site transfer wizard. First, the file is too big. We now have the archives broken into parts, so that shouldn't be an issue. Second, the path is wrong. we can beat that into submission. That feature works on most servers, but not all.

As an alternative, you could post process your backup to Amazon S3 or Dropbox and use Kickstart Pro to retrieve the backup from there to your target server. That makes all the file transfers between the servers, not to your local computer.

Both of these solutions prevent the bottleneck of having to download and upload the backup archives to and from your local computer.

Have a great holiday! Happy New Year!

Brilliant, Dale! I'll send the backup to Dropbox, as you suggested, the next time I have to move a site from server to server.

Happy New Year wishes to you as well, from the woods of Tennessee. (I have no flat land, no grass to cut, just trees and a gazillion leaves!) Thank you, again, for all your help.

Pat

You're welcome!