Mailinglist Archive: opensuse (1698 mails)

< Previous Next >
[opensuse] backup break on fs differences? (was: .gvfs backup)
  • From: Joachim Schrod <jschrod@xxxxxxx>
  • Date: Wed, 14 Dec 2011 03:18:23 +0100
  • Message-id: <jc911f$9ss$1@dough.gmane.org>
Adam Tauno Williams wrote:
On Tue, 2011-12-13 at 12:54 +0100, Anders Johansson wrote:
On Tuesday 13 December 2011 12:47:41 Joachim Schrod wrote:
Dave Howorth wrote:
AFAIK, drwx------ is how it is supposed to be. Definitely root doesn't
have access rights (.gvfs is a real pain when making backups for that
reason)
Do you really backup that?
Is that sensible? Does restore work?
We've excluded the .gvfs dirs from backup, since they didn't seem
to have permanent content. But then, GNOME is not much used here,
so I might miss something.
The gnome vfs directory is used for things like ftp or samba access,
temporary
FUSE mountpoints for data access. It's not something you'd back up from the
client side.

First, thanks to all of you who confirmed my suspicion that .gvfs
doesn't need to be / should not / must not be backuped. (Frankly, I
don't care which of these three. ;-)

+1

Most backup software provides a feature to not descend across
mount-points / filesystems. Enabling that feature will probably fix the
problem.

That's an interesting different question. Since it's partly my
thread, I take the liberty to "hijack" it. Let's talk about best
practice.

In our experience, it's less work to maintain a list of mount
points that must not be backed up than to maintain a list where
filesystems are descended.

To be more precise:

1) All user and company data is on file servers. They are
mirrored and backed up.

Backup is both on local servers and
on remote servers. Remote backup is daily for business-
critical data and weekly for personal data.

This backup has the .gvfs excemption, for example.

2) Specific system data is backed up daily, both locally and
remote.

The list of system data to be backed up has been
constructed by 30 yeas of Unix experience and is distribution-
independent. Actually, it includes Solaris, AIX, and HP-UX
locations as well.

3) Generic system configuration and package stuff is not backed
up. This is generated by Puppet on a new system as needed.
(Tests to assure that this process is working are done
bi-yearly. I disregard DR processes for this issue, where tests
are done yearly.)

We run a mixture of openSUSE, Debian, and Ubuntu systems, in
varying versions. (Even some Debian oldstable that we have to
upgrade until February 2012. In fact, we've even got one SLES 9.3
instance where we hope that our customer will evenutally upgrade to
some current version.) We also have RHEL, CentOS, FreeBSD, NetBSD,
and Solaris, in VMware instances, that use the same backup
infrastructure. A few AIX servers are here to be killed in the near
future. Still, their backup (and restore (tested!)!) works. Code
for HP-(S)UX support is there, but luckily ain't not used any more.
(I don't count the dozens of Windows systems in VMware, with their
own backup infrastructure.)

Such a mixed infrastructure is not uncommon, IMH experience. To
disable any backup by mount point would be a disaster, in our
environment. That's because it's a blacklist caused by an unknown
system configuration... To enumerate file systems on all those
distributions and Unix systems, would be nightmare. The only robust
way is a whitelist to tell what shall be backed up in one of the
use cases enumerated above, where one can construct the relative
blacklist by common distribution- and UNIX-independent patterns.

So, do you really use file system boundaries for backup fences?
If yes, how do you manage backup of other Unix systems? other
distributions? other versions? I'd like to share experience reports
about backup strategies that work for small- and mid-sized
companies with a divergent installation base. (I know how to that
for big data centers, that's what I do for a living. Nevertheless,
mid-sized experience would be very valuable to me.)

Joachim

--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Joachim Schrod Email: jschrod@xxxxxxx
Roedermark, Germany

--
To unsubscribe, e-mail: opensuse+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse+owner@xxxxxxxxxxxx

< Previous Next >