On Wed, May 24, 2000 at 06:20:33PM +1000, Robert Elz wrote:
>     Date:        Tue, 23 May 2000 18:01:37 +0200
>     From:        Manuel Bouyer <bouyer@antioche.lip6.fr>
>     Message-ID:  <20000523180137.B357@antioche.lip6.fr>
> 
>   | I disagree. /etc is where up-to-date files are stored, this is what's
>   | important.
> 
> yes, it is, but if you do
> 
> 	dump ... /
> 
> or
> 	cp /etc/{files,that,matter} /var/backups
> 	dump ... /var
> 
> then surely all that matters is saved just the same, except there are
> several advantages.  (Or you can use some other directory in /var,
> I have used /var/save sometimes) if you perfer to leave the standard
> NetBSD usage of /var/backups unaltered.
> 
> First, should one of the important files be lost, it is just left sitting
> there in /var just the same as it is on the tape, which can make it much
> quicker to recover.   Second, more useful stuff gets dumped (most of the
> rest of the dump of / just duplicates the distribution, and isn't really

This assume you're running a stock release :)

> important, essentially nothing in /var is of that nature), and third, if

There's at last one important thing in /: the kernel. I also have
custom stuffs in /, and not all important files in / are in /var/backup
(or you have to copy the whole /etc).

> you need to do a full restore, then you can't really start with a full
> restore of / - you need / to exist in order to do the restores.  It is

Why ? I can restore from tape elsewhere and copy over NFS. I've done this
a lot of time (not only to restore a server, but also to duplicate a server).

> generally easier to re-install in that case (perhaps even upgrade) and
> then restore /var and copy back the files that matter.
> 
>   | /var/mail is only on mail servers,
> 
> Not true.   If you use fetchmail, or even procmail, your mail (or some
> of it) can end up in /var/mail even on your local workstation.

Then you know what you're doing. I use fetchmail/procmail, and all my mail
ends in $HOME.

> 
>   | If you're backuping once a day, /var/spool/mqueue and /var/db/dhcpd.leases
>   | will be out of date anyway and are not that usefull.
> 
> mqueue varies - though recovering it is generally better than trashing it
> if at all possible (some messages can wait in the queue for days before being
> delivered).   For dhcp.leases, unless you have a very high churn rate, it

On internal mail servers it's there at most one day, usually.

> will always be much better to recover it.   In most cases (where there are
> enough addresses available for the clients), even an out of date leases
> file is much better than none at all.  The dhcp server will hand out the
> same address again to a client that requests it, even if the lease had
> expired (or the server thought it had because of an old leases file being
> restored), which is just what you want to happen.

Depends on what you're using dhcpd for. Anyway it's not on all machines.

> 
>   | On a system where /var matters I'd rather go with a raid filesystem than
>   | backups.
> 
> Sure, mirroring (or raid 5 or whatever) /var is a good idea for continuous
> uptime - but that is no substitute at all for dumps.  No raid I have ever
> seen will recover you from a major machine room fire...

Sure, in this case I don't matter much about the dhcpd lease file :)

> 
>   | Conforming to hier is also important I think:
>   | /var/      multi-purpose log, temporary, transient, and spool files
> 
> hier is a description of what is where, it isn't, and shouldn't be,
> treated as a specification of what must be put where.
> 
>   | /var/db/pkg doens't fit in this category.
> 
> Nor is /var/at, yet hier(7) (the 1.4.2 version anyway) says that
> goes in /var ...  It does with /var/msgs as well.  Then there's
> also /var/spool/ftp.

If a server is reinstalled from backups I would't expect at jobs to be
restored. However I agree that crontabs should not be in /var as well
(but this is less annoying for me than /var/db/pkg :)

> 
> I think the one line summary of /var is a poor one, it is an attempt to
> describe what is a general mish-mash really by example, which is a very
> poor way to accomplish anything useful.
> 
> I'd prefer if hier(7) said
> 
> 	/var/	system maintained files that are subject to change
> 		(including spool, log, database, and longer term
> 		temporary files)

I don't find that /var/db/pkg fit in this sheme very well anyway.
It's not the same as the other stuffs in /var/db (Hum, there's libc.tags
here too, should be somewhere in /usr IMHO).

On most systems I don't care about what's in /var where I care about / or
/usr (and this is the case for most workstations or developement machines).
But I have to backup it because there are stuffs here associated with
things of /usr. Such stuffs should be in /usr as well IMHO.
For sure a simple symlink will fix it but I'd prefer if the default was
changed :)

--
Manuel Bouyer, LIP6, Universite Paris VI.           Manuel.Bouyer@lip6.fr
--