Backup and Recovery

It may happens you need to restore all the Newsletter settings and generated content from a blog backup but without restore all the blog database.

It’s a relatively simple task as far as you can restore the backup on a different and temporary database (anyway few technical skills are required).

So, to recover only the Newsletter’s data from a database backup, follow the steps below:

  1. restore the full backup in a temporary database
  2. you should be able to list the tables and identify the Newsletter’s tables: they are named like wp_newsletter* (see below about the “wp_” prefix)
  3. you should even find the wp_options table which contains the Newsletter settings on few “meta_key” named starting with “newsletter*”

Now that you have identified the data to be move to the production database, you can use different tools. Here just an example of how to proceed:

  1. copy the Newsletter option rows on the production database, eventually you may need to remove the already present “meta_key”
  2. on the temporary database, drop all the table but the Newsletter’s ones and then dump the database to have an SQL file (MySQL comes with a useful mysqldump command but it’s easy to use a graphic client)
  3. import the dump on the production database

There are not files related to the Newsletter plugin generated and stored on the file system, so there should nothing to download and/or upload. In the case you coded a custom theme, the folder wp-content/extensions/newsletter/emails/theme should be moved as well to the production server.

About the tables’ prefix

WordPress prefixes its tables with a prefix set on first installation. Newsletter uses the same prefix for its tables (the prefix is used for multisite installation and/or for database shared installations).

To find that prefix you can look at your wp-config.php file or directly inside the Newsletter’s diagnostic panel, see the picture below.


If for some reasons the production database where you want to restore the Newsletter’s data uses a different table prefix, you should edit the database dump. It’s a lot more easy to rename the table names on the temporary database to match the ones of the production database before start the restore operations.