VMware Cloud Community
fusebox
Enthusiast
Enthusiast
Jump to solution

Using Asigra 8 For Backup & Restores For Virtual Infrastructure

Hi Folks!

Would really love to have your suggestions,tips,resources or advices for the below.Thanks in advance for all your time and patience.

1) What is a decent backup strategy for Non-Prod and Prod VMs running on their respective ESX hosts?

2) How does Asigra Backup & Recovery Software fare in ESX 3.5 Environments?Any basic thumbrule strategies for backing up the ESX hosts and VMs hosted on them?

3) Do we have to use VCB in conjunction with the 3rd party backup software?

4) Strategy for scheduling backup?

0 Kudos
1 Solution

Accepted Solutions
InfoStewards
Enthusiast
Enthusiast
Jump to solution

A lot of this will depend on your organization...

1) What is a decent backup strategy for Non-Prod and Prod VMs running on their respective ESX hosts?

There are two parts...what is backed up, and how often (which you ask about in #4). In general with ESX, you can back up an entire VM (all the disk and config files) as a large chunk. VizionCore's vRanger is an example of a program that does this, but there are several out there. Or you can run a client within the VM like you would within a traditional server, and backup all/subset of the files. Pick your favorite Windows backup program as an example of this.

2) How does Asigra Backup & Recovery Software fare in ESX 3.5 Environments?Any basic thumbrule strategies for backing up the ESX hosts and VMs hosted on them?

I haven't looked at Asigra for a while, but when I last did they were of the "copy the VM disk to the vault" model. From there, it was possible to take advantage of the offsiting features of Asigra.

3) Do we have to use VCB in conjunction with the 3rd party backup software?

No, you don't have to. A number of packages do support VCB now, which will offload the backup processing from your ESX servers to the VCB server. If you don't use VCB, the ESX server is doing the backup processing work.

4) Strategy for scheduling backup?

It depends on the tolerance for data loss. If mgmt is willing to lose a day of work on the production systems and a week of work on the non-prod systems, then the systems should be backed up daily and weekly, respectively. As a rule of thumb, the more it will cost to replace data over a time period, the more often the data needs to be backed up - to the point where the replacement and backup costs balance.

View solution in original post

0 Kudos
1 Reply
InfoStewards
Enthusiast
Enthusiast
Jump to solution

A lot of this will depend on your organization...

1) What is a decent backup strategy for Non-Prod and Prod VMs running on their respective ESX hosts?

There are two parts...what is backed up, and how often (which you ask about in #4). In general with ESX, you can back up an entire VM (all the disk and config files) as a large chunk. VizionCore's vRanger is an example of a program that does this, but there are several out there. Or you can run a client within the VM like you would within a traditional server, and backup all/subset of the files. Pick your favorite Windows backup program as an example of this.

2) How does Asigra Backup & Recovery Software fare in ESX 3.5 Environments?Any basic thumbrule strategies for backing up the ESX hosts and VMs hosted on them?

I haven't looked at Asigra for a while, but when I last did they were of the "copy the VM disk to the vault" model. From there, it was possible to take advantage of the offsiting features of Asigra.

3) Do we have to use VCB in conjunction with the 3rd party backup software?

No, you don't have to. A number of packages do support VCB now, which will offload the backup processing from your ESX servers to the VCB server. If you don't use VCB, the ESX server is doing the backup processing work.

4) Strategy for scheduling backup?

It depends on the tolerance for data loss. If mgmt is willing to lose a day of work on the production systems and a week of work on the non-prod systems, then the systems should be backed up daily and weekly, respectively. As a rule of thumb, the more it will cost to replace data over a time period, the more often the data needs to be backed up - to the point where the replacement and backup costs balance.

0 Kudos