Support » Plugins » Database backup: “Backup file could not be saved”

  • Resolved Christiaan


    No matter which option I use (to email, to hard drive, or to server) I get the following message when I try to do a backup using WordPress Database Backup:

    The backup file could not be saved. Please check the permissions for writing to your backup directory and try again.

    Does anyone know how I overcome this?

Viewing 8 replies - 1 through 8 (of 8 total)
  • The back-up directory needs to writable by the server, no matter which end-result you choose, it needs to have write access to generate a file.

    Yeah I thought that might be the case but it already has write access (i.e. 755).

    Interestingly if I try to change it it says permissions could not changed, permission denied.

    Mark (podz)


    Support Maven

    Tried 777 ? And the parent folder ?

    Yeap, tried that, and it didn’t work. But I’ve fixed the problem. I was having similar problems getting the Extended Live Archive plugin to work too.

    For whatever reason when a directory is created automatically in my wp-content directory by a plugin something goes wrong with the permissions. The permissions are indeed 775 but it still won’t be writable, and I couldn’t actually change the permissions, it just denies me (using Transmit).

    To fix the problem I simply uploaded and replaced the offending directories manually (in this case /wp-content/backup-ad509/ )

    The permissions issues from script created directories is often because PHP runs as “nobody” in apache, not under your username, so even though your script created the directory, the user “nobody” owns it and has full permissions to it.

    Thanks niziol, is there any way around this?

    It depends, I know with the host I’m on, if I create a directory and want a script to be able to write to it, it needs to be chmod 777, which causes security issues. This may or may not be the case on your host, but I’m guessing it is (you can start with the lowest chmod that will allow writing and go up to 777 and see which one works or ask your host).

    PHP is executed (in my environment anyway) under the user “nobody” and group “nobody” so the only way it can write to a file that is not owned by “nobody” or group accessible by the group “nobody” is with world-writable, so my solution was to have the back-up script I use, WP-DBManager, which I set to write to a directory that was above www document root, so it is not accessible from via URI and that is set as 777. Technically it is still writable by the world, but since it should not be accessible via URI, on people on the server can write to it and my server is set-up in “jail-cells” which seems to mean it would be difficult to get access to it from outside my account. This is the best solution I came up with besides having the script create the directory and having it 755.

    Take prudent measures with permissions, but I think in the end, if someone really wants to hack you, they’ll figure out a way. I’m sure there is an easier/better way, but I just don’t know what that is!


    No, in my case if I create a directory myself it only needs to be 775 to be writable. And its owner is christiaan (me), while the group is www. If a script creates directory it appears to be owned by www and group www.

Viewing 8 replies - 1 through 8 (of 8 total)
  • The topic ‘Database backup: “Backup file could not be saved”’ is closed to new replies.