-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Fri, 28 Sep 2007 15:24:39 +0200
Krzysztof Halasa <khc(a)pm.waw.pl> wrote:
"Nicolas Mailhot" <nicolas.mailhot(a)laposte.net>
writes:
> Because /var/ mixes long-term and transient data, generic and
> implementation-specific stuff, local and global data, and makes
> backup stategies a PITA for everything but SOHO contexts.
Non-SOHO, you back up everything you have on disk and you don't
think about every file and directory. You have to be able to restore
the system reliably and fast. You may consider excluding things like
/tmp and /var/cache but any re-installations or rebuilding of RPMS
databases etc. are not options.
I'm sorry, but I am having a lot of difficulty resolving your statements here. The
only thing I can think of is that you have "SOHO" v. "Non-SOHO"
backwards, but even then it doesn't make complete sense to me either.
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.
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?).
So, 10,000 times 4GB of stuff that's either the same on all those servers or otherwise
doesn't need to be backed up because Bob can reinstall it by other means. Let's
see that 40TB of data he'd be backing up if he followed your advice. Oh, and it would
take *longer* to restore those systems.
Now, let's get back to a bit of the real world here. In medium to large Enterprise
environments, I've never met anyone who just backs it all up and restores it. The
data has to be separated from the OS and apps. In the real world, I can do a kickstart
install (or other automated install, depending on the system) in under 10 minutes for any
server. Then, I only have to go to the slow-speed stuff for the data the box needs.
Tape, even very fast tape, isn't fast.
> Good backup is expensive backup so bulk-var-backup is not
scaling
> In case of general system failure, or major release update, you're
> better of without a lot of /var contents, because some stuff is
> easier to set up again than take the risk of restoring a rotten
> state
Excuse me? Restoring from a good backup is the only option, if your
last backup is rotten then you take the previous one.
He wasn't advocating that the quality of the backup wasn't important. What I got
from it was that he's merely saying that *state* information may no longer be valid by
the time one needs to restore from backup.
WRT /srv I personally rmdir /opt /*/opt /srv /media after a system
upgrade because I don't usually use them. Should a need arise, mkdir
and friends aren't that hard to type.
That's your choice. Personally, I hate having /media/ used for removable media
instead of /mnt/, but that's where udev rules are going to do things for me. On a
server (without X), removing /media/ is probably just fine (i.e. not going to break things
so much), but on a desktop/notebook/whatever, you'd probably tick someone off if they
are expecting the udev mounting magic to "just work."
I think there are no more real problems in Fedora as people start
fixing "non-problems" instead. /var has been working fine for years
and I don't see any reason to break it now.
I'm sorry, I must have missed the part of this thread where people were wanting to
change things in order to break the system.
If you truly feel that there are no more real problems in Fedora, then why are you even on
this list? After all, this list is for development discussion. The very nature of its
existence implies that we're not done yet.
- --
Lamont Peterson <lamont(a)gurulabs.com>
Senior Instructor
Guru Labs, L.C. [
http://www.GuruLabs.com/ ]
NOTE: All messages from this email address should be digitally signed with my
0xDC0DD409 GPG key. It is available on the
pgp.mit.edu keyserver as
well as other keyservers that sync with MIT's.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
iD8DBQFG/X4k+YBsl9wN1AkRAho5AKDDYSMCZy0vOh2YnWehAU4ew87n5wCfZ1E1
OZETvrIHZ25hj+4bwo9l2sc=
=QFBT
-----END PGP SIGNATURE-----