Hi,
first of all, I'm disappointed that Sourceforge's Spamassassin failed to sum
up our opinion regarding the original post with the concise description
"UNWANTED_LANGUAGE_BODY".
Secondly, sending an automatic translation of your reply is a great idea :-).
Michael Stowe wrote on 2011-07-08 09:28:37 -0500 [Re: [BackupPC-users] Backuppc
legt Server lahm]:
> Detlef Sch?el *should have* written:
> > Hello,
> >
> > I've got a root server [...] with 100GB backup space via FTP.
> >
> > The root server runs a VM with VMware server. The FTP backup space is
> > mounted on the (physical) root server via CIFS.
> >
> > The VM is backed up with BackupPC, however, some process appears to
> > use up so much of the resources of the virtual server, that it turns out
> > to be next to unusable. Even ssh runs into a timeout at this point.
> >
> > Is this type of setup a structural problem in itself, or can the issue
> > be solved by configuration? I wasn't able to find any mention of such
> > a problem with Google. Shouldn't it be possible to lower the priority
> > of a backup in such a way that the server stays more or less unaffected?
>
> If I understand you correctly, the backup works, but is overwhelming the
> VM, via ftp, thus making the VM unusable.
>
> Are connecting TO the VM via FTP?
No, as far as I understand it (and there are a lot of details missing!),
TopDir is effectively mounted via CIFS, which should in itself be a problem,
because hardlinks shouldn't work, should they?
I can't find any mention of the XferMethod used - there's a mention of 'ssh',
but it's not even clear whether that is part of the backup transfer or of an
attempt to investigate what is going on in the VM.
So, the questions I'd like to ask at this point are:
1.) How is your BackupPC pool accessed? Is it true that this is a CIFS mount?
If so, what has that got to do with FTP?
Are you able to access it in a way that will allow hardlinks to work
correctly? If not, you can stop here. BackupPC won't work without hardlink
support.
Is your access to the backup space fast? BackupPC is designed for fast
local pool access and potentially slow client access, not the other way
around.
2.) Is your client (the VM) running Linux (or some other Unix) or Windoze?
3.) What XferMethod are you using to access the client?
4.) Are you using a virtual disk for the VM, or does the VM have access to
a physical disk/partition?
5.) How much data do you want to backup?
6.) Are backups currently working, even though they slow down the virtual
server unacceptably, or do they abort with a timeout? If they work, how
long do they take?
7.) Have you tried simulating a backup without BackupPC, i.e. rsync the
files from the VM to your backup space (presuming you're using rsync)?
Does that work?
8.) Does your VM have enough memory assigned to it? How much memory does your
root server have? The problem here is, that both the client and the
server need enough memory and you're basically splitting up the physical
memory of your root server between both.
9.) Ah, yes. The version of BackupPC you are using might be relevant. Any
other specs of your root server you can provide might also help.
In any case, backing up a VM running on the BackupPC server itself doesn't
sound too promising. If you *have* to do it that way, you should think about
how you can minimize resource requirements. Turning compression off if you
don't need it should help. If you're using ssh, use a faster cipher (is it
possible to turn off encryption altogether?), or consider completely avoiding
ssh (-> rsyncd). tar probably needs fewer resources than rsync (and you don't
need the bandwidth savings), but you'd be sacrificing backup exactness
(probably nothing to worry about if you can run full backups regularly).
If you need to use compression, things might speed up considerably after the
first backup has completed, presuming you have a lot of data that doesn't
change regularly. This is because files already existing in the pool don't
need to be re-compressed. If you're really desperate, rsync the data from your
VM to the physical server and back it up with BackupPC from there (use a
different host in BackupPC; the point is just that it is compressed into the
pool). Then you can see if subsequent backups work out or not.
Hope that helps.
Regards,
Holger
------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
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/
|
