Your identity has quite a lot of value, especially in the wrong hands. Security firm ZoneAlarm put together some numbers in 2011 concerning identity fraud, and it even shocked us. Let's talk about a few of these statistics and what it means.
When you mention the term 'disaster recovery,' most people think about the big ground-shattering events like earthquakes, fires, floods, tropical storms, etc. While these natural events are certainly disasters and devastating in their own right, smaller things can constitute as a disaster for your business, and they aren't seasonal.
Saving a little on your technology can go a long ways, but cutting too many corners can lead to additional problems and expensive downtime. Here are a few ways you can cut costs without creating long term issues.
On the surface VMware’s Site Recovery Manager (SRM) is heaven sent bringing the promise of taking your servers running in production and getting them back up in a DR site in a mostly automated way. SRM does deliver on this promise but as we see all to often, it’s not as easy as it looks and some thoughtful planning is a must. This blog is about some key considerations you should make if, like most people, you have different subnets in use at your DR site and you are using SRM to change the IP address of your severs during failover.DR sites are commonly using kit that has other primary uses, or is older, re-used ex-production kit. Typically, your DR site is going to offer lower performance. This is key for storage. While most companies are willing to take a performance and productivity hit in DR, recovery time objectives (RTO) are typically something that they aren’t willing to miss – when every hour of downtime costs money, getting those systems back online is critical. When you have low performance available from the storage, managing the load an SRM failover generates is key to having a successful recovery.
