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 <jida...@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 > _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l