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:
- restore the full backup in a temporary database
- 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)
- 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:
- copy the Newsletter option rows on the production database, eventually you may need to remove the already present “meta_key”
- 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)
- 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.