Support

Mandatory information about my setup:

Have I read the related troubleshooter articles above before posting (which pages?)? YES
Have I searched the tickets before posting? YES
Have I read the documentation before posting (which pages?)? YES/ALL
Joomla! version: (2.5.9)
PHP version: (5.3.23)
MySQL version: (unknown)
Host: (various)
Akeeba Backup version: (3.7.4)

Description of my issue:
Setting up S3, (ABT working fine before without remote backup).

I'm just trying to understand the JPA file "part sizes" for Amazon S3. In general I have my new free-trial AWS S3 all working and connections with my buckets are established. I had an initial problem with buckets named with a "dot" (eg "my.files") which caused an issue with "Use SSL" set to on (thereby treating the dotted bucket names as subdomains). Creating and using new dotless bucket names instead solved that particular problem.

My current mystery is that I have found that NOT setting a "Part size for split archives" under "JPA format" seems to work without a problem (using the default "Custom 2047MB"). I now get no server time-outs but this only seems to happen after successfully completing a "part" S3 upload for any particular site (with parts set to 20MB or less and "Disable multipart uploads" on). I have tried this from two different hosting providers, one using a VPS creating a 128MB backup size and on two shared server sites with 28MB and 76MB backup sizes. It was after completing the successful "part" backups, that I then reset the part size to "Custom 2047MB" and turned off the "Disable multipart uploads" and then the large single uploads to S3 seem to work just fine.

The thing that prompted me to test this out was that during setting up ABT with S3, I was getting the occasional time outs with 20MB and then 10MB part sizes, so I kept trying alternative settings. I tried it with the "Disable multipart uploads" on or off and various part sizes, but ultimately just not splitting the archive seems to make it work reliably!

Is this normal? I have not tried it extensively but it seems to be working for me over the last couple of days (all just manually run backups, not tried cron yet).

Looking at the php info, max_execution_time, it is set to 30 on the shared server and 300 on the VPS, I think I've seen ABT occasionally report greater than 30 secs while backing up in "Last server response" timing on the sites on the shared server. The transfers to S3 seem to happen quite quickly though so I'm not sure which servers timing is counted for this part of the process.

There are two final points I'd like to mention and possible bugs:

1. I keep ABT's Output Directory set to a place on the server above and outside of the public_html folder. This owrks fine but on one site I had the folder named as "akeeba_backups" and the others I had it named to just "akeeba". I noticed I was getting backup errors at some point when I backed up the site using the first folder name (with the underscore). When I renamed it to just "akeeba" everything seemed to work okay after that. It may just be a coincidence but maybe worth mentioning I thought (ABT was working to that underscore folder fine on it's own before configuring for S3).

2. When using "part archives" when the backup saves okay to my site's output folder and S3, even though I have "Delete archive after processing" set to on, only one of the archive parts is deleted from ABT's Output folder (the smaller .jpa one). i.e. the .j01, j02, etc. backups don't get deleted and remain on my server, yet the backup files all appear on S3. Is something being missed in the deletion process?

"You're the first person to report that this works but the legacy upload of smaller parts doesn't!"

I haven't fully tested again with "part" uploads, but it was just occasionally in my initial testing that one part would seem to fail. Now that I know a single big file is working and "normal", that seems the better option for me to use.

Actually, I just tested again with the 76MB site splitting it into 20MB part sizes and "Disable multipart uploads" set to on. First test failed with some SSL error message after upload the first jpe part. 2nd test failed after the j01 part with same SSL message, 3rd test uploaded all backup parts successfully. So it does seems to be a variable problem for me. Switching back to a full one-part file shows it still being always successful (so far!).

"...waiting for libcurl to complete, therefore not counting towards the PHP timeout limit. I'm sure you didn't understand any of that."

Hey, I did get it...! Just!... Now I understand why over-time on time-outs are logically okay!

Re the last point about ABT not deleting all the parts, my observation was that all the files had backed up and transferred to S3 successfully but didn't seem to be being fully deleted. However, in the new (successful) 76MB "part" test I just made (above), all the files were deleted from the output directory. So, maybe my mistake on files time stamps or something, sorry.

Thanks for your time.

Re SSL error: Bucket name is just a lowercase ordinary ascii name like "sitebackup" on the Ireland server, going into a pre-defined directory named and entered in ATB as "/ac". As I say, not a problem with using a large one-part file, just when doing it as smaller part files.

Re complicated concepts: I find it best to not attack developers (or anyone for that matter) with pitchforks just because something doesn't make sense! :) - Anyway, your explanations are usually brilliant!