Backing up virtual machines while powered on is probably not a great
idea, but there are good alternatives:
- In your ClientRunBeforeJob script, power down the VM, and power it
back up after the backup is done. Alternatively, suspend and resume the VM.
I used to take this approach in my pre-bacula days, so I can't give you
the exact way to make it work with bacula.
I used the vmware-cmd script several times:
vmware-cmd -l
produces a list of all registered virtual machines. Each line can act as
<machinename> in the following scripts.
vmware-cmd <machinename> getstate
returns the current state of the VM. I used this to determine whether I
need to stop, and later to restart, the VM
vmware-cmd <machinename> stop soft
vmware-cmd <machinename> start
will stop and start the virtual machines, respectively. The "soft"
keyword will cause a graceful shutdown; it requires the VMWare Tools to
be installed in the VM.
Taking it all together, my script looked something like this - you will
need to rewrite it quite a bit to split it into the ClientRunBeforeJob
and ClientRunAfterJob scripts.
#!/bin/bash
vmware-cmd -l | while read vmname
do
machinestate=$(vmware-cmd "$vmname" getstate -q)
if [ $machinestate -ne 0 ]
then
vmware-cmd "$vmname" stop soft
fi
# do the backup here
if [ $machinestate -ne 0 ]
then
vmware-cmd "$vmname" start
fi
done
- Use LVM snapshots. I would still suggest suspending the VM for a few
seconds while taking the snapshot.
Timo Neuvonen wrote:
> This isn't excatly a Bacula-related issue, but has anyone experiences how
> consistent bacups can be achieved if I back up a linux host running a VMware
> Server with some of the virtual machines "powered on"? Will the result be
> something total garbage, or something that can reasonably succesfully be
> restored too? Though a virtual machine would be on, there would be no
> significant user activity during the backup run.
>
> Of course, this would lead to making always full backups, since a whole
> virtual machine is basically just a single file (or very few huge files).
> But I wouldn't like to install a client to each of the virtual machines
> separately, especially since they all won't be powered up at all the times.
> This is mostly about occasionally backing up the whole set of system files
> in all the virtual machines, there would be only minimal amount of any user
> data, since it would be actually a workstation with 2-3 different virtual
> machines with different operating systems each, and users should keep the
> actual data elsewhere on a "real" server.
>
>
> Then, this is more like a Bacula thing: are there any "big" issues specific
> to current Bacula clients in 64-bit RHEL5/CentOS5 systems running on
> an Intel CPU (Core 2 etc, but not Xeon)?
> Should I use i386 client in such an environment, or x86_64 which has a
> remark "AMD architecture" on Sourceforge downloads?
>
>
> Regards,
> Timo
>
--
Kevin Keane
Owner
The NetTech
Turn your NetWORRY into a NetWORK!
Office: 866-642-7116
http://www.4nettech.com
This e-mail and attachments, if any, may contain confidential and/or
proprietary information. Please be advised that the unauthorized use or
disclosure of the information is strictly prohibited. The information herein is
intended only for use by the intended recipient(s) named above. If you have
received this transmission in error, please notify the sender immediately and
permanently delete the e-mail and any copies, printouts or attachments thereof.
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users
|
