Holger Parplies wrote:

>>> We've started to setup a large multiple server backuppc environment [...]
>>> We've got a large 2TB nas at the back of it with gig connectivity.
>>> Filesystem is LVM on top of OCFS2 so we have multiple front-end servers
>>> with read/write. [...] The actual top/backup location is shared on the
>>> main nas store.
>>> [...]
>>>
>>> Can anyone see any pitfalls with this?
>> You will run into lots of troubles [...]
> 
> actually, I'm not sure you will. I'd expect subtle corruption which you won't
> notice until it's too late. Things like single files in backups containing the
> wrong contents. There might be more obvious things like garbled status.pl
> contents, which might make BackupPC crash or display (and use) incorrect
> values. I wouldn't be surprised if each BackupPC instance would remove
> information for hosts it doesn't know about (from status.pl, not the host
> directories). Random things may or may not happen.

I thought someone had reported doing this successfully over NFS - using 
a high capacity commercial NAS.

> You might even be lucky and simply get away with it. Race conditions are
> things waiting to happen, although they may turn out not to. I don't know and
> it doesn't seem important to me either. Are you doing backups for the odd
> chance of them being correct?
> 
>> BackupPC is not designed to support multiple instances accessing the same
>> storage.
> 
> 
>> There are
>> processes like BackupPC_nightly which need to have exclusive access to
>> the pool (e.g. no parallel BackupPC_link running).
> 
> While you might even be able to rule that out by some clever scheduling (and
> some luck), there's no sane way to prevent more than one instance of
> BackupPC_link from running.

That shouldn't matter - and in fact probably happens with multiple 
processes on a single server. link() should be an atomic operation so 
creation of a hash collision should be detected even if it is simultaneous.

>>> The only strange thing I've
>>> noticed is with the trashClean process, it seems to be trying to clean
>>> things that the other server is creating/working on and failing with
>>> "Can't read /var/lib/backuppc/trash/xxxx/home/blah/thing/file: No such
>>> file or directory". It doesn't seem a major thing so I'm ignoring it
>>> for now!
> 
> This is one example of a race condition. Two trashClean processes are
> simultaneously trying to delete the same tree. Each file can only be deleted
> once, so each trashClean will fail for an arbitrary number of files (and log
> it, as it is unexpected). Obviously, running multiple trashClean processes on
> the same file system is a waste of resources, i.e. slows things down
> considerably compared to only one instance running. Multiple BackupPC_nightly
> instances would be even more wasteful by far.

The BackupPC_nightly run is the more dangerous part.  There you have the 
possibility that it might delete a pool link at the same time another 
process just re-used it.  In older versions, this could not run 
concurrently with backups for this reason.  In the current version there 
is some sort of locking around the operations that might collide so this 
might or might not also work on a network filesystem.  But in any case 
you would probably only want one nightly run and keep it outside the 
backup window.

-- 
   Les Mikesell
    lesmikesell AT gmail DOT com


------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time, 
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize  
details at: http://p.sf.net/sfu/Challenge
_______________________________________________
BackupPC-users mailing list
BackupPC-users AT lists.sourceforge DOT net
List:    https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki:    http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/