WP-DBManager

About this plugin

location ^~ /wp-content/backup-db/ { deny all; }

wp dbmanager tables
wp dbmanager backups
wp dbmanager backup --yes
wp dbmanager backup --no-gzip --yes
wp dbmanager restore <file> --yes
wp dbmanager delete <file>... --yes
wp dbmanager email <file> [email protected] --yes
wp dbmanager optimize --all --yes
wp dbmanager repair wp_options --yes
wp dbmanager empty <table>... --yes
wp dbmanager drop <table>... --yes

optimize and `repair` take table names or `--all`. `empty` and `drop` take names only: emptying or dropping every table in a database is not maintenance, and the screen at least shows you the list before you tick it.

wp dbmanager checks no capability. WP-CLI has no logged-in user unless you ask for one with `--user`, and whoever can run it can already read the credentials in `wp-config.php`, so a check would refuse every scheduled backup script while protecting nothing. The `install_plugins` gate on the admin screens is unchanged.

Questions

My database is not backed up / My backup file is 0Kb

• 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.

My gzipped backup file is about 20 bytes

• 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.

I clicked Optimize (or Repair) and it says “No Tables Selected”

• 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.

The Database pages say “Sorry, you are not allowed to access this page”

• 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.

What is the difference between WP-DBManager and WP-DB-Backup?

• 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.

My backup folder is reported as visible to the public

• 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.