Re: [Bacula-users] Backing up a VMware Server on 64-bit Linux

[Timo N. <tim...@te...>]

"Kevin Keane" <sub...@kk...> kirjoitti viestissä 
news:493...@kk......
> 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.
>

Thanks for the advice. In my case, this scenario would be for 3-4 computers 
only, without a need for any exact pre-set schedule but maybe just a few 
times in a year or so, mostly before some significant application software 
upgrades etc. Considering the amount of work needed to write, debug and test 
the necessary scripts, I guess I'll concentrate in my more urgent tasks 
first, and plan to run those backups manually at some reasonable time of the 
day, after just making sure the virtual machines are first powered off 
manually.


> 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=/