Yes, it's true!

StorageCraft recently announced the release of StorageCraft ShadowProtect SPX (or just SPX) which provides comprehensive DR support for Ubuntu, Red Hat (RHEL), and CentOS Linux.

SPX represents a product built from the ground up by StorageCraft developers and it provides another component in the over all StorageCraft Recover-Ability solution--a platform for building fast and reliable enterprise level DR services.

If you're interested in trying out this new product to see how well it works in your environment, please visit the StorageCraft website and download a trial today. We look forward to seeing you online.

Cheers!

Hey @DustinB3403,

As Scott points out, client level backup processes protect virtual systems from inside the client OS and so they do not rely on the underlying hypervisor. And yes, we do support XenServer as well as RHEV, Oracle, Hyper-V, ProxMox, VMware, and other hypervisor platforms. StorageCraft backup images are highly portable and you can restore a VMware VM to a XenServer environment quickly and easily.

Cheers!

@scottalanmiller said:

Given the costs and the specific needs, I feel like XenServer and StorageCraft might be the most cost effective. All you have to license is the StorageCraft.

Yes, StorageCraft would be a cost effective solution here.

We support XenServer as well as ESXi (including free) and Hyper-V as well as several other hypervisor platforms. So you have a number of choices how you deploy your virtual environment because we're not tied to a specific host API to get the job done. StorageCraft uses an agent on each Windows or Linux VM to create a disk image and store it on your storage (again, you can choose what storage to use). You can license StorageCraft per agent and most of the admin tools (e.g. centralized management and monitoring, etc.) are free. Feel free to download a trial from our website, and let me know if you want someone to quote prices for you.

As an aside, if you did decide to switch from VMware ESXi to Hyper-V or XenServer at some point in the future it would be extremely easy to V2V those VMs using StorageCraft. In addition, your backup history on ESXi would continue to be used as part of the ongoing backup chain on the new server. We really do make it easy to recover anywhere!

Cheers

@hubtechagain said:

So, do i stick with ESX and get essentials for 666 bucks, and if so what backup do i use?
Do i switch do xen for the cost of me doing the work? if so what backup solution do i use?
Do i switch to Hyper-V 08r2? what backup solution do i use?

Thanks for everything guys!

You can use StorageCraft with each of these solutions. Which means my response to your question becomes, "Which of these hypervisors fits your budget and offers you the most features you'll use?" If you like one of these or are more familiar with one over the others then I would go with that one. Hypervisor features are becoming more standardized across all vendors. When one comes out with a good idea the others tend to come up with their own version of the same feature soon after. At that point it just becomes a matter of which UI you know best.

Cheers!

@scottalanmiller said:

Paging @Steven

Yep... was doing a webinar with Redmond Channel Partners at the time so I responded as soon as I could.

Thanks for the ping!

@hubtechagain said:

Well, were i to "network raid" my two hosts....I would not have enough space to handle the workload. Pretty sure that separate hosts is the way we need to stay at this client specifically. @Steven sadly you were a bit slow to the game and I think that the boys have me figured out I'm currently using thinware for my local backups. not sure if it works with HyperV or if i'll have to find another local storage backup option to push to the NAS.

I hear ya. Thanks for letting me join (late) and good luck!

My two bits:

Definitely ditch the full backup process and go with a continuous incremental process. StorageCraft will do continuous incremental backups of your virtual or physical systems as frequently as every 15 minutes. These are byte/sector level files so they're small and efficient.

Just to run the math (*assuming you have 24TB of data to back up) here are three quick examples:

1. Create a weekly full backup. This produces 24TB x 4 weeks = 96TB of backup files. Even with good compression you're still looking at a lot of storage and network traffic when replicating these offsite.

2. Initial full and then weekly incrementals backups every Saturday. Let's assume a constant change rate of around 20%/month to keep this simple which means that every weekly incremental would be about 5% x 24TB in size. The first month would be 24TB (base full) + 1.2TB x 3 weeks or 27.6 TB. Every subsequent month would only be 4 x 1.2TB or 4.8TB of storage. Compression would further reduce the storage requirements.

3. Now for the really slick option... since this is a continuous rate of change we can increase the recovery points (capture incremental files more frequently) without affecting storage too much. For example, each 15 minute incremental file would be approximately 24TB x (.05/week) x (1 week / 7 days) x (1 day / 24 hours) x (4 backups / hour) = about 28.5GB every 15 minutes. The advantage here is that you have about the same amount of data your storing as in option #2 but you have granular recovery points every 15 minutes of every day in the week. So you can select a very specific point in time to recover.

Obviously, this math is over-simplified and you should benchmark your own numbers. But even with a simplified model it should be obvious that periodic full backups are much more storage intensive than incremental backups. And a continuous incremental scheme can produce a powerful granular recovery through the amount of recovery points generated.

The only reason I see people do full backups is because their backup process rolls up these continuous incremental files into a synthetic full which means that if corruption gets into just one of my recovery points my synthetic full is now corrupt. Essentially the periodic full backup is their way of re-basing a backup chain to keep out corruption.

(This became longer than I expected... maybe I should've made the value bigger than "2 bits")

Cheers!

@DustinB3403, just some quick responses:

Is there any documentation that I can review regarding SC and XS working together?
Just looked for documentation beyond the normal user guide and support information. Didn't see any, so I'm asking the content team. Did you have something specific regarding "working together"? Because to the client VM the hypervisor is transparent. Are you looking for product integration?

Does every version of SC, support VM backup and restore?
Yes, absolutely. Again, the process isn't tied to the hypervisor host. Which means it's as easy to restore to XS as it is to restore to VMware or Hyper-V.

Are there data limits to SC?
There are no known data limits. Our engineers (in the spirit of good fun) have toyed with some theoretical limits but I doubt we'll ever see those IRL.

Is there anyway to see a demo on StorageCraft restoring a XenServer VM?
I can get you in touch with an SE to give you a personal demo. Just send me a PM and I'll get the ball rolling. (I'd offer to do it myself but I just rebuilt my lab as Hyper-V to test some of our new tech and I'm locked into that platform for at least a month--sorry.)

Cheers!

@scottalanmiller
Mmmm... Minecraft!

So it looks like most of my work is done? StorageCraft is a disk imaging backup solution. We snap VM volumes directly and ship these off to your available storage. A continuous incremental backup takes an initial full and then changes afterwards. Backups are compressed/encrypted and managed centrally and can be replicated locally/offsite for failover and/or archival.

We're known for our Windows agent (same one VMware licensed for VM Converter 3.0) and we've also produced our own Linux imaging driver. Not sure what else to tell you besides we recently picked up $187M in investment funds from TA to help us grow bigger/faster (pretty cool!).

Feel free to ping me if you have any specific questions!

Cheers

Hey @DustinB3403,

As Scott points out, client level backup processes protect virtual systems from inside the client OS and so they do not rely on the underlying hypervisor. And yes, we do support XenServer as well as RHEV, Oracle, Hyper-V, ProxMox, VMware, and other hypervisor platforms. StorageCraft backup images are highly portable and you can restore a VMware VM to a XenServer environment quickly and easily.

Cheers!

@scottalanmiller said:

They have an online video of this. Under two minutes. The video is useful but I don't know about that Steven guy doing the demo...

Youtube Video

Yeah... they really need to get someone new!

@DustinB3403, just some quick responses:

Is there any documentation that I can review regarding SC and XS working together?
Just looked for documentation beyond the normal user guide and support information. Didn't see any, so I'm asking the content team. Did you have something specific regarding "working together"? Because to the client VM the hypervisor is transparent. Are you looking for product integration?

Does every version of SC, support VM backup and restore?
Yes, absolutely. Again, the process isn't tied to the hypervisor host. Which means it's as easy to restore to XS as it is to restore to VMware or Hyper-V.

Are there data limits to SC?
There are no known data limits. Our engineers (in the spirit of good fun) have toyed with some theoretical limits but I doubt we'll ever see those IRL.

Is there anyway to see a demo on StorageCraft restoring a XenServer VM?
I can get you in touch with an SE to give you a personal demo. Just send me a PM and I'll get the ball rolling. (I'd offer to do it myself but I just rebuilt my lab as Hyper-V to test some of our new tech and I'm locked into that platform for at least a month--sorry.)

Cheers!

My two bits:

Definitely ditch the full backup process and go with a continuous incremental process. StorageCraft will do continuous incremental backups of your virtual or physical systems as frequently as every 15 minutes. These are byte/sector level files so they're small and efficient.

Just to run the math (*assuming you have 24TB of data to back up) here are three quick examples:

1. Create a weekly full backup. This produces 24TB x 4 weeks = 96TB of backup files. Even with good compression you're still looking at a lot of storage and network traffic when replicating these offsite.

2. Initial full and then weekly incrementals backups every Saturday. Let's assume a constant change rate of around 20%/month to keep this simple which means that every weekly incremental would be about 5% x 24TB in size. The first month would be 24TB (base full) + 1.2TB x 3 weeks or 27.6 TB. Every subsequent month would only be 4 x 1.2TB or 4.8TB of storage. Compression would further reduce the storage requirements.

3. Now for the really slick option... since this is a continuous rate of change we can increase the recovery points (capture incremental files more frequently) without affecting storage too much. For example, each 15 minute incremental file would be approximately 24TB x (.05/week) x (1 week / 7 days) x (1 day / 24 hours) x (4 backups / hour) = about 28.5GB every 15 minutes. The advantage here is that you have about the same amount of data your storing as in option #2 but you have granular recovery points every 15 minutes of every day in the week. So you can select a very specific point in time to recover.

Obviously, this math is over-simplified and you should benchmark your own numbers. But even with a simplified model it should be obvious that periodic full backups are much more storage intensive than incremental backups. And a continuous incremental scheme can produce a powerful granular recovery through the amount of recovery points generated.

The only reason I see people do full backups is because their backup process rolls up these continuous incremental files into a synthetic full which means that if corruption gets into just one of my recovery points my synthetic full is now corrupt. Essentially the periodic full backup is their way of re-basing a backup chain to keep out corruption.

(This became longer than I expected... maybe I should've made the value bigger than "2 bits")

Cheers!

@hubtechagain said:

using the hyper v replication, how do the VMs behave? they're offline, replicating, then boom, tree crashes through building and smokes our server rack. i just remote into the DR server and spin em up?

As I understand it, writes to one VM are also sent to the replica. The data sent happens at set intervals (e.g. 30s, 5min, and 15min). This creates redundant VMs on the two hosts with the replica slightly behind the source. When a tree crashes through the roof and craters one VM then the other simply keeps running (either it's the source and the target no longer receives updates, or it's the target and the host doesn't care).

@hubtechagain said:

Well, were i to "network raid" my two hosts....I would not have enough space to handle the workload. Pretty sure that separate hosts is the way we need to stay at this client specifically. @Steven sadly you were a bit slow to the game and I think that the boys have me figured out I'm currently using thinware for my local backups. not sure if it works with HyperV or if i'll have to find another local storage backup option to push to the NAS.

I hear ya. Thanks for letting me join (late) and good luck!

@scottalanmiller said:

Paging @Steven

Yep... was doing a webinar with Redmond Channel Partners at the time so I responded as soon as I could.

Thanks for the ping!

@scottalanmiller said:

@Dashrender said:

@scottalanmiller Would StorageCraft in this case basically just sync his VM's from one client to another at a given point in time? I think that is real goal here. If the main site dies, Hub wants to connect to the VM host in the remote DC and just turn on the VMs there so they company is back on line.

Yes, it would be an incremental backup from one site to the other. As well as taking normal "on site" backups. It's a full backup utility.

That's correct. This design is especially useful as a warm failover when replicating between sites rather than replication between two hosts at the same site. As Scott points out, Hyper-V will replicate between hosts. VMware does this with vMotion as well. These provide native replication between two hosts on the same hypervisor platform.

Replicated backup image files become more useful when you:

A) you want to lower costs. For example, your hypervisor of choice charges for this feature.
B) you want to reach back into the past. For example, you get a virus and want the far side to use a virtual disk based on a point in time prior to the infection.
C) you have limited resources at the offsite. For example, your offsite is primarily a storage repository but you have some compute resources available. Those resources can be used as a temporary failover for onsite systems by implementing a backup image in the offsite storage. Public cloud services are a good example of this where you use offsite mostly for storage and only spin up a VM when needed.

@hubtechagain said:

So, do i stick with ESX and get essentials for 666 bucks, and if so what backup do i use?
Do i switch do xen for the cost of me doing the work? if so what backup solution do i use?
Do i switch to Hyper-V 08r2? what backup solution do i use?

Thanks for everything guys!

You can use StorageCraft with each of these solutions. Which means my response to your question becomes, "Which of these hypervisors fits your budget and offers you the most features you'll use?" If you like one of these or are more familiar with one over the others then I would go with that one. Hypervisor features are becoming more standardized across all vendors. When one comes out with a good idea the others tend to come up with their own version of the same feature soon after. At that point it just becomes a matter of which UI you know best.

Cheers!