Thank you for your thoughts. Your comments about the local snaps make sense. To clarify, my risk of the WAN link failing for any extended amount of time is extremely low. Both of these devices are hosted in high end data centers that both have N+1 redundant power, cooling etc. The replication traffic is going over a multi-gigabit data center to data center link (we only have access to a portion of this bandwidth).
Since we have no staff in either data center, tape is not a viable option. I could write deduped backups to a separate storage device in the same data center as the PS6500E primary device. However, in the event that I lost the array (due to some massive site issue) this device would probably be destroyed as well.
In addition, I did plan for a huge amount of space for local snap storage, and my entire PS4100E is for nothing but offsite backup storage (either smart replicas, or smart replicas plus off site 3rd party backup storage).
Thanks again for your thoughts on this. I look forward to hearing what others think as well.
I think they can and should be considered an important component of your overall "protection" strategy. Yeah, the snaps and replicas won't do much for you in regards to long term protection, but when you factor in protection of your data, AND protection of the systems that serve up the data, as well as the various layers that you have to consider when protecting the data, it is my belief that there is no greater addition to the IT arsenal than snapshots and replicas. They work when other means fall short. Are they the only thing that you should rely on? No, of course not, but they are incredibly useful. ...To the degree that I can't imagine living without it.
I think everyones needs are differnt depending on you level of acceptable downtime, recovery objectives, and resources available to you. So if snaps and replication fit your BCP recovery objectives and you have tested the recovery methods, I think your fine.
dwinslow
20 Posts
0
February 12th, 2012 19:00
Hi Don,
Thank you for your thoughts. Your comments about the local snaps make sense. To clarify, my risk of the WAN link failing for any extended amount of time is extremely low. Both of these devices are hosted in high end data centers that both have N+1 redundant power, cooling etc. The replication traffic is going over a multi-gigabit data center to data center link (we only have access to a portion of this bandwidth).
Since we have no staff in either data center, tape is not a viable option. I could write deduped backups to a separate storage device in the same data center as the PS6500E primary device. However, in the event that I lost the array (due to some massive site issue) this device would probably be destroyed as well.
In addition, I did plan for a huge amount of space for local snap storage, and my entire PS4100E is for nothing but offsite backup storage (either smart replicas, or smart replicas plus off site 3rd party backup storage).
Thanks again for your thoughts on this. I look forward to hearing what others think as well.
David
sketchy00
203 Posts
0
February 13th, 2012 13:00
I think they can and should be considered an important component of your overall "protection" strategy. Yeah, the snaps and replicas won't do much for you in regards to long term protection, but when you factor in protection of your data, AND protection of the systems that serve up the data, as well as the various layers that you have to consider when protecting the data, it is my belief that there is no greater addition to the IT arsenal than snapshots and replicas. They work when other means fall short. Are they the only thing that you should rely on? No, of course not, but they are incredibly useful. ...To the degree that I can't imagine living without it.
rcharest
1 Message
0
April 4th, 2012 07:00
I think everyones needs are differnt depending on you level of acceptable downtime, recovery objectives, and resources available to you. So if snaps and replication fit your BCP recovery objectives and you have tested the recovery methods, I think your fine.