Manuel Bouyer wrote:

> This is also my opinion, but for another reason: on my servers,
> /var is a separate file system, and can be quite large. To have a backup of the
> system I need /var as well, for /var/db/pkg (I don't care much about the
> logs, interesting ones are replicated on loghosts anyway).

> I think /var should
> only contain log files or files that can be regenerated from the system.

/var is meant to be state local to this host.  Dynamic files that change
more often than the rest of /, amongst other characteristics.

My understanding is that /var/db is meant to be primarily databases that
are preserved across reboots (as distinct from /var/run).  E.g. dhcpd
state files.
Am I mistaken?


Where else would you store this data?  Under /usr?  Keep in mind that
this is often (ok, ok, so that's a relative term) NFS-shared between a
cluster of machines.  If the data reflects the the contents of /usr,
then somewhere under /usr sounds very appropriate.  Otherwise /var
(whether it's part of / or not) has historically been a sensible
location.

In any case, relying on /var to _only_ have throwaway data is a flawed
policy that will bite you (or someone else) sooner or later.  I guess it
boils down to a question of how much pain you're willing to go through
if/when you have to go to backups.  If you're going to exclude data from
your backups, be sure you don't do it with too broad a cut (sure,
filesystem-level dumps may make your choice harder, but symlinks are
useful).


I would favour keeping the state under /usr/pkg, but definitely not for
your reason.
__
David Burren