Le samedi 29 septembre 2007 à 02:22 +0200, Krzysztof Halasa a écrit : > Lamont Peterson <lamont@xxxxxxxxxxxx> writes: > > > Let's just go to an example. > > > > Bob runs IT for a large organization. The systems that Bob deals with > > are firmly in the category of "Enterprise-Grade." > > > > Bob has 10,000 server to backup. > > So anything non-SOHO means 10,000 servers and perhaps hundreds > of thousands people. Ok, let it be. Anything non-SOHO is somewhere where you do automated regular backups via hardware you don't find in consumer PCs and is expensive enough you can't just backup everything. It starts at the cheap DLT auto-changer+amanda level > > Each of Bob's servers has an average of, say, 30GB of stuff (everything > > on the disk added up together). > > > > Of that average of 30GB/server, only 4GB is not data the server manipulate. > > Or in other words, 4GB is OS, libraries, application code, etc. (of > > course, this number would be significantly higher for Bob's Windows > > server, but let's keep this scenario simple for now, shall we?). > > IOW, 13.3% of your data is the OS. > How about a bit larger systems? Like the one I have here with > ca. 440 GB of data? 1% = the OS. It's still a small machine. Very often your critical data has not inflated like consumer OSes, so the trend goes the other way (increasing OS data weight). And you still have backup space constrains because many systems are connected to the same backup hardware. > [Several questions that show you've got absolutely no understanding of real-life enterprise contexts, and that I'll answer in one go] In real-life systems are not identical. They're supposed to be but perfection costs money, so they aren't. In case of system failure reinstalling from scratch is a way to heal a system which has bitrotten (or a system update that was planified in the next months is just done with the reinstall) An enterprise will have streamlined installation of its main OSes, using kickstart, mirroring or just plain paper procedure so "re-installation keeps crashing" is not a possibility. And anyway the problem is not you can save half an hour by restoring an OS backup but sysadmin availability - you don't pay a sysadmin per system, and you don't pay 24/24 7/7 care for every system. You're assuming every system connected to an enterprise backup system is critical and needs to be restored at once. It's not. Entreprises have big shared backup systems because big shared systems are more reliable and on the whole cheaper than lots of separate systems, and to achieve volume everything from critical to no-so-critical is plugged in the same system. Projects are then billed on data backup volume and frequency. A "critical" system will have a spare waiting to go live, will pay for full-system backup, and is on the night sysadmin list for immediate restoration. A "not-critical" system will only backup data, will be put back-on-line when sysadmins have the time, will be lagging on updates, etc. It will run on old obsolete hardware that can't be replaced identically when it fails. It's a lot more work to restore than the critical system, but recurrent costs are lower, and on the whole it's cheaper than the other one. If the hosting site is destroyed by fire or Al-Qaida plane it can wait months before restoration, while the other will have its hot spare on another hosting site go live in minutes This kind of setup where costs closely mirror system criticity requires careful planning and sorting of on-disk data (and current /var is such a mess it's not an option) -- Nicolas Mailhot
Attachment:
signature.asc
Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
