Troubleshooting Backup

thanx, macmanx. Was confused because I understood backups default to latin1 even if blog content settings are utf.

Anyone know why the backup files might be misbehavin’?

paperlion: try using 777 on your backup directory.

Here’s how UNIX permissions work:

* the first number is for the user owner of the file
* the second number is for the group owner of the file
* the third number is for everyone else

So:
755 means the owner can do everything, and everyone else can read the file
775 means that the user owner and the group owner can do everything, and everyone else can read the file
777 means everyone can do everything

Unless you’re sure that the group account used by the web server has been set as the group owner of the file, please try mode 777.

Skippy thanks, but this wasn’t enough. /backup is set to 777, but your 1.6 hangs about a third of the way through the backup (for that matter 1.5 hasn’t been an honor student lately either).

A gz file, appropriately named, was saved to /backup, but it was just 2kb! I decompressed it, and opened it in Notepad++. It looked good until its last line, which was this:

# End of data contents of table wp1_linkcategories
<line>

There seems to be plenty of disk space on the server – I checked at the host.

One interesting piece: the file properties of the .gz file created in /backup shows itself as 644. Don’t know how it incarnated this way or if this has anything to do with the problem, but it seems suspicious enough to mention.

thanks everybody for your help.

The files created by wp-db-backup will be assigned whatever umask exists for the target directory. wp-db-backup does not do anything with file permissions. It simply creates the files, owned by the same user that runs the PHP process (usually the same user as used by the webserver).

The fact that the process hangs is curious. The javascript in the status bar should prevent the script from timing out. The backup should dump only 10 or so rows at a time, so even the largest tables should backup without problem. Indeed, it was tested on a database over 30 megs uncompressed, and it went off without a hitch.

Nothing in your web server error log?

Gee. Didn’t think of looking in the log; can’t imagine why!

Two things. The backup stops just before the halfway area on the progress bar almost immediately after starting -doesn’t seem like a timeout thing, with this text underneath:

Backing up table “wp1_post2cat”…

Then, noticed this on the errors log:

[Tue Aug 16 18:08:36 2005] [error] [client ip] File does not exist: /home/found/public_html/403.shtml
[Tue Aug 16 18:08:36 2005] [error] [client ip] client denied by server configuration: /home/found/public_html/wp-fdn3/wp-admin/edit.php
[Tue Aug 16 18:08:11 2005] [error] [client ip] File does not exist: /home/found/public_html/wp-fdn/wp-rss2.php

Don’t know if the last (which is really the first about wp-rss2) is relevant, but the edit.php denial sure is, and probably the 403 too.

Don’t know how though.

Thanks once again.

FWIW, this is a new upgrade: 1.5.0 –> 1.5.1.3. Deleted all files except /content and config.php and uploaded the upgrade. Any issues here maybe?

I’d ask your host about the specific conditions they’ve defined that will generate the “client denied by server configuration” error. It’s clearly an Apache thing, and not generated by PHP, WordPress, or wp-db-backup.

Skippy, I’m impressed! Webhost told me I’m hitting up against an anti-denial of service tool called mod_dosevasive.

Do you know of any workarounds – he’s probably going to tell me not to use your backup util, but I don’t want to give sql or phpmyadmin access to site editors; besides those methods are a lot more difficult to carry out and I’d rather not have to be on constant backup duty.

Thanks.

I’ve got to put a plug in for the greatest webhost – Thomas at livehost.net. He found the problem Skippy, and I thought I should post it to save any future anguish. He installed a tool called mod_dosevasive that is trying to prevent Denial of Service attacks. It’s designed to allow only so many hits to the server in an elapsed period of time by the same user. It was set to allow 150 hits to the server in a second, more than that, and it would block the IP for 5 seconds.

Here’s what he did:

The script would backup one table, and rerun the same script over and over… Each time probably accessing some of the same components twenty or thirty times. Since the problem was too many accesses to the same objects per second, the script just needed to be slowed down.

wp-admin/edit.php started like this:
<?php
require_once(‘admin.php’);
$title = __(‘Posts’);
$parent_file = ‘edit.php’;
require_once(‘admin-header.php’);

I added two sleep statements and it works great. And the same first lines of edit.php look like this:

<?php
sleep(1);
require_once(‘admin.php’);
sleep(1);
$title = __(‘Posts’);
$parent_file = ‘edit.php’;
require_once(‘admin-header.php’);

Now if I can get the encoding straight.
thanks for your help everyone.

paperlion: I’d not heard of that module before. Interesting. I’m glad you were able to get it resolved!

I’ve just released WP DB Backup v1.7, which unfortunately means you’ll need to re-apply your changes if you choose to upgrade. If 1.6 works for you, there should be no pressing reason to upgrade at this time.

Actually, I saw a post about 1.7 and did it – seems to work okay – note that the only changes done to make 1.6 work were to WP’s own edit.php file.

Skippy,

Thanks for the great plugin and I apologize in advance for the newbie question on file permissions.

I received the directory permission error message cited in other posts. And yes, when I change the permission to 777 everything works fine. It does not at 755 or 775.

My question is this. By making the directory 777, are we exposing the backup data to the world to see?

Thanks.