Thread

Just a question on this release. Is there a method for upgrading without disabling the backup utility. The utility has worked fine on all our various client sites, and we’ve established protocols with the various administrators, that they are suppose to run the backup utility before making any site modifications (besides data entry). I’d prefer not to give them access to PHPMyAdmin, since they can do a lot of damage accidently with that. And while the ISPs involved are all mostly very good about backups, the safety of having a file on hand to restore to is very nice.

I’d personally start moving to a different option.  It just isn’t reliable in all situations.  (I miss it too, though.  I’d backup a single table before running a risky query on it- or use it to view the file structure rather than having to open up a hosting cp or dig through the file.)

Er.  Anyway.  Not reliable.  But I took a look at the file- looks like they just commented out the code- the main functions and such are all still there.  Could likely remove comments in cp.utilities.php and get it working w/out killing yourself.  But I’d say by 2.0 you’ll need to let it go.  Given that it’s not dead reliable, it would be too much work to keep hacking it back in.

So the plan is to totally remove it in EE 2.0 instead of repairing the query? Well, that sucks. Obviously, I can live with it, but I guess I’ll need to find away to give client administrators an easy way to backup, without allowing them access to PHPMyAdmin.  We had one client administrator who destroyed their backed database, because the were too impatient waiting for a screen to redraw in PHPMyAdmin once. I don’t know how they did it, but they managed to drop a table. 

Since that, we decided that access to PHPMyAdmin is just too much power for the administer that only has to administrate once every few moons.  The ability to backup, run repairs, and optimize tables via the EE Control Panel was a great way to make casual administrators feel powerful, while limiting potential damage.

Nope- I’ve no idea for what the plan is with 2.0.  I’m just betting it will be different enough that this hack won’t be reasonable to maintain.  (If you want it in there- be sure to make a feature request.  The crew pays attention.)

And yep- I wouldn’t be keen on giving them phpmyadmin access either.  But- I try to make the server guys handle it via regular backups.  And then a backup by me when I upgrade.  The backup in EE was really sweet- but if it’s not consistently reliable under a variety of server setups, it can cause big trouble.

Thanks Robin.  I guess I’ll just hold off the 1.6.2 upgrade, until I finish mentally debating the pros and cons. I’d prefer not to hack.

Yea- the hack is kinda evil.  I briefly considered it and figured it wasn’t worth it.  But if you FR?  I’d second it.  It’s not a super high priority to me, but it is dang handy.

So the plan is to totally remove it in EE 2.0 instead of repairing the query?

This issue is much more complex than that. The current plan is to review a number of options for providing backups until we find one that 100% reliable.

O’ I assumed that. I guess my full thought was, if they’re prepared to remove instead of repair, then the issue must be major. But I was actually looking for the confirmation, I didn’t mean to offend. It was more surprise that the function couldn’t be easily (or with moderate effort) repaired.

O’ I assumed that. I guess my full thought was, if they’re prepared to remove instead of repair, then the issue must be major. But I was actually looking for the confirmation, I didn’t mean to offend. It was more surprise that the function couldn’t be easily (or with moderate effort) repaired.

The issue only impacted a small number of people, probably around 1% of installations, if that. The problem is that if you rely on the previously included utility and you’re in that 1% there is no recovery if it fails. For something as important as backing up that simply wasn’t acceptable to us.

The actual issue is complex because it involves the various versions and settings of php that can’t be controlled reliably by a php script.

Oh, and no offense taken 😊

As I am the one who made the decision to remove it, I can comment as well.

Thanks to the various PHP configurations out there, one could experience a number of problems with our backup utility that would cause it to fail either a) completely with a blank screen; or b) silently with a bad backup.  It was the latter that was causing people to suffer data loss.  People had lost months of data because they had relied solely on the ExpressionEngine created backups and their host had no other MySQL database backup system in place.  The reasons for these failures typically were a lack of memory allocated to PHP or to MySQL for the size of the database.  Also, PHP could sometimes timeout before the backup was complete.  Certain setting can be modified at runtime in a PHP script, but not all of them and some hosts actually disable the ability to even change those.  The curse of distributed opposed to hosted software.

To really make a fully working backup utility in ExpressionEngine, it would require using code very similar to phpMyAdmin’s, if not an almost exact duplicate.  As those who have used phpMyAdmin know, even it has its limits regarding database size.  Not only that, but for larger databases it can be extremely, extremely slow.  Creating what amounted to an entire new module’s worth of code was not very feasible for us to do in a short order with other, larger projects on our plates.  And, you know, a web host created backup, done through the MySQL command line tool is far faster, less memory intensive, and more reliable than anything done through PHP.  Why hosts do not provide this service and backups on a nightly basis is beyond me.  If your host does not do this already, demand it.  Nothing is more precious than your site data.

Still, as Robin mentioned, we only have the links and code commented out.  We have hope that we might be able to provide a more reliable backup utility in the future, one with better error reporting if PHP on the machine is simply incapable of creating a backup.  We shall see though and we cannot make any promises, obviously.

For some it might be worthwhile to take a closer look at MySQLDumper.

Looking at the now missing backup utility, am I right that the cron_db_backup plugin is gone as well? And - even more relevant - users that have implemented this plugin at their sites will most likely not recognize that the plugin isn’t backing up anymore if they update to 1.6.2?

I’ve taken a look at the change log, the update guide and the version specific notes for 1.6.2, but it seems there is no mentioning of the cron related plugin anywhere?

I have to agree with Silenz that the MySQLDumper is a really great backup utility and probably even a little easier and more powerful than PHPMyAdmin.

Mark

Looking at the now missing backup utility, am I right that the cron_db_backup plugin is gone as well? And - even more relevant - users that have implemented this plugin at their sites will most likely not recognize that the plugin isn’t backing up anymore if they update to 1.6.2?

I’ve taken a look at the change log, the update guide and the version specific notes for 1.6.2, but it seems there is no mentioning of the cron related plugin anywhere?

The Cron DB Backup plugin has been removed from our Plugin Library for the same reason.  As it was never a part of the ExpressionEngine download, there would be no reason to have it mentioned in the 1.6.2 version notes or change log.

Further, the plugin had its own stand alone code for backing up the database, based on what was included in the Utilities section but separate.  Thus, the plugin will still work on those sites running 1.6.2, even though we would discourage its usage.

...the plugin had its own stand alone code for backing up the database, based on what was included in the Utilities section but separate.  Thus, the plugin will still work on those sites running 1.6.2, even though we would discourage its usage.

Thanks for the clarification - I wasn’t aware of this.