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
