Thanks for the response I will private message your shortly, but to answer your questions on whether I would use this extension in production yet and whether 50 cents per GB is reasonable I would say a definite YES to both. In fact I’m using it in production already, as it hasn’t broken my clients store, the cloud backup works even though there are a few oddities. I downloaded one of the backups and all files/db were intact. I think this extension could be one of the most important extensions for any Magento Live store in the future.

As for other features, what else would anyone want other then a simple utility to backup their entire store offline with the ability to download and restore if need be. If Amazon’s API permits, some sort of progress indicator for backing up to the cloud would be useful for large stores but other than that I think it’s more than ready for production after bug fixes etc 😉

Firstly, thank you so much for trying the extension and reporting feedback so thoroughly.

I’ll flick you an email and we can work through these questions offline, but to answer a couple of your questions for the benefit of other users.

2) The billing for our extension is handled by Amazon’s AWS devpay web service. I’m not sure if it’s considered a feature or a limitation, but when software is using a devpay S3 bucket, it is ‘quarantined’ from the users normal S3 buckets. That means that our devpay software cannot touch your existing buckets, and the devpay buckets cannot be touched by non-devpay applications (like the AWS console as you have observed).

It’s caused a lot of confusion for our users, so I’m not really happy about it, but alas, who are we to tell Amazon they’re doing it wrong.

3) For the automatic backups to occur you will need to make sure cron is running on your webstore. If it is, and automatic backups are enabled, you should see a new backup in the offsite backups list everyday. If that’s not happening and cron is running then there’s something not right.

I’ll work through 3) and 1) the timestamp issue with you offline – expect an email soon.

Lastly, when will it be out of beta? Obviously, we’ll get these issues you have reported fixed up, and there are a few extra features I’d like to add early 2011; fault tolerance, error detection, file system permission detection and cron detection – as described in my MDP presentation. Once I have those things in place, I think we’d be ready to launch.

I’d be interested to hear your thoughts on the extension, would you use it in production yet? Are there features you think are missing? Is 50 cents per gig a fair price?

Just wanted to say been using the Cloud Backup extension for a while now and noticed a few oddities. Which I note below:

1. Weird dates are appearing in admin for backup dates to the cloud. See following image http://db.tt/5fn4GEc
I did a backup today and it dated the creation date as 16th June 1989 what’s that all about?

2. When I login to the Amazon account which I registered for testing this extension under the AWS Management console > S3 tab I don’t see the Bucket I created. Any ideas where the actual bucket is?

3. I selected YES to the Automatic Offsite backup option but again I don’t see these backups in the admin or S3 tab? Is it really doing a backup?

Other then that the extension works like a dream. I’ve downloaded my backups without problems and all files are in order. Any feedback on these questions would be greatly appreciated. One final thing when do you think the software will come out of Beta?

Cheers, Sahus

this message is this:

Could not Activate Cloud Backup.Error: Cannot activate product. Reason: Activation failed. Solution: Please try again shortly and if problems persist contact support.

That’s correct all files and folders were inside of:

/var/www/app/code/community/Aschroder/CloudBackup/lib

However the folder Archive_Tar-1.3.7 had Archive inside of it instead of being in the root of the lib folder. I think something on the install went wrong which meant the folder was not unpacked correctly though I could be wrong. I have another Magento 1.4.1.1 install setup so might try it again and monitor how the install writes the relevant files.

FYI I’m running Ubuntu Lucid Lynx with Apache 2.2 + PHP 5.2.10 if that helps.

Thanks to both of your for the error reports and the info/tips. Looking at your error Sahus – it looks like the path PHP is trying is: /var/www/app/code/community/Aschroder/CloudBackup/lib/

Is that correct, is that where the lib files originally were? If not then it’s possible my technique to add the include path is not working on your Apache+PHP combo, and I’ll need to test and find out why. Please let me know.

Cheers,
Ashley

Thanks for the response. I used your fix for the Archive Folder, tried the backup again which then showed me the error relating to pear.php as you described. Not sure whether you did the same as me to resolve but on line 43 of Tar.php I changed the following:

From:

require_once ‘PEAR.php’;

To:

require_once ‘lib/PEAR/PEAR.php’;

That resolved it for me and now the backups work ;);)

Thanks for your initial guidance, and please let me know if you find a fix for the include_path

Cheers, Sahus

I had the same problem on CE 1.4.1.1 with CloudBackup ver 0.2.3 (beta)

It is a path problem

You will find in /code/community/Aschroder/CloudBackup/lib/

That there is a directory called “Archive_Tar-1.3.7” which has /Archive/archive.php folder/file inside it which is what require_once() is calling.

I moved the Archive folder up one level to /lib and it worked

I then had another similar problem with tar.php calling pear.php (/lib/pear/pear.php) with similar resolution.

Please note these changes are temporary for me until I sort the real issue which is my include_path but hopefully will point you in right direction
Double disclaimer: I’m a beginner 🙂