WP-DBManager

Go to WP-Admin -> Database -> Backup DB . The top of that page checks the backup folder, both binary paths, and whether passthru() , system() and exec() are available, and tells you which one is the problem. The usual answer is that the host does not allow mysqldump to be run at all, or that the path under WP-Admin -> Database -> Settings is wrong. Your host can tell you the correct path. If you added extra flags to the mysqldump or mysql path, remove them. From 3.0.0 the path is passed as a single argument, so anything after the binary name is treated as part of the file name.

That is an empty gzip stream: mysqldump failed and produced nothing, and gzip compressed the nothing. Before 3.0.0 the plugin could not tell. mysqldump | gzip reports gzip’s exit status rather than mysqldump’s, and the file it leaves behind is not empty, so the check for a zero byte backup never fired. The file was renamed with a checksum and, if you had backup e-mails on, sent to you. From 3.0.0 the dump is read back before it is accepted, and one with nothing in it is deleted and reported as a failure. Check any recent .sql.gz backups you are relying on — a real one is far larger than 20 bytes, and gunzip -c yourbackup.sql.gz | head should show SQL.

From 3.0.0 these screens no longer tick every table for you. Tick the tables you want — or the box in the header row to take the lot — then pick Optimize from Bulk actions and press Apply . The old screens pre-selected everything, so a single click acted on the whole database whether or not that was what you meant. Selecting first is the WordPress convention and is a good deal harder to do by accident. The same applies to Empty/Drop Tables , which additionally can no longer empty some tables and drop others in one submit — pick one action, apply it, then pick the other.

Your bookmark points at the old address. In 3.0.0 the screens moved from admin.php?page=wp-dbmanager/database-backup.php to admin.php?page=wp-dbmanager-backup , and likewise for the others. Reach them from the Database menu in the sidebar and re-bookmark. Nothing has been removed. The old addresses embedded the plugin’s folder name, which meant the plugin only worked when installed as wp-dbmanager . It no longer cares what the folder is called.

WP-DBManager uses the mysqldump application to generate the backup and the mysql application to restore it, via the shell. WP-DB-Backup uses PHP to generate the backup. In some cases WP-DB-Backup will work better for you because it requires fewer permissions — not every host allows mysqldump / mysql to be run directly. WP-DBManager also gives you automatic optimizing and repairing of the database on top of backing it up.

Anyone who guesses a backup file name can download your entire database, including your users table, so this is worth fixing rather than hiding. The most reliable fix on any server is to move the folder outside your web root — set Path To Backup under WP-Admin -> Database -> Settings to something like /var/www/example.com/backup-db . Nothing is served, so there is nothing to protect. If it has to stay inside the web root, see Securing The Backup Folder above. On nginx the bundled .htaccess does nothing at all; you need a location block. The Backup DB page requests a file from the folder and reports what your server actually returned, so it is telling you what a visitor would get rather than guessing. If you have verified it yourself and want the notice gone anyway, set Hide Admin Notices to Yes under Settings .