Why You Should Not Use WP Reset Database Snapshots

WP Reset is a popular plugin for resetting or experimenting with a WordPress site. Its database snapshot feature, however, is a poor fit for FimuroHost Cloud Hosting and we ask you not to use it.

What goes wrong

A snapshot is not saved as a separate backup file. Instead, WP Reset copies every WordPress table into your live database under a new random prefix. A normal site might have around 100 tables, so 100 snapshots means around 10,000 extra tables sitting next to your real ones.

We have seen databases grow from a few dozen megabytes to several gigabytes this way, with almost all of the space taken by old snapshots. Each database is currently limited to 1 GB (1024 MB), so snapshots can quickly cause errors, slow queries and failed backups. Limits can change; ask support if you need more.

Use Timeline Backups instead

Your hosting already includes automatic Timeline Backups, which are stored outside your database. At the moment they keep:

• Databases: 60 days
• Website files: 30 days
• Email: 30 days

You can restore any of these from StackCP, so there is no need for in-database snapshots.

How to check and clean up

If you have used WP Reset snapshots, follow these steps. If you are not comfortable with SQL, stop after step 3 and open a ticket; we can help.

1. Deactivate WP Reset in Plugins. Do not reactivate it to delete snapshots on a heavily bloated database, as that can time out.
2. Make sure you have a backup. Confirm a recent Timeline Backup exists or export the database yourself.
3. Find your table prefix. Open wp-config.php and look for $table_prefix. It is usually wp_. Also note the database name (DB_NAME).
4. Open phpMyAdmin from StackCP and select the database.
5. Measure the database. Run this, replacing your_db:

   SELECT COUNT(*) AS tables_found,
          ROUND(SUM(data_length + index_length)/1048576, 2) AS size_mb
   FROM information_schema.tables
   WHERE table_schema = 'your_db';
   
                           
                       

6. List the snapshot sets. Snapshot tables have an extra random prefix in front of your normal one (for example a1b2c3_wp_posts). This groups them:

   SELECT SUBSTRING_INDEX(table_name, 'wp_', 1) AS snapshot_prefix,
          COUNT(*) AS tables_found,
          ROUND(SUM(data_length + index_length)/1048576, 2) AS size_mb
   FROM information_schema.tables
   WHERE table_schema = 'your_db'
     AND table_name NOT LIKE 'wp\_%'
     AND table_name LIKE '%\_wp\_%'
   GROUP BY snapshot_prefix
   ORDER BY size_mb DESC;
   
                           
                       

7. Drop snapshot tables, one prefix at a time. Double-check every table name before deleting. Never drop tables that start with your real prefix alone (wp_posts, wp_options and so on). Dropped tables cannot be recovered except from a backup.
8. Re-run the size query from step 5 to confirm the space has been freed.
9. Remove the old snapshot list that WP Reset kept in your options table. This does not delete any tables; it just clears the stale record:

   DELETE FROM wp_options WHERE option_name = 'wp-reset-snapshots';
   
                           
                       

10. Uninstall WP Reset unless you need its other tools, and rely on Timeline Backups for restore points.

If your prefix is not wp_, replace it everywhere in the queries above.

Need help?

If anything here does not work as described, our team is happy to take a look. Open a support ticket from your FimuroHost client area or message us on WhatsApp at 01818160926.