Simultaneous Freezing of Several VMs

[J1mbo]

Good morning

I'm just wondering if a job can be defined such that a number of VMs are frozen (broadly) concurrently?

I.e. the snapshots taken of VMs A, B and C together, then backed-up or replicated sequentially as usual.

Many thanks!

[Gostev]

Good morning, this is technically impossible to implement with VMware snapshot unfortunately (at least, without downtime). Each VM requires different time for guest to freeze, and for VMware snapshot to be created. Today, the above is only achievable with crash-consistent SAN level snapshot when all VMs are located on the same LUN. Thanks.

[J1mbo]

Interesting, thanks. I've just done some testing and the closest I can make them is two seconds apart... does that buy anything I wonder - maybe not.

[tsightler]

Today, the above is only achievable with crash-consistent SAN level snapshot when all VMs are located on the same LUN.

Most SAN's actually support this across multiple LUN's so no requirement for all VM's to be on the same LUN.

[cby]

This seems an appropriate thread to throw in my feature request...

We have a number of Oracle databases that the DBAs insist on shutting down for a 3 hour period during which we need to perform the snapshot element of the Veeam backup. Despite suggestions to implement hot backups we are still operating in database shutdown mode.

This was fine and dandy when the snapshots took place in the 3 hour window. However, inevitably, as the the number of VMs increase our window is squeezed and we cannot guarantee that snapshots are taken when the databases are shut down.

One way to address this problem would be to specify when the snapshots are to take place -- i.e. schedule the snapshots to be taken during the 3 hour window ahead of the actual backup process. I know that this will have a knock-on effect on the snapshot removal times, but is there a technical reason (in ESX/Vmware or Veeam) why this could not be implemented? I can see how orphaned snapshots might be an issue and that the relationship between snapshot and real backup times would need to be controlled.

This feature would allow us to lump all the DB server VMs into a single job thus taking full advantage of Veeam's de-dup capabilities. As things stand we have to split the backups into multiple jobs up to ensure we get the DB server VM snapshots complete within the 3 hour window.

We currently run a single Veeam backup server which is not ideal given the number of VMs now being backed up. So there are a number of possible workarounds with the existing Veeam setup:

1. Multiple Veeam backup servers to run concurrent backups -- still doesn't address the issue of avoiding multiple DB VM jobs

2. Implement Oracle hot backup mode -- gives us plenty of time to undertake snapshots

3. SQL script to halt database updates prior to snapshotting (is this possible?!)

Can anyone suggest other workarounds while we wait for the snapshot schedule feature?

Thanks.

[Vitaliy S.]

Hello,

If your DBAs are hesitant on doing hot backups, then I would recommend going with pre-freeze and post-thaw scripts that would be invoked prior and post snapshot procedure. In V6 you would be able to specify VMs order to process, and that would allow you to assign a higher priority to your Oracle VMs.

Here is an existing topic that you might find helpful: Backup SAP Oracle vServer

Thanks.

[cby]

Vitaly, thanks for the pointers. Pre freeze and and post thaw has been suggested in the past I recall. Time to look at it.

[cby]

Has anyone successfully implemented pre-freeze-script and post-thaw-script on RHEL5 VM?

I've stuck these in /usr/sbin and given them execute permissions but the scripts are not invoked when taking a VM snapshot in Virtual Center. There is no entry, error or otherwise, referring to the scripts in the vmware.log file for that VM

Currently running vSphere 4 and Vmware tools installed on VM.

Thanks.

[Vitaliy S.]

Have you enabled VMware Tools quiescence? By the way I've seen that some customers place these scripts to this folder /etc/vmware-tools, even though they are on vSphere 4.

[Gostev]

Have you seen our recorded webinar on virtualized Oracle backup and recovery? This has some good information on different methods of hot Oracle backup. Particularly, some customers quoted in this webinar have been doing hot Oracle backups without quiescing the database successfully for many years, without a single recovery issue (every single backup was autotested to prove to DBA that there are no issues).

[cby]

Anton/Vitaly

Thanks for the suggestions.

1. I had already placed the scripts in /etc/vmware-tools but still not running.

2. Isn't vmware-tools quiescence purely a Veeam property and not a general Vmware facility? I tested the scripts by taking a snapshot using snapshot manager in VC. My understanding that was that any snapshot process would automatically fire off the pre and post scripts. If this worked I would have then gone on to test in Veeam. Should I test directly in Veeam with quiescence set on?

3. I'll check the webinar, but bear in mind there is no hot backup run by DBAs.

[Vitaliy S.]

Isn't vmware-tools quiescence purely a Veeam property and not a general Vmware facility?

Pre-freeze and post-thaw scripts is VMware functionality, they are triggered by VMware when snapshot is created. Make sure you can trigger them with vSphere Client (create snapshot manually with quiescence enabled) before attempting to use them with Veeam backups.

[cby]

Vitaly

Thanks. Yes, I understand the principle -- I had neglected to manually quiesce in VC when testing...mea culpa.

All working fine now. Scripts live in /usr/sbin, no need to stick them in /etc/vmware-tools. Incidentally make sure your scripts generate a non-zero exit code and no, you don't have to set them with permissions 777!

[steelnwool]

Have you seen our recorded webinar on virtualized Oracle backup and recovery? This has some good information on different methods of hot Oracle backup. Particularly, some customers quoted in this webinar have been doing hot Oracle backups without quiescing the database successfully for many years, without a single recovery issue (every single backup was autotested to prove to DBA that there are no issues).

Do you have a link to this webinar? Thanks.

[Gostev]

Yes. It's 4 years old now, but still good > https://www.youtube.com/watch?v=j49MfsnkVWQ
Of course, v9 will render this useless with native Oracle backup and recovery support.

[steelnwool]

Cool. I wonder what the upgrade from 8 to 9 will cost.

[foggy]

Nothing, if you're on active maintenance.

[steelnwool]

Win. ETA ?

[foggy]

Q4