[RFC] /var versus /srv

[Lamont Peterson]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, 28 Sep 2007 15:24:39 +0200
Krzysztof Halasa <khc at pm.waw.pl> wrote:

> "Nicolas Mailhot" <nicolas.mailhot at 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 at 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-----