Notes on Web Development
- // TESTING
- $files = array("js", "media");
- // TESTING
- $files = array("js", "media");
Please get the latest version on Magento Connect as soon as you can…
And sign up to be notified of future bug fixes/features – I’ll aim for more of the latter and fewer of the former.
PS: Big Thanks Oren for bringing this to my attention.
You might also be interested in:
Love the idea of Cloud Backup so thought I would install and try out the solution. So far so good I have managed to install the extension, obtain an API key and create the relevant settings within System>Configuration>System.
When I then go into System>Tools>Offsite Backup and create a backup I’m presented with the following error:
Fatal error: require_once() [function.require]: Failed opening required ‘Archive/Tar.php’ (include_path=’/var/www/app/code/local:/var/www/app/code/community:/var/www/app/code/core:/var/www/lib:.:/usr/share/php:/usr/share/pear:/var/www/app/code/community/Aschroder/CloudBackup/lib/:/var/www/app/code/community/Aschroder/CloudBackup/lib/:/var/www/app/code/community/Aschroder/CloudBackup/lib/’) in /var/www/app/code/community/Aschroder/CloudBackup/Model/Backup.php on line 155
After going back into the admin I noticed it created a bucket but when I click on view the backup is empty. I thought there might be permission issues but the folder was chmod 777 all the way down to the Tar.php file which was set to 666 so I changed this to 777 and tried again. Still got the same error… Any ideas what it might be???
I looked into Model/Backup.php and it seems to be moaning about this code here:
PATH_SEPARATOR . Mage::getBaseDir(‘app’) .
Any help or guidance would be greatly appreciated. FYI I’m using Magento CE 126.96.36.199 on standard LAMP stack.
thought there might be permission issues but the folder was chmod 777 all the way down to the Tar.php file which was set to 666 so I changed this to 777 and tried again. Still got the same error… Any ideas what it might be???
I had the same problem on CE 188.8.131.52 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 🙂
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:
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
Hi, Matt and Sahus
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.
That’s correct all files and folders were inside of:
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 184.108.40.206 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.
Hello, I have a problem whit this extension. I put my Access Key ID and I get a error
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.
@israel How long have you been experiencing this error? Sometimes there is a delay from when you sign up to when you can activate, but not normally more than an hour or two.
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?
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?
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 😉
Comments are closed.