Hi all,
Now our controller upgrade woes have been sorted I can start to play with the new stuff on our 2050.
One of those is SMVI.
Unfortunately as we're not on vSphere (and our ESX hosts aren't up to 3.5 update 4) we'll be sticking with v 1.2 of SMVI until we upgrade our ESX infrastructure to v4.
Anyone out there willing to share their experiances with SMVI ? It looks fairly simple to configure and get going but just as I was about to schedule a few backup jobs I thought I'd trawl the net to find out if there are any 'gotchas'.
For example we use iSCSI - will the VM grind to a halt (ie queisce) while the Volume is snapped (ie is there a performance hit) or is this a momentary operation (ie safe to do during the day) ?
I have seen the note about snapping a VM with iSCSI attached LUN's - I can live with that (not sure about the DBA's . . .).
For Prod we tend to put a 300Gb VMFS lun in a 500Gb flexvol - rate of change is generally pretty minimal for the app servers (generally w2k3 or w2k8 servers from templates). Is this a workable ratio or do I need to allocate more space (I'm looking at just a once a day snap with a 1 or 2 day retention) ?
Thanks in advance, Raj.
Hi
Please take a look at TR 3737 . This is the best practices guide for SMVI 1.0. But this should get you started on some of the best practices for retention, scheduling etc.
http://www.netapp.com/us/library/technical-reports/tr-3737.html
We are currently working on 2.0 best practices and I'll let you when that's done.
Regards Amrita
-----Original Message----- From: Raj Patel [mailto:phigmov@gmail.com] Sent: Friday, November 13, 2009 2:40 AM To: toasters@mathworks.com Subject: SMVI Experiances
Hi all,
Now our controller upgrade woes have been sorted I can start to play with the new stuff on our 2050.
One of those is SMVI.
Unfortunately as we're not on vSphere (and our ESX hosts aren't up to 3.5 update 4) we'll be sticking with v 1.2 of SMVI until we upgrade our ESX infrastructure to v4.
Anyone out there willing to share their experiances with SMVI ? It looks fairly simple to configure and get going but just as I was about to schedule a few backup jobs I thought I'd trawl the net to find out if there are any 'gotchas'.
For example we use iSCSI - will the VM grind to a halt (ie queisce) while the Volume is snapped (ie is there a performance hit) or is this a momentary operation (ie safe to do during the day) ?
I have seen the note about snapping a VM with iSCSI attached LUN's - I can live with that (not sure about the DBA's . . .).
For Prod we tend to put a 300Gb VMFS lun in a 500Gb flexvol - rate of change is generally pretty minimal for the app servers (generally w2k3 or w2k8 servers from templates). Is this a workable ratio or do I need to allocate more space (I'm looking at just a once a day snap with a 1 or 2 day retention) ?
Thanks in advance, Raj.
We use it, and due it generally works OK.
However, getting quieced VMs isn't as straight forward as you'd hope (especially for highly used VMs).
Nothing should grind to a halt; we snap every 4 hours and it goes unnoticed. One thing to note is that if you use iSCSI from your guests then you cannot use SMVI to generate a quieced backup.
Darren
-----Original Message----- From: owner-toasters@mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Raj Patel Sent: 12 November 2009 21:10 To: toasters@mathworks.com Subject: SMVI Experiances
Hi all,
Now our controller upgrade woes have been sorted I can start to play with the new stuff on our 2050.
One of those is SMVI.
Unfortunately as we're not on vSphere (and our ESX hosts aren't up to 3.5 update 4) we'll be sticking with v 1.2 of SMVI until we upgrade our ESX infrastructure to v4.
Anyone out there willing to share their experiances with SMVI ? It looks fairly simple to configure and get going but just as I was about to schedule a few backup jobs I thought I'd trawl the net to find out if there are any 'gotchas'.
For example we use iSCSI - will the VM grind to a halt (ie queisce) while the Volume is snapped (ie is there a performance hit) or is this a momentary operation (ie safe to do during the day) ?
I have seen the note about snapping a VM with iSCSI attached LUN's - I can live with that (not sure about the DBA's . . .).
For Prod we tend to put a 300Gb VMFS lun in a 500Gb flexvol - rate of change is generally pretty minimal for the app servers (generally w2k3 or w2k8 servers from templates). Is this a workable ratio or do I need to allocate more space (I'm looking at just a once a day snap with a 1 or 2 day retention) ?
Thanks in advance, Raj.
To report this email as spam click https://www.mailcontrol.com/sr/wQw0zmjPoHdJTZGyOCrrhg== FZBV57R5d!BtF5J49kuNm83idHzK4RT!!!4pahZRjvH8A== .
Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
I can understand wanting to make your backup up method as reliable as possible but for most organizations I suspect that crash consistent backups meet their requirements. I haven't had one fail yet - although we do dump databases to flat files just in case.
-----Original Message----- From: owner-toasters@mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Darren Sykes Sent: Friday, November 13, 2009 5:23 AM To: Raj Patel; toasters@mathworks.com Subject: RE: SMVI Experiances
We use it, and due it generally works OK.
However, getting quieced VMs isn't as straight forward as you'd hope (especially for highly used VMs).
Nothing should grind to a halt; we snap every 4 hours and it goes unnoticed. One thing to note is that if you use iSCSI from your guests then you cannot use SMVI to generate a quieced backup.
Darren
-----Original Message----- From: owner-toasters@mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Raj Patel Sent: 12 November 2009 21:10 To: toasters@mathworks.com Subject: SMVI Experiances
Hi all,
Now our controller upgrade woes have been sorted I can start to play with the new stuff on our 2050.
One of those is SMVI.
Unfortunately as we're not on vSphere (and our ESX hosts aren't up to 3.5 update 4) we'll be sticking with v 1.2 of SMVI until we upgrade our ESX infrastructure to v4.
Anyone out there willing to share their experiances with SMVI ? It looks fairly simple to configure and get going but just as I was about to schedule a few backup jobs I thought I'd trawl the net to find out if there are any 'gotchas'.
For example we use iSCSI - will the VM grind to a halt (ie queisce) while the Volume is snapped (ie is there a performance hit) or is this a momentary operation (ie safe to do during the day) ?
I have seen the note about snapping a VM with iSCSI attached LUN's - I can live with that (not sure about the DBA's . . .).
For Prod we tend to put a 300Gb VMFS lun in a 500Gb flexvol - rate of change is generally pretty minimal for the app servers (generally w2k3 or w2k8 servers from templates). Is this a workable ratio or do I need to allocate more space (I'm looking at just a once a day snap with a 1 or 2 day retention) ?
Thanks in advance, Raj.
To report this email as spam click https://www.mailcontrol.com/sr/wQw0zmjPoHdJTZGyOCrrhg== FZBV57R5d!BtF5J49kuNm83idHzK4RT!!!4pahZRjvH8A== .
Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
Please be advised that this email may contain confidential information. If you are not the intended recipient, please do not read, copy or re-transmit this email. If you have received this email in error, please notify us by email by replying to the sender and by telephone (call us collect at +1 202-828-0850) and delete this message and any attachments. Thank you in advance for your cooperation and assistance.
In addition, Danaher and its subsidiaries disclaim that the content of this email constitutes an offer to enter into, or the acceptance of, any contract or agreement or any amendment thereto; provided that the foregoing disclaimer does not invalidate the binding effect of any digital or other electronic reproduction of a manual signature that is included in any attachment to this email.