Hoi, With all respect, what is the purpose of this theoretical excercise ? You _may_ be able to ommit selected files when you make a backup. This comes at a cost. The cost is the time that it will take to recreate the data pr the loss of that data. This is fairly obvious. It is equally obvious that a recovery can take a considerable amount of time. When the system is essentially available for users, this may be not that much of a problem. When the system is not available for users for an extended period of time, it may be considered problematic.
The one thing missing in this discussion is a risk assessment and the importance given to maintaing our infrastructure availability. When downtime is considered to be acceptable, it can be considered to omit files from a backup. In all scenarios it makes sense to define a backup and recovery procedure and test it. I know first hand of backup procedures that were done regularly and in the end proved to be of no value. Thanks, GerardM
2009/3/15 jidanni@jidanni.org
AG> Why don't you just do:
AG> $ mysqldump --ignore-table=my_database.wiki_objectcache AG> --ignore-table=my_database.wiki_searchindex my_database
OK, but then the structure of those tables are gone from the dump too, not just their contents. We cannot thus recover from scratch straight from the SQL dump. But perhaps we then can immediately run a maintenance script to recreate the missing tables' structure?
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l