Still won't work for me. :-/

Is it possible that it's something server side?

Because I have two other WP sites and this works perfectly for both of those.

I'm afraid that I don't know much about Windows servers, so I think it would be best to ask your host what needs to be done so that PHP can write to that directory.

unfortunately, my site is hosted on windows. so i am unable to use my ftp program to change the permissions of my backup folder so that the backup plugin can write to it. thus, i get the following error message each time i try to run the backup:

WARNING: Your backup directory is NOT writable! We cannot create the backup files.

must i use an program like plesk or get my hosting provider to change the directory permissions?

Thanks for the explanation. At least I feel more comfortable using it now.

I don't presume to be a security expert, and I wouldn't advise anybody to do something that he or she feels is insecure. However, here are a few reasons why I don't think making the backup directory world-writable is too great a concern.

* No one should know the path to the backup directory, as it's a hash unique to your database password.
* If someone were to have the kind of access that listed your site's directories, they're likely going to be able to dump your database directly anyways.
* With safe_mode on, a malicious script could not operate on a file with a different owner; if the person planting the malicious script could set the appropriate ownership, directory permissions wouldn't be much of an issue.
* The backup folder has no scripts that are part of or included by WordPress, so there's no danger of someone modifying a core file.
* Backup files should be in the backup directory only for the minute or so it takes to create and download/email them.
* Making a directory world-writable for uploads seems to be a common practice.

Why do you say that? What scenario do you have in mind?

My understanding of 777 is that it allows anyone to perform said actions (read, write, execute). Which to me means that 1) They could load and run malicious scripts/whatever. And 2) they would be able to download one of my database backups. And thus have access to the sensitive information contained.

I do not store my database backups in that folder. But they are stored there temporarily during the backup process, which to me is a security vulnerability if someone has access.

1) Is there any way we can make whatever user WP Database uses part of a group so that public has no access whatsoever to that directory?

2) Isn’t 777 a huge security vulnerability?

Question. It seems the advice given for the "Backup" directory is to change the permissions to 777. I've managed to get it working using 773 (removing public read access).

I have two questions...

1) Is there any way we can make whatever user WP Database uses part of a group so that public has no access whatsoever to that directory?

2) Isn't 777 a huge security vulnerability?

obviously these messages were generated because the write permissions need to be set. but why two messages?

You need the backup directory for the backups; if it doesn't exist, the plugin tries to create it. In your case, the backup directory doesn't exist and the parent directory isn't writable, so you get two error messages.

btw, why “96d3c”? how is that number generated?

It's based on a double hash of your database password (don't worry--it can't be reverse-engineered). That makes it practically impossible to guess, helping to reduce the possibility that someone could guess the path to one of your backup files.

how do i change my backup directory (”backup-96d3c” located beneath my WP installation is less than ideal for me)?

You can change the following line:
define('WP_BACKUP_DIR', 'wp-content/backup-' . $rand);

to something else:
define('WP_BACKUP_DIR', 'some/other/directory/no/higher/than/the/WordPress/directory/');

when wp-db-backup saves a backup to a directory, what does it do with any backups that already exist in said directory?

Nothing.

is there any documentation for the wp-db-backup plugin?

There is a readme file included with the plugin download. That's about it.

can _scheduled_ backups be set to save to a directory rather than being sent via email?

Not currently. For one thing, I don't want to encourage people to leave backups on their server, as it increases the possibility that their data will be compromised. For another, there's a good risk of someone filling up their drive with backups.

how are backup names constructed?

A combination of the database name, the date, and the time.

i just installed and activated wp-db-backup 2.1.4 and when i went to the Manage -> Backup tab the following messages were displayed:
.
--
WARNING: Your wp-content directory is NOT writable! We can not create the backup directory.
/wordpress/wp-content/backup-96d3c/
--
WARNING: Your backup directory is NOT writable! We can not create the backup directory.
/wordpress/
--
.
.
obviously these messages were generated because the write permissions need to be set. but why two messages?
.
i'm assuming that the first message is because wp-db-backup want's to create the "backup-96d3c" directory. (btw, why "96d3c"? how is that number generated?)
.
why is there a second message that's referring to the root of the WP installation? is wp-db-backup attempting to write some additional information?
.
.
how do i change my backup directory ("backup-96d3c" located beneath my WP installation is less than ideal for me)?
.
.
when wp-db-backup saves a backup to a directory, what does it do with any backups that already exist in said directory?
.
.
is there any documentation for the wp-db-backup plugin?
.
.
can _scheduled_ backups be set to save to a directory rather than being sent via email?
.
.
how are backup names constructed?
.
.
thanks,
david

Thank you for your respond. It works. ;-)

Try changing the ownership. One way to do that is to delete backup-7061b using your FTP program, then re-create it.

I just tried to backup my database but your plugin won't work unfortunately. Everytime there is a popup with the text: "The backup file couldn't be saved. Please check the permissions for writing to your backup directory and try again. Couldn't open the backup file for writing!"
I've changed the permissions for /wp-content/backup-7061b to 777, but it still not work. Could I do something else?

works fine for me, thnx a lot!

Try deleting the directory backup-xxx71 with your FTP client and replacing it with one of the same name (this is one way of changing the ownership instead of the permissions).

Dude it won\'t work.
wp-content 777, it will create any folder I define in de plugin\'s php on 777
like: backup-xxx71 (on 777)
But it won\'t write anything in it. I get the error menitioned above.
I use WP 2.1.1

I once played around and made it work somehow. I didn\'t touch the files and permissions since then and thought it would work again - doesn\'t.
Btw: very good and usefull plugin. thnx for your efforts.

Try changing this line

define('WP_BACKUP_DIR', 'wp-content/backup-' . $rand);

to this

define('WP_BACKUP_DIR', 'wp-content/backup');

to see if it will use your old directory.

All permissions for wp-content, wp-content/backup (made by me) and wp-content/backup-8f3c0 (made by the plugin) are set to 777, but I still get a 'check permissions' error (it's in Dutch actually, so is my WordPress).

Any idea what can be the problem?

In earlier versions, the backup directory was wp-content/backup/, but that was changed to wp-content/backup-["random" letters]/ for security reasons.

One solution is to make your wp-content directory writable--temporarily--by changing the permission to 777. Then let the plugin create your backup directory, make sure it's writable, then change back the wp-content permissions so that it's no longer writable.

"WARNING: Your backup directory is NOT writable! We can not create the backup directory.
/home/fulwood/public_html/wp/"

What should the permissions be on the backup directory? I have no idea. I wonder whether I may have broken something in upgrading from WP 2.0.7 as the backups worked fine with that.

Thanks in advance.