Support

From the description of it, either your backup is corrupt OR it gets corrupt during upload. There's only one way to find out. Use our free Akeeba eXtract Wizard to extract the backup archive on your PC.

If it doesn't extract your backup archive is corrupt. In this case you have to retake the backup. Make sure that if you have a multipart backup, all backup archive parts (.jpa, .j01, .j02, ...) are present in the same directory.

If the archive extracts upload all extracted files to your new host. However, do NOT copy the .htaccess and php.ini files (if you have such files) yet. Then access the restoration script as http://www.example.com/installation/index.php where http://www.example.com is the domain name of your site. After the restoration is complete remove the installation directory from your site and copy over the .htaccess and php.ini files (if they did exist in the backup). You may have to adjust the settings in those two files as they are very server-specific.

Important note: Kickstart only extracts the backup archive. It does not restore your site. The actual restoration takes place using a restoration script included inside your backup archive at backup time. This is why you can restore your site even when Kickstart doesn't work. Also note that even when the restoration script doesn't work either you can still salvage your site using our emergency manual restoration procedure. The only way to be completely unable to restore a backup is if the backup is deleted or entirely corrupt. In any other case we have a (documented!) way to restore your site. Hey, I built Akeeba Backup to satisfy my paranoid concerns regarding the safety of the data of my own sites :)

I don't think you read my reply (at least not carefully).

The problem you had WAS NOT with the .htaccess or php.ini file. The problem you had was a corrupt or partial backup archive. I gave you a solution to that.

If you use Kickstart both .htaccess and php.ini are extracted as htaccess.bak and php.ini.bak exactly so as not to cause a problem. Please read the fine manual where I explain in every detail how that works.

I understand that you were frustrated that you were not able to restore your backup but at least do read the documentation and follow my replies. Otherwise why did you ask me for support? Did you want to solve your problem or just make me spend my time in a futile task?

You see, for me it's not about making money or not. OK, I need to pay my staff and put food to the table but my objective is not making money: it's helping people. I've gone to great lengths to make sure that it's really darn hard to be unable to restore a backup. So what I want to do when replying to support request is above all help you understand what all the alternatives are (even though it's all documented) and how it all works.

> I re-read your email. The "archives" kept failing. I created several archives, all failed to expand properly. I created archives (.JPA) that were reduced to just a few directories knowing I could copy them over manually if needed. the site is not that big. After several hours and several versions of archives, I gave up.
This means that the backups get corrupt during transfer. To quote my earlier message:
"From the description of it, either your backup is corrupt OR it gets corrupt during upload."

> What I did not find is a way to BYPASS the first step of the kickstart expansion, and jump right into the restore section. Since I manually moved the files from testing server to production, I figured all I needed to do was restore, update database, replace php.ini and .htaccess and go.
That was the part I was hoping to help you with. It seems like I did? I got confused between your two replies :s

> Now - to you I say, your fine manual might be great for programmers and webmasters, but as an professional in visual communications, I can say that your manual does not communicate as clearly to me as it could on this day.
Just imagine that I had to leave some self-understood stuff out of the documentation. Backing up, restoring and moving a site is not as easy as it sounds. To give you an idea of how difficult this is: try taking a hard drive with Windows or Linux installed on it and put it in a completely different machine, then expect it to boot up without a problem. This is pretty much what you're trying to do restoring a site to a different server. We try to anticipate most of what can go wrong, but ultimately there's no silver bullet hence detailed documentation is necessary.

Also note that the documentation works best if you've read it before you need it. This applies to the documentation of everything. I even read my car's documentation. You never know when you need it (or what features you'll be missing if you don't). Reading the documentation when pressed by a deadline is definitely not going to help. Even if the solution is clearly spelt out you'll miss it.

> I am frustrated with BlueHost, for whom after 30 minutes on the phone asking for logs on why the Akeeba archive was crashing, was advised to use Akeeba Backup. Infuriating as I spent 30 min telling him EXACTLY what software I was using and where and how to follow along to see for himself. That man is a friggin idiot.
Welcome to hosting support hell :( In 2004, after having a host tell me that their database server was working fine and my "script" (Joomla!) wasn't working I had to learn how MySQL works only to find out that the bloody fools had MySQL 3.23 while everyone else –including my local server– had MySQL 4, resulting in failed site transfers due to incompatibilities. Had the support actually taken 2 minutes to enlighten me of that potential problem I would have spent one day less. Had they told me that I could put my MySQL 4 server in 3.23 compatibility mode with just one command before dumping its contents they'd have saved me a week. And that's how I started writing my own site transfer script which eventually evolved into JoomlaPack, the predecessor of Akeeba Backup.

> I am a full time visual communications designer with 15 years experience, a part time professor in visual communications for the past 8 years (At 2 separate colleges). I have a masters degree as well an undergraduate degrees in design and engineering.
Respect.

> I may be confused, but I am not an idiot. Again, I am frustrated.
Fully understood and I guessed you were frustrated. I was just unable to understand from your reply if you had read my reply or you were just venting off. Damn written communication, it fails to convey emotions accurately.

> I apologize if I wasted your time, but hopefully it was only the time it took to read this letter.
As long as I helped you understand the alternative ways to restoring a site in the rare cases where Kickstart doesn't work it's not a waste of time.

> I hope you see it was far less than the 2+ days I wasted before I wrote you.
Just a little bit of advice for future issues. If you've spent more than 30 minutes and you're not figuring it out yourself, start with the troubleshooter. If you can't find an answer there, drop us a line (and do tell us what you've tried so far so that we don't waste your time by telling you to read the troubleshooter). Give us information about the server environment and the exact errors you see. In short, help us help you just like you did in your original message. Then follow our instructions. There's an excellent chance we'll be able to help. There's also a small number of cases when we figure out that the host is FUBAR and we recommend using a better host. In any case, we'll try finding a solution for you.

> My letter was meant to be a customer comment to help you improve, take it or leave it as you will.
And I hope that you didn't waste any time trying to rebuild the site. The database is the least likely piece of the backup to be corrupt. I have chosen to place it in the backup archive first. My experience tells me that if the backup gets corrupt it tends to do so after several megabytes. If the database dump is stored in the beginning of the backup (as it is, by design) it can be salvaged. With 90% to 100% of the typical site's vital data being stored there we make sure that even in the worst case scenario you'll not be screwed.

Regarding .htaccess and php.ini I would like to comment a bit further. When restoring we do rename them with a .bak extension as I said above. We rename them back to their normal file names at the end of the restoration. There might be directives in either file which don't work on the new server setup. There is no way to know that for sure and deal with it automatically. If there was a way, I'd have written the code for it. All I can do is document the potential issues and link to this troubleshooter page in the final page of the restoration script. I even urge you to bookmark that page for future reference, in case the restored site doesn't work. I hope that further clarifies my reply to your comment.