Support

Site Restoration

#32224 Importing From S3 - Extraction Failed

Posted in ‘Site restoration’
This is a public ticket

Everybody will be able to see its contents. Do not include usernames, passwords or any other sensitive information.

Environment Information

PHP version
n/a
CMS Type
Other
CMS Version
n/a
Backup Tool Version
n/a
Kickstart version
n/a

Latest post by on Saturday, 08 February 2020 17:17 CST

Monday, 06 January 2020 20:52 CST

jenziggo
Hi Nicholas,
I have the latest Akeeba Pro (7.0.0)

Connected to S3 with Access Key and Secret Key and connection OK.
Imported from S3 Bucket and message shown that import is successful. (the backup file is 2.7GB) but strangely the import process only took several seconds.

In Manage Backups, the "Imported Backup" is listed, and has a green tick but no size information.

When trying to restore - error message was shown " The Extraction Has Failed, The Archive file was corrupt, truncated or archive parts are missing"

Kindly help!

Tuesday, 07 January 2020 00:42 CST

nicholas
the backup file is 2.7GB) but strangely the import process only took several seconds.


There is no way you downloaded that much data from Amazon S3 in so little time.

First, I need you to tell me exactly what you tried. Are you using Import from S3 or the Manage Backups page to import the archive? While both pages offer an S3 import feature they work very differently. I assume you are using Import from S3 based on your wording.

Then, I need you to tell me the exact version of Akeeba Backup that you are using. "7.0" is not a version number, it's a version family. That's not specific enough for what I am trying to help you with. Something like "7.0.0.b1" is what I am looking for.

I also want you to tell me if you can download the files the backup consists of manually and use Kickstart to extract them on any server, even your local computer. Please use the same Access Key and Secret Key as the ones you entered in Akeeba Backup. This will help me understand if the files are accessible with the credentials (Access/Secret Key) you are providing and whether the backup itself is a valid archive that can be extracted. If either condition is false we are trying to solve the wrong problem.

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

Tuesday, 07 January 2020 00:58 CST

jenziggo
Gosh am I glad to see your reply!

The Akeeba Version is: 7.0.0.rc1 (pro version)

Here's what happened:
From the Akeeba dashboard, I clicked on "Import from S3" icon, which brings me to the S3 connection page (with the secret key and all -and of course I uploaded the archive to S3 prior to this. In S3 I set the file access as "publicly accessible")

The connection was successful, because I could see right "bucket" and the intended backup archive (.zip) listed in the right column. Clicked the title, and several seconds later, a green message appeared saying it was a success.

When I attempt to restore this archive - using he "Restore" button on the "Manage Backup" page, it goes to the first restore page (that asked about execution time limit). I hit "continue" and then the error was produced.

I guess you're right - I have a feeling that the "Imported backup" from S3 is merely a title without the actual data being imported. No way 2.7GB was transferred in short seconds.

Where can I find clues to troubleshoot this issue?
*I have yet to test the backup in my local computer. But im guessing the archive is a good one

Tuesday, 07 January 2020 05:03 CST

nicholas
I want you to tell me if you can download the files the backup consists of manually to your local computer using the same Access Key and Secret Key as the ones you entered in Akeeba Backup. This will help me understand if the files can be downloaded with the credentials (Access/Secret Key) you are providing and whether the backup itself is a valid archive that can be extracted. If either condition is false we are trying to solve the wrong problem.

To be perfectly clear: knowing a file is there (displaying the listing of a directory) and downloading a file are entirely different actions which require different permissions. In the first case we are doing list contents on the bucket and that requires read permissions on the bucket. In the second case we are doing a get contents on the object (file) and that requires read permissions on the object. It is possible to have read privileges on the bucket but not the object. That's why I am insisting about retrying the download locally with the same access and secret key. This will tell me if the problem is with the credentials not being adequate to download the file OR with the download process in Akeeba Backup.

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

Tuesday, 07 January 2020 21:16 CST

jenziggo
Nicholas,

I just did what you told me to do: test the download using (Access/Secret Key) in another Joomla installation. Due to some reason I cant to that on my local computer but used another totally different hosting with a fresh Joomla installation.

Result: pretty much the same. Bucket is OK, archive is listed, but when clicked on the archive, it took only several seconds for the "successfully imported to your site" message to appear. This "Imported Archive" can't be restored.

The bucket and specific archive file in S3 both has public view/write permissions ( I have double checked that).

Awaiting your kind reply sir, thanks!

Wednesday, 08 January 2020 01:54 CST

nicholas
I tested that on my own sites. Importing a 200MB archive worked just fine.

I need some more information about your backup to understand what is going on.

  1. What is name of the file?
  2. Which OS are you trying to import the file into? I am thinking that if your archive's file name has characters which are not allowed on Windows (such as &, +, : or $) you would, indeed, get an immediate failure.
  3. Is the file in the bucket root or a subdirectory? If in a subdirectory, what is the path to the subdirectory starting from the bucket's root? I want to check whether path length may have an effect to the download.
  4. How many parts are there? Is it a single part e.g. just a .jpa file or multiple parts e.g. .jpa, .j01, .j02, ... I need to know the number of parts in case the problem has to do with multipart import only.
  5. What is the exact size in bytes of each file? I am thinking that individual file sizes over 2147483647 bytes (2GB minus one byte) could cause problems in certain circumstances.

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

Wednesday, 08 January 2020 21:27 CST

jenziggo
Nicholas,

1. File name : site-www.website.com-20200109-102724+08.zip
2. We are using a virtual server that runs on CentOS
3. The archive file is in bucket root
4. The archive file is a single zip (2.7GB). I have re-tried with 6 multiple parts of 500MB each, still same problem.
5. For the 6 multiple parts, (231.5MB, 536.9MB, 536.9MB, 536.9MB, 536.9MB, 536.9MB)

Awaiting your next advice.

Thursday, 09 January 2020 09:27 CST

nicholas
Thank you for the additional information. I created several scenarios with a massive (2.5 GB) backup with part sizes ranging from 20 to 500MB. In all cases I was able to import them without a problem. At this point I am convinced this is not a problem with our software or Amazon S3.

Based on your description all the data download requests to Amazon S3 return immediately without producing an error but also without returning any data. Based on our experience, this happens if and only if your server has some kind of misconfigured caching proxy which intercepts the HTTP GET requests and serves cached content without taking into account the headers sent with the request. This is a server configuration issue and we cannot help with it besides pointing at it.

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

Saturday, 08 February 2020 17:17 CST

System Task
system
This ticket has been automatically closed. All tickets which have been inactive for a long time are automatically closed. If you believe that this ticket was closed in error, please contact us.
Edited by on 2020-02-08 17:17 CST

Support Information

Working hours: We are open Monday to Friday, 9am to 7pm Cyprus timezone (EET / EEST). Support is provided by the same developers writing the software, all of which live in Europe. You can still file tickets outside of our working hours, but we cannot respond to them until we're back at the office.

Support policy: We would like to kindly inform you that when using our support you have already agreed to the Support Policy which is part of our Terms of Service. Thank you for your understanding and for helping us help you!