Troubleshooting Backup

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.

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.

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

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.

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

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):

https://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

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

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?

anybody : (

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?

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

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.

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.

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.

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.