If it's VMWare server, that wouldn't necessarily work - a snapshot opens
a new file which stores a binary delta of all changes since the snapshot
was taken and this file is being constantly written to. Backing it up
without taking account of this causes all sorts of fun.
I'm doing something similar to Kevin's suggestion - I have a script
which lists every live VM in a specific directory, pauses it, takes an
LVM snapshot of the underlying LV, restarts the VMs, mounts the snapshot
LV. Bacula then takes a backup of the mounted snapshot then removes it
post-backup. VMs which were already paused or shut down aren't
brought back up - we assume they were down for a reason.
I'm not sure I can make it available as it was written on my employers'
time for my employers' systems but it wouldn't be too hard to
re-implement for someone reasonably competent in bash.
Kevin Keane wrote:
> If you are thinking of doing it just before application upgrades or the
> like, how about using VMWare's own snapshot functionality? They
> implemented it for that exact purpose.
>
> Timo Neuvonen wrote:
>> "Kevin Keane" <subscription AT kkeane DOT com> kirjoitti viestissä
>> news:4932A7F8.5040604 AT kkeane DOT com...
>>
>>> 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=/
>>>
>>
>>
>> -------------------------------------------------------------------------
>> 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
>>
>
>
--
James Cort
IT Manager
U4EA Technologies Ltd.
--
U4EA Technologies
http://www.u4eatech.com
-------------------------------------------------------------------------
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
|
