SMVI Experiances

[Raj Patel-2]

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.

[Das, Amrita]

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@...]
Sent: Friday, November 13, 2009 2:40 AM
To: toasters@...
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.

[Darren Sykes]

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@... [mailto:owner-toasters@...]
On Behalf Of Raj Patel
Sent: 12 November 2009 21:10
To: toasters@...
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

[Page, Jeremy]

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@... [mailto:owner-toasters@...]
On Behalf Of Darren Sykes
Sent: Friday, November 13, 2009 5:23 AM
To: Raj Patel; toasters@...
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@... [mailto:owner-toasters@...]
On Behalf Of Raj Patel
Sent: 12 November 2009 21:10
To: toasters@...
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 [phone]) 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.