By your even looking at this blog post, it’s a safe assumption that you’re planning on going (or are already going) through a migration or are preparing for a disaster. With Active Directory being the crux of so many critical systems, you need your plan to be as close to reality as possible to ensure a successful migration or recovery. So how can you best prepare for any unforeseen contingencies in a way that doesn’t take up all your time and focus? In this webcast sponsored

It’s likely today that you’ll need to recover a single user account, an email, a database, or a file – far more than you’ll need to recover all of Active Directory, Exchange, SQL Server, or SharePoint – and yet, your backup and recovery strategy focuses on recovering the enterprise, and not daily recovery needs of that enterprise. In this recorded webcast, sponsored by Veeam, I discuss what’s possible from a technology standpoint – both with the product you wish to recover fr

I recently finished an 8-step series on business recovery, where I covered a number of methodologies that would not only enhance your recovery offering, but provide better data protection for your customers. Assuming a few of those are appealing and can be applied to your customer base, the next logical step is to market these services. Having 10 years of experience as a Marketing VP in the tech space, as well as being a former owner of two service organizations, marketing th

We’ve reached the final article in this 8-step program. Throughout the last 7 articles, I’ve laid the foundation for expanding your backup services to a true recovery offering by establishing the Recovery Time Objectives and Recovery Point Objectives for each critical data set, application, service, or server, and introducing various kinds of recovery services you can provide: Virtual Disaster Recovery Continuous Recovery File Versioning File Level Recovery Virtual to Virtual

We’re nearly at the end of this series of articles covering the ways you can improve business recovery, while increasing your service revenue. I’ve covered a number of ways to recover entire machines using virtualization as both a platform for disaster recovery, for continuous recovery, and in cases where going virtual to virtual makes sense. While virtualization plays a dominant role in the infrastructure for many of your customers, some still have specific servers still run

Virtual to virtual (V2V) recovery involves the backing up and recovering of virtual machines. So you may be thinking that your customer already has a virtual infrastructure, so why would they need V2V recovery services? Great question, right? But there’s one presumptive point in that question that may not be true when recovery is required. When you consider your customers with a VMware or Hyper-V-based infrastructure, and think about the idea of offering V2V recovery, you pro

In my previous article (in this 8-step “recovery” program for businesses) I talked about the recovery of critical files, the recovery point objectives (RPOs) for them, and how file versioning helps meet the customer need to recover files that simply don’t change very often. But most files don’t fall into the “this is critical, but it doesn’t change much” category; I think you’ll agree that most fall into the “I created this once and never touched it again” category. So are th

Most backups are relatively small because they only contain changes made (at a file or, even better, a block level) since the last backup. But while you’re backups are busy grabbing the latest and greatest, some files simply don’t change very often and are, therefore, overlooked. For example, take an organizational chart—it is important, but won’t change daily. Now add to this the fact that your default retention of backups may only be, say, 30 days, with a few archives at mo

In my last article, I discussed how some applications are so critical, they need to be recovered using timeframes in terms of minutes – even when there’s no hardware available – making virtual disaster recovery (VDR) the second step towards building a solid business recovery program for your clients. VDR is useful in addressing the need to meet a particularly restrictive recovery time objective (RTO), but what about when a system is so critical that it has an equally restrict

Some applications will be important enough that having an ability to recover to the same (or similar) hardware isn’t enough. Take email for example. If your client has an Exchange server running and wants to make sure it can be recovered within an hour with data no more than 4 hours old, that’s an absolute standard. It means no matter what, you have an hour. Period. What if you have no network, no server hardware, how about no building? You have an hour! How in the world are