Support

Both issues are unrelated with the update. I have seen them happening many times in the past years and I have a fairly good idea of what could be going wrong.

Backup issue. Your host is killing the backup. There are a few different reasons why this could happen. Please follow each one of the recommendations below, in the order specified. I mean: try the first one; if the error persists try the second one; if the error still persists try the third one.

First go to the Configuration page of the backup profile and find the Archiver Engine row. Click on the configure button next to it and set the part size for split archives to 10Mb. If this doesn't work you may have to also try a part size fo 5Mb.

If this didn't work, on the same page, at the bottom set the following time settings:
- Minimum execution time: 1 second
- Maximum execution time: 10 seconds
- Runtime bias: 75%

If this doesn't work please try:
- Minimum execution time: 1 second
- Maximum execution time: 7 seconds
- Runtime bias: 50%

Or, if all else fails:
- Minimum execution time: 5 seconds
- Maximum execution time: 3 seconds (yes, the maximum is less than the minimum)
- Runtime bias: 50%

Finally you may want to try using a different browser. In some cases I have seen a huge difference when the user switched his browser. Note: there is no consistency from which to which browser that works; it seems dependent only on the browser setup of the specific computer. Statistically, Chrome yields better results. Try switching to another browser and see what happens. You may also want to turn off any antivirus, firewall or script blocking applications and/or browser extensions you may be using. Some of them (like AVG Antivirus) are notorious for screwing up certain pages with lots of AJAX loading – like the backup page of Akeeba Backup.

Restoration issue: Follow the instructions in the previous paragraph regarding browsers and antivirus / firewall / script blockers. Moreover, when the ANGIE page reloads, click on "Start over". This should clean up the session which allows the restoration to run through all of its steps.

Further advice: Your log states that the jos_mvc_iptocountry table has 111799 records. You may want to exclude the contents of this table from your backup. This table adds 50-70Mb to your backup.

Moreover, I can see this large file being backed up:
INFO |130428 17:30:19|Breaking step *after* large file: <root>/_db_backups/wattpa100400821.sql - size: 36660563
I believe this also contributes to your backup being bloated. Delete or exclude this file from your backup, please.

I am not sure what the wattpa100400821.sql file is, but it's not something generated by Akeeba Backup during the backup. If it's a database backup you've taken either with a third party application or with a different Akeeba Backup profile please note that you are supposed to exclude it manually using the Files and Directories Exclusion feature of Akeeba Backup. Its size, about 30+ Mb, is the exact size difference between the backup files that you are reporting.

Regarding the backup restoration, you seem to have either a backup archive of the wrong type or a badly set up server. After you extract the archive check your files. There should be an "installation" directory over there.

* If there is no installation directory: go back to Akeeba Backup and make sure that the backup type is set to "Full site backup". Anything else will not work for the kind of site transfer you want to achieve. Self understood, but let's mention it anyway: In this case you will need to take a new backup, transfer it to your new server and go through the entire archive extraction and restoration process using Kickstart.

* If there is an installation directory try accessing http://www.example.com/installation where http://www.example.com is the URL leading to your site. It's the same URL you used to run Kickstart, minus the /kickstart.php part, of course. Visiting this URL should show you the restoration script's page and allow you to proceed with the restoration.