Hot vs Cold backup!

[James]

Are there any disadvantages  to using the hot backup rather than the cold?

I heard a rumor a while back that vmserver snaphots reduce performance?

Thanks
James

[ronaldlw]

I can't think of any.

As far as any performance issues with snapshots, I do think it can
make a difference if the snapshot gets big, which would happen if it
is left in place for a long time. I just remove the snapshot asap
after the backup, and in fact modified the script some to do this
after the backup finishes copying the files. I have a request to add
this option to the script.

This is a great script!

Ron

[ronaldlw]

> What do I mean by 'crash-consistent'? Let's say you go to restore a
> Windows 2003 VM and you go restore, add into inventory, and power on.
> Windows will ask you why there was an unexpected shutdown. Database
> servers(i.e., SQL, Exchange, Active Directory) are recommended for
> Cold backup in my book if this is your only backup method. Just
> because the issue with potential data corruption.
>
Umm.. I might be wrong here, but I don't think that is the procedure
that you're supposed to use to restore from the "hot" backup method.
The "hot" backup method creates a vm snapshot and then does the
backup. You are supposed to add the vm then choose to "revert to
snapshot" so the vm will actually come up exactly as it was when the
backup snapshot was taken, specifically it will be powered on so I
don't believe you would get any questions about unexpected
shutdowns.

I assume that there is potential for data corruption since there may
be active connections to the database at the time of the backup, but I
wouldn't think that would be as serious as a uncontrolled power off of
the vm.

Am I missing something?

Thanks,
Ron

[10nico]

Crash-consistent backup?

Not if you do this way:

1) you go restore
2) you add the vm to inventory
3) you DO NOT power on
4) you do a "revert to snapshot"
5) VOILA' , you get a powered on machine which never crashed, it will
simply have to sync its time and nothing other, just as if it had been
"hibernated" or "suspended".

Database integrity will be ok since it *didn't* crash.

Of course if you try to power on and don't do a "revert to snapshot"
you'll get a VM which *has* crashed.
Or, to better put it, a VM which had its "plug pulled".

But I never take this route since I know I don't want to restore such
a machine; in fact its own O.S. would probably need to perform a
checkdisk and its databases would need an integrity check; and this is
avoidable, just by doing a "revert to snapshot".

Just my 2 cents! :-)

Michele


On 12 Ago, 20:27, farewelldave <farewelld...@gmail.com> wrote:
> James,
>
> The main disadvantage is that Hot backups will get you a crash-
> consistent backup. (At least, in other methods where you're backing up
> the VM while it's in a snapshot.) The main advantage is that the VM is
> not offline for the duration of the backup.

>
> What do I mean by 'crash-consistent'? Let's say you go to restore a
> Windows 2003 VM and you go restore, add into inventory, and power on.
> Windows will ask you why there was an unexpected shutdown. Database
> servers(i.e., SQL, Exchange, Active Directory) are recommended for
> Cold backup in my book if this is your only backup method. Just
> because the issue with potential data corruption.
>

> I've got some hosts that really need to be available all the time, and
> so here's what I'm doing to allow for Hot backups, and yet still be
> protected. I am doing weekly backups to an external drive, and then
> swapping out the external drive every week with another drive. This
> way I have two weeks/copies and one being stored off-site all the
> time. Then, I'm doing nightly off-site backups (just Active Directory,
> Exchange, SQL, file-level, etc.) with a backup service and in the
> event that I lose the VM, I can restore the most recent from the drive
> (multi GB but back pretty quickly over eSATA) and then restore the
> most recent data from the offsite backup which is much more reliable
> and still save money in not having to use many more GBs on the backup
> service.
>
> I know my examples are of a Windows VM, so any linux guys may have
> some more detailed info for that OS.
>
> -Dave

> > James- Nascondi testo citato
>
> - Mostra testo citato -

[10nico]

Exactly my point Ronald! :-)

Regards,

Michele

[farewelldave]

Point taken, so then what would be a disadvantage to hot backups? Does
this script remove the snapshot after hot backup is complete?

If so, then you don't even have to worry about the snapshot growing
too large, etc.

[James]

Thanks for getting back to me everyone!

Michele from what you have said it sounds like hot backup is the way to go! With a cold backup at the weekends (not sure if that is even needed?).

So to conclude is there more chances of a corrupted db with a hot backup over a cold backup? I guess if the machine is suspended that stops database connections so should eliminate corruption, unless it happens right at the point the machine suspends? In which case it is no better than a hot backup?

Do you remove the snapshot after the backup has taken place? Is it safe to remove the snapshot file after the backup has taken place & the machine is still on? What extension are these files? And are these files big?

Sorry for all the questions!

Thanks again!

James

[10nico]

Wow wow wow , how many questions!

1) I go with hot backups. Anyone is free to try and make his own
experience/learn.

2) HOT vs COLD database backups...well well...
HOT and COLD are "concepts"; let's talk about reality.

A) a "COLD" backup , made by *shutting down* a VM , guarantees db
integrity.
B) a "COLD" backup , made by stopping the db engine before suspending
the VM, guarantees db integrity.
C) a "COLD" backup , made only by suspending the VM has exactly the
same problems that a snapshot-backup; the connections to the db are
active and if they are "caught in the middle of a transaction" some
transaction could be left incomplete.
D) a "HOT" backup , made by simply saving the VM files using VSS (on
windows) or LVM snapshots will result in a VM which will "think" it
has crashed and thus will possibly need checkdisk / db recovery
E) a "HOT" backup , made by doing a VMware snapshot will get you the
very same result that you'd get by suspending the VM without stopping
the db engine (same as point C)

3) No I don't remove the snapshot after the backup, simply because to
remove that I'd need to suspend or shutdown the VM.

In fact you cannot remove snapshot without suspending or powering down
the VM.

Let me repeat it in capital letters:

**** YOU CANNOT REMOVE SNAPSHOT WITHOUT SUSPENDING OR POWERING DOWN
THE VM ****

VMware snapshot files have exactly the same extension of regular VMDK
files; the file name is different, for example.

Regular VMDK file: "myvirtualmachine.vmdk"
Snapshot file: "myvirtualmachine-000001.vmdk"

When you take another snapshot the snapshot file name will become:
2nd time snapshot file: "myvirtualmachine-000002.vmdk"

Please note that with vmware server you cannot have more than one
snapshot at a time, so the second snapshot will *replace* the first.

I hope to have answered all of your questions! :-)

Regards,

Michele

On 13 Ago, 08:49, James <packetsnif...@gmail.com> wrote:
> Thanks for getting back to me everyone!
>
> Michele from what you have said it sounds like hot backup is the way to go!
> With a cold backup at the weekends (not sure if that is even needed?).
>
> So to conclude is there more chances of a corrupted db with a hot backup
> over a cold backup? I guess if the machine is suspended that stops database
> connections so should eliminate corruption, unless it happens right at the
> point the machine suspends? In which case it is no better than a hot backup?
>
> Do you remove the snapshot after the backup has taken place? Is it safe to
> remove the snapshot file after the backup has taken place & the machine is
> still on? What extension are these files? And are these files big?
>
> Sorry for all the questions!
>
> Thanks again!
>
> James
>

[James]

Yes thanks that answers everything, Thank you :D

Oh apart from, do VMWare server snapshots reduce performance of the VM?

Thanks!
James

[James]

Also it would appear that it creates a snapshot file for each .vmdk file? (if you have it split into 2GB files).

James

[10nico]

Yes that's correct and is the expexted behavior.
When you create a snapshot for a "sliced" vmdk, the snapshot will also
be sliced in an equal amount of slices.

Regards,

Michele

On 13 Ago, 10:31, James <packetsnif...@gmail.com> wrote:
> Also it would appear that it creates a snapshot file for each .vmdk file?
> (if you have it split into 2GB files).
>
> James
>

> On Thu, Aug 13, 2009 at 9:24 AM, James <packetsnif...@gmail.com> wrote:
> > Yes thanks that answers everything, Thank you :D
>
> > Oh apart from, do VMWare server snapshots reduce performance of the VM?
>
> > Thanks!
> > James
>

[ronaldlw]

> 3) No I don't remove the snapshot after the backup, simply because to
> remove that I'd need to suspend or shutdown the VM.
>
> In fact you cannot remove snapshot without suspending or powering down
> the VM.
>
> Let me repeat it in capital letters:
>
> **** YOU CANNOT REMOVE SNAPSHOT WITHOUT SUSPENDING OR POWERING DOWN
> THE VM ****
>

I do not see this limitation when using server 2.01. I am able to
easily and consistently remove snapshots while the vm is running, both
via the web interface and using a modified backup_vmware.sh script.
Why can't you remove a snapshot without suspending or powering down?
Is that only in server 1.x perhaps?

Ron

[10nico]

Yes you are right, it's a limitation of VMware Server 1.0.x only;
VMware Server 2.0.x does not have this limitation.

Regards,

Michele