Akeeba Backup for Joomla!

Tuesday, 10 May 2011 12:34 CDT

michael.hermary

Mandatory information about my setup:

Have I searched the forum before posting? Yes
Have I read the Troubleshooting Wizard before posting? Yes
Have I read the documentation before posting? Yes
Joomla! version: 1.5.6 (ya, I know it's old)
PHP version: 5.2.17
MySQL version: 5.1.54
Host: ICDSoft
Akeeba Backup Professional version: 3.2.7

EXTREMELY IMPORTANT: Please attach your Akeeba Backup log file in order for us to help you with any backup or restoration issue.

Description of my issue:

I upgraded from Akeeba 3.1.2 to 3.2.7 and now have 2 issues:

1. The permissions of all backup files are set to 666, except .j01 which is 755 as usual. So if I break it up into 3 5Mb files, .jpa and .j02 are 666 and .j01 is 755. If I leave it as one 15Mb file, it's .jpa at 755. Same things happen if I do .zip files.

2. Files are no longer being uploaded to Amazon S3, regardless of the above scenarios and seemingly regardless of other configuration settings I tweak.

Thanks,
Michael

Tuesday, 10 May 2011 15:41 CDT

nicholas

Akeeba Backup never changes the permissions of the backup archive parts. If you want different permissions for files created by PHP, please ask your host.

That said, 0666 is adequate permissions for uploading the files to S3. These permissions mean "read and write permissions to owner user, owner group and everyone else". In fact these are adequate permissions to do everything with the file!

That said, your backup profile is set to "All databases (archive file)". This is not a supported scenario for S3 transfers. We only support full site backups to be transferred to S3. Did that work for you in the earlier versions?! It was never something we planned :)

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, 10 May 2011 18:10 CDT

michael.hermary

Thanks for your reply. I mentioned the 666 permissions because they just started doing that when I updated Akeeba Backup, so I figured it has at least something to do with that.

"All databases" backups have always gone up to S3 no problem. In fact, it's important to use to store it off-site, so that is the reason we use Akeeba. I guess we'll have to find another way to get them up to S3.

Still, our full site backups have not been making it up either. I did finally get one to almost work with the 'Process each part immediately' box checked and a 10Mb split archive size. .j02 through .j17 made it up, but no .jpa or .j01. Same if I do a 5Mb split.

I've attached those logs.

Thanks very much,
Michael

Wednesday, 11 May 2011 04:45 CDT

nicholas

Hm... I just checked the code and run a few tests and yes, the parts do upload to Amazon S3. The post-processing engine scans all produced files (archives or SQL) and uploads them. That wasn't an intended feature to be honest, but it's working.

You seem to have a server-side problem there. Please dump the structure of your jos_ak_stats table and paste it here. The easiest way to do that is to run a show create table jos_ak_stats and paste the result in your next post. I think that some fields are missing from it.

For good measure, please ZIP and attach the backup log file from your full site backup. I'd like to take a look at what is going on during the uploads. It may be something as simple as a timeout error or as complex as a network failure which prevents all parts to be uploaded to your S3 account.

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, 11 May 2011 06:55 CDT

michael.hermary

Thank you (I tried to upload the log last time, but it didn't seem to happen).

CREATE TABLE `jos_ak_stats` (
`id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
`description` varchar(255) NOT NULL,
`comment` longtext,
`backupstart` timestamp NOT NULL DEFAULT '0000-00-00 00:00:00',
`backupend` timestamp NOT NULL DEFAULT '0000-00-00 00:00:00',
`status` enum('run','fail','complete') NOT NULL DEFAULT 'run',
`origin` enum('backend','frontend','cli') NOT NULL DEFAULT 'backend',
`type` enum('full','dbonly','extradbonly','alldb','fileonly') NOT NULL DEFAULT 'full',
`profile_id` bigint(20) NOT NULL DEFAULT '1',
`archivename` longtext,
`absolute_path` longtext,
`multipart` int(11) NOT NULL DEFAULT '0',
PRIMARY KEY (`id`)
) ENGINE=MyISAM AUTO_INCREMENT=1773 DEFAULT CHARSET=utf8

Wednesday, 11 May 2011 11:48 CDT

nicholas

So, that's the problem! Here's the correct structure:

CREATE TABLE `jos_ak_stats` (
  `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
  `description` varchar(255) NOT NULL,
  `comment` longtext,
  `backupstart` timestamp NOT NULL DEFAULT '0000-00-00 00:00:00',
  `backupend` timestamp NOT NULL DEFAULT '0000-00-00 00:00:00',
  `status` enum('run','fail','complete') NOT NULL DEFAULT 'run',
  `origin` varchar(30) NOT NULL DEFAULT 'backend',
  `type` varchar(30) NOT NULL DEFAULT 'full',
  `profile_id` bigint(20) NOT NULL DEFAULT '1',
  `archivename` longtext,
  `absolute_path` longtext,
  `multipart` int(11) NOT NULL DEFAULT '0',
  `tag` varchar(255) DEFAULT NULL,
  `filesexist` tinyint(3) NOT NULL DEFAULT '1',
  `remote_filename` varchar(1000) DEFAULT NULL,
  `total_size` bigint(20) NOT NULL DEFAULT '0',
  PRIMARY KEY (`id`),
  KEY `idx_fullstatus` (`filesexist`,`status`),
  KEY `idx_stale` (`status`,`origin`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8;

Try reinstalling Akeeba Backup 3.2.7 (without uninstalling the previous version). If the structure of that table is still not changed or if you receive a rather big red box with an error message in pretty big letters, ask your host to give ALTER TABLE privileges to your database user for your site's database. That should allow you to reinstall Akeeba Backup properly.

If all else fails, drop the stats table and create it using the SQL command I provided above.

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, 11 May 2011 19:08 CDT

michael.hermary

I seem to already have 'Alter' privileges and 'Alter SP' privileges. Not sure if that means I have 'Alter Table' privileges.

Anyway, the reinstall didn't work, but creating the table manually did and now everything is working beautifully. Thanks!

Michael

Thursday, 12 May 2011 01:50 CDT

nicholas

Alter privileges is basically "ALTER TABLE" as I said we'd need. I'm puzzled why the update/reinstallation didn't work. Which version of MySQL are you using? Did you receive any error messages on your screen when the update ran?

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!

Support