WordPress.org

Ready to get started?Download WordPress

Forums

Troubleshooting Backup (28 posts)

  1. paperlion
    Member
    Posted 8 years ago #

    I have the 1.5 and the new 1.6 Backup plug-ins. Both (activated alternately) hang and don't complete the file backup - whether the folder files or the database.

    Anyone have a thorough way to troubleshoot these modules?

    Thanks

  2. Lorelle
    Member
    Posted 8 years ago #

    First, begin by deleting the original backup plugin from its directory in your plugins folder and uploading a brand new copy. Not all uploads transfer completely so this is a good preventive step.

    Make sure you have the LASTEST version of WordPress (see the DOWNLOAD link at the top of this page). If not, upgrade.

    Try a backup to your server with only the defaults - click nothing in the optional tables. See if that works.

    If it still doesn't work, come back and let us know.

  3. paperlion
    Member
    Posted 8 years ago #

    Lorelle, thanks for your help.

    Am running a fresh copy of 1.5.1.3.

    Deleted and reinstalled all files of LaughingLizard's 1.5 plugin BackupRestore, I figured I'll start with that one since I have some older backups to test with done with this version. (BTW, have the backups folder permissions set to 777 -not sure if that's necessary -or safe -when he says to set write permissions, not sure if he means all this).

    'Back up Database' now tells me 'Backup Successful'. Clicking the 'Download the new Backup sql file' generates an html page that stops (almost immediately -doesn't seem like a timeout problem) in the middle of the options table -doesn't even get near the records entries. This repeats itself when I try the whole routine again.

  4. Mark (podz)
    Support Maven
    Posted 8 years ago #

    LL's plugin is outdated.
    The one you need is Skippy's
    http://www.skippy.net/blog/category/wordpress/plugins/wp-db-backup/

  5. Lorelle
    Member
    Posted 8 years ago #

    And the new version by Skippy is version 1.6 - so that is what I thought you were talking about! Yikes.

    Skippy's backup is awesome! Very easy and will easily handle huge backup files with compression.

  6. paperlion
    Member
    Posted 8 years ago #

    Actually had been running Skippy's - that was my reference to 1.6, and it locked up. Will try it again.

  7. paperlion
    Member
    Posted 8 years ago #

    Well, I thought I nailed it - was flat out of disk space. That doesn't seem to be the problem any more - might explain why the progress bar stopped smack in the middle though before -fellow frustrated backer-uppers take note!

    Now 1.6 (Skippy's of course) is going through the motions, (have the options set to 'save to server') and is even asking if I want to download a copy. I select yet and notice this line on the link bar at the bottom (copied it though from the download 'here' link properties):

    http://www.mysite.com/wordpress/wp-admin/edit.php?page=wp-db-backup.php&backup=found_fdn3_wp1_20050814_011

    wp-content/backup permissions are set to 755.
    Other permissions are right out of the box.

    Oh yea, nothing is saved in backup (I did several refreshes) and though my file download dialog box pops up [getright], the only thing that's downloaded is this (inside a file called edit-001.php):

    File not found:
    found_fdn3_wp1_20050814_011.sql.gz

    Return to Backup

  8. paperlion
    Member
    Posted 8 years ago #

    Oops. Permissions on wp-content/backup is set to 775 not 755.

  9. paperlion
    Member
    Posted 8 years ago #

    PS - Nothing in the readme about the .pot and .mo files of the same name as the main .php file. Are these supposed to be installed anywhere?

  10. paperlion
    Member
    Posted 8 years ago #

    anybody : (

  11. paperlion
    Member
    Posted 8 years ago #

    Anybody know their way around backup and restore?

    One more question: if restoring with phpmyadmin, I have to choose an encoding scheme, such as UTF-8, latin1 or others.

    Although I haven't changed WPs default setting of UTF-8, I believe any non-specifically UTF-8 indicated command-line SQL backups are saved as Latin1 (including all the backups done with the various WP plugin utils). Therefore, which encoding choice is correct when doing a restore?

    Podz, Lorelle - where did everybody go. Is there a WordPress convention going on I don't know about?

  12. Beel
    Member
    Posted 8 years ago #

    I am running my site off W2K with Apache2 and 1.6 doesn't work. Creates a gz file (which of course I wouldn't want) but with nothing in it. I went back to 1.5.

    It is not all peachy keen, though. I get a database error - something about a resource table not existing (which it doesn't), but the backup is created just fine. Now do I try to track down that error or see if I can get 1.6 to work... ?

  13. skippy
    Member
    Posted 8 years ago #

    Why wouldn't you want a .gz file? It's a gzip compressed file, and WinZip handles it just fine.

    You might be experiencing some trouble due to your Win2K server. I don't have access to any, so I was unable to test this plugin on such servers. Is there anything in your error log?

    paperlion: the .pot and .mo files are used to translate the admin interface into your native language if you're using a non-English language for WordPress. If you're using English, you may safely delete those files.

    The backup link presented to you after saving the backup to the server is a redirect. It first loads the Backup page, then sends you the file. Once the transfer is complete (or aborted), the file is deleted from the server. If you don't want the file to be deleted from the server, then don't click that link. Download the backup file manually using your FTP program.

  14. Beel
    Member
    Posted 8 years ago #

    Nothing in the error logs. I will dink around with it when I get the time. For now, 1.5 backs up the core tables just fine when deselecting the gzip. It just bombs on other non-WP tables but that's fine.

  15. paperlion
    Member
    Posted 8 years ago #

    skippy: thanks. I kept my ftp s/w open during the 'backup'. No files ever made it to /backup even before I clicked the 'save to disk'. Actually, they may have - but they're essentially empty (3k for what are normally 25mb+ files). Any ideas?

    Also, any answers on the other stuff, esp. re: encoding details utf-8 vs latin1 on a phpmyadmin restore and how it works -getting shifted between utf on the blog and latin on the backups? thnx.

  16. James
    Happiness Engineer
    Posted 8 years ago #

    One more question: if restoring with phpmyadmin, I have to choose an encoding scheme, such as UTF-8, latin1 or others.

    Always restore the database backup under the same encoding scheme that it was saved under. So, if the database was latin1 when you created the backup, then you should restore it as latin1. If the database was utf-8 when you created the backup, then you should restore it as utf-8.

  17. paperlion
    Member
    Posted 8 years ago #

    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'?

  18. skippy
    Member
    Posted 8 years ago #

    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.

  19. paperlion
    Member
    Posted 8 years ago #

    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.

  20. skippy
    Member
    Posted 8 years ago #

    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?

  21. paperlion
    Member
    Posted 8 years ago #

    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.

  22. paperlion
    Member
    Posted 8 years ago #

    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?

  23. skippy
    Member
    Posted 8 years ago #

    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.

  24. paperlion
    Member
    Posted 8 years ago #

    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.

  25. paperlion
    Member
    Posted 8 years ago #

    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.

  26. skippy
    Member
    Posted 8 years ago #

    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.

  27. paperlion
    Member
    Posted 8 years ago #

    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.

  28. press
    Member
    Posted 7 years ago #

    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.

Topic Closed

This topic has been closed to new replies.

About this Topic