Hi
>I have some experience with backing up virtual machines snapshot,
me too :)
>and I find
>them completely useless.
I don't :)
>Why? Let me show an example.
>
>You make a snapshot of working environment - whatever it is - it has
>some
>clients connected, some sessions active, and some files opened, then
>make a
>backup. After a few days you have to recover this environment, because
>main
>machine is down and unable to recover in any different way.
>
>You put your snapshot up and look what is happening:
>Active sessions ask: hey where are my clients?
>Opened files ask: hmmm, am I opened or I should be closed? Where is
>person
>who opened me?
Of course, your example points out a crucial problem with virtual
machines. Doing backups from outside a VM is tricky. However, there are
such things as pre run scripts that could trigger backup procedures
within the VM, put the database into a consistent (sleep) state and
therefore ensure valid backups.
>It make whole environment completely inconsistent, so I prefer shut
>down the
>virtual machine, make a snapshot and backup - power it up. Or use a
>backup
>directly from operating system. I think backing up such a large files,
>which
>changes not often without incremental way is wasting of storage, time
>and in
>some cases may be useless.
Here's what we do (just to give you an idea, we have a total of approx.
90 ESX-Servers at the moment and run close to 800 VMs and the
environment is continouisly growing):
We're using VCB (VMware Consolidated Backup, quite useful actually). The
tool will take care of your VMs, snapshot them, export the vmdk-files in
2GB sized snippets (no worries about large files) and all that can be
done via SAN, network or whichever you prefer. If you care, I can supply
you with simple scripts that will take care of most of the hazzle.
There's also a huge advantage of using VCB over doing manual
snapshotting and having Bacula: the extracted files will be slightly
larger only than the actual used space within the VM. Say you have a
100GB sparse file, the VM's data covers about 40GB, then the export will
be approx. 41GB large.
You're right of course, that there is no such thing as an incremental
backup. However, as long as you're not concerned with the VM's internas,
a backup from "outside" is the best thing I can think of. We've been
running a setup like that for several months now and never had serious
problems. Backing up a running Windows, Linux or Solaris VM, restoring
it somewhere else and booting it up worked properly in every occassion.
If you're running such things as a proxy server, gateways and similar
stuff, I'd say that's the way to go. For DB-servers etc. there should be
a set time to do backups. You could, within that time-windows, shutdown
the box which would ensure that there are no open sessions, files,
connections and the DBs and others would be in a consistent state, fire
away the backup (which will at the very first stage create a snapshot of
the VM's disks) and then startup the VM again right away. Downtime can
be reduced to mere minutes.
This all will work in static VM-Server environments just as well as in
highly dynamic Virtual Infrastructure [tm] environments with DRS enabled
etc. I those cases you'd just have to think it over a bit more and
create custom shutdown and startup scripts to shutdown and power off
running virtual machines automatically without knowing where they
actually reside within the cluster. Feel free to ask...
Anyways, time for lunch, gotta run...
>
>Best regards,
>Marcin
Ronald
-------------------------------------------------------------------------
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
|
