Bug#612739: store archive/backup files in /etc/lvm/

[Luca Capello]

Hi there!

On Thu, 10 Feb 2011 12:35:21 +0100, Alasdair G Kergon wrote:
> On Thu, Feb 10, 2011 at 12:17:51PM +0100, Luca Capello wrote:
>> The best place for these archive/backup files is /var/backups/lvm2.
>  
> But unfortunately if /var is a separate file system you might need
> to restore from the backups in order to regain access to /var!

Correct.

> /etc is better than /var for that reason

Why?  Being on the *same* LVM you want to recover is even worse...

> and the FHS has no understanding of this category of file:

?  These are backup files, nothing more, nothing less.

> it's outside the scope of what the FHS authors considered when they
> wrote it.

Sure, but if there is a canonical location where all programs put their
backups this is the preferred one and sysadmins knows where to look...

Please note that while I agree that such a location has not been agreed
upon, /var/backups is the de facto standard and it is even mentioned as
reserved in the FHS

  <http://www.pathname.com/fhs/pub/fhs-2.3.html#THEVARHIERARCHY>

  Requirements

  The following directories, or symbolic links to directories, are
  required in /var.

  [...]

  Several directories are `reserved' in the sense that they must not be
  used arbitrarily by some new application, since they would conflict
  with historical and/or local practice. They are:

    /var/backups
    /var/cron
    /var/msgs
    /var/preserve

On my Debian sid, /var/backups contains atp, dpkg and others' backups
(group, gshadow, passwd, shadow).  This is similar to some lenny systems
I (still) have.

> If your /etc is an lvm partition, but /boot is not, then you may
> decide that /boot is a better location for these files.
>
> The best place for these files is a non-lvm device which you can
> still access if the system fails to boot.

Something unfortunately you can not decide a priori (too many possible
combinations) nor at runtime (different systems will have different
locations).

Thx, bye,
Gismo / Luca
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-lvm-maintainers/attachments/20110223/fe161210/attachment.pgp>