Exclude advice [#209647]

The module says for the option 'Exclude the data from the following tables:' ... "The selected tables will have their structure backed up but not their contents. This is useful for excluding cache data to reduce file size."

I searched on Google for guidance on which standard table I could safely exclude, but found nothing. I assume cache and search table, but there are 6 and 3 of these respectively. Are there any others? Are the contents of these table rebuilt automatically by cron?

Can someone advise?

Comments

Comment #1

ronan CreditAttribution: ronan commented 14 January 2008 at 19:42

The module provides defaults that are reasonably useful. If you don't know the db structure of Drupal inside and out I would just stick to these.

In general, the tables to exclude here are the ones that contain
1) caching data (usually called cache_xxx),
2) data that can be easily rebuilt (eg: search indexes)
3) data that is not relevent for backing up and migrating (eg. sessions).

Another category of tables are those with useful data which does not affect the end-user experience. A good example of this is the access and error logs. The data in the access log is not recreatable and is therefore not as obviously disposable as the caching and index tables, but they do not affect the core functionality of a site, and will tend to bloat a backup file for busy sites. If you are moving data from a live site to a staging site for testing, you will probably want to ignore the log tables.

All of these tables are selected for exclusion by default, but some third party modules create their own caching and indexing tables which may be safe to ignore.

I do not know of a published list of tables which can be safely ignored, so here's the list Backup and Migrate excludes by default:
cache
cache_filter
cache_calendar_ical
cache_menu
cache_page
cache_views
sessions
search_dataset
search_index
search_keywords_log
search_total
watchdog
accesslog
devel_queries
devel_times

If anybody knows of any other tables that fit the descriptions above (even if they're created by third party modules), please let me know.

Comment #2

david@thrale.com CreditAttribution: david@thrale.com commented 14 January 2008 at 21:56

Thank you very much for a prompt and excellent reply. It cut the size of the backup by 60%. Also the tip about log files on staging sites (that's what I am doing building a website off-line) was also excellent. Thanks

Just one thing more, I also have a table cache_content. I have excluded data from this table too, but it was not in your list. I assume this is OK?

Comment #3

ronan CreditAttribution: ronan commented 15 January 2008 at 00:03

Just one thing more, I also have a table cache_content. I have excluded data from this table too, but it was not in your list. I assume this is OK?

I believe this table is created by CCK and I'm not 100% sure but since it's a cache table, it should be safe to exclude this data. If that is the case, then I'll add it to my list of defaults.

IMHO any table prefixed with 'cache_' should only contain cached data, and no code should assume that the cache data is valid or even present. In other words, deleting the contents of a cache table should have no discernible effect (other than speed of page generation) to the end user. As far as I have seen, this is indeed the case at least for core code. YMMV with other modules.

Remember to always test your backups on a stage site first. :)