Backup and recovery site if possible,

[JosueM]

Good day everyone,

Attached is the image of our current setup. I would like to heard ideas for best way to get backup onsite and recovery if possible to remote site.

This is what I'm considering.
On main site:
1. Replicate to isci02 lun02 the most critical vms (AD, exchange, app server) all sum about 3.5 TB. Why replicate cuz it seems to be more store efficiente than backup, in my tests to backup 3.5 TB using backup job and retention policy of 7 assuming 1 backup per day means you need at least 7TB of backup storage, instead with replication you would be ok with about 4TB of backup storage. Please if my analisis is wrong correct me.

On remote site:
1. Replicate to isci03 lun02 the most critical vms (AD, exchange, app server) all sum about 3.5 TB. Here not have clear how to handle IP and rounting in case the main site goes down.
2. Backup the rest of VMs trying to cover the most important ones since the storage space limitation.
Here my main concern is what type of backup to use:
a) if use incremental could make iniatilization taking a full local and moving the data phisicall to the remote site then keep doing just incrementals.
PROS: just moving data changed CONS: less efficient use of storage as per my analisis of backups instead replica.
b) if use reverse incremental could make same initalization as option a) but at the paying price of moving more data over the link.
PROS: efficient use of storage at remote site CONS: everyday will have to move much more data over the link.

I will appreciate your comments and ideas to figure out the best way to make the use of veeam for this scenario.

[veremin]

Before we start to discuss DR plan, it'll be interesting to clarify some questions.

Firstly, replication can not be considered as a sufficient replacement of backup, as they are serving completely different purposes; so, keep that in mind.

Secondly, backup restore points should occupy less space than replica ones do, as they are stored in highly compressed and deduplicated state. Thus, the results you saw are not expected. Can you tell what backup mode you were using? (forward or reversed incremental one)? Didn't you perform only full backups, by any chance? If not, what were the sizes of full backup and subsequent increments?

Thanks.

[foggy]

In addition to what Vladimir has mentioned above:

Here not have clear how to handle IP and rounting in case the main site goes down.

There's replica re-IP functionality implemented to help in addressing this concern.

a) if use incremental could make iniatilization taking a full local and moving the data phisicall to the remote site then keep doing just incrementals.

This is called backup seeding and can be performed with the help of the ability to map the backup job to the backup files physically copied offsite.

[JosueM]

Hello Eremin,

A backup job that contains 2 domain controllers (win2k3), a centos linux mail gateway and two exchange servers (win2k3,win2k8) with a data size of 968GB, the first (FULL) backup takes 552GB (dedup 1.2, compression 1.4), next sequentials backups takes about 10GB and it runs once a day. This was done with default settings nothing have been modified, the mode use is Incremental and synthetic full is check to run on saturday.

Another backup job contains one windows 2003 file server and two windows 2008 fileservers with data size of 1.8TB. the first (FULL) backup takes 1.3TB (dedup 1.2, compression 1.1), next sequentials backups takes about 20GB and it runs once a day. Created with default settings and same incremental as above.

These are two of the most significative jobs that were run.

[veremin]

May be my estimations are not that good, but how did you get 7 TB?

The jobs with 6 daily increments and 1 weekly full each will occupy about: 2 TB (552+6*10+1.3TB+6*20 ~ 2TB)

with 12 daily increments and 2 weekly fulls each: ~4TB

Thanks.

[JosueM]

Hello Foggy,

For one side there a few windows and linux application servers that I'm not sure if they like the IP change and don't know if they will run ok after changing IP, I'll have to test this first. On the other hand there is not a good DNS implementation and many clients have their configurations based on ip addresses not server names.

In case of main site lost, I believe we will have to figure a way to make the redirection by the way of the routers and of course manually. Will also test this to add the implicit time in the recovery process. since currently there are only 8 remote branch officess that access the servers , I think the manual change in routing should be done in a timely fashion.

[JosueM]

Hello Eremin.

Cuz in the example I gave there was missing the application server, I did a excel with how I made the calculations and so the estimated storage used for backup and in fact the estimated storage for backup is more that 7TB as I initially mentioned.

[JosueM]

Before we start to discuss DR plan, it'll be interesting to clarify some questions.

Firstly, replication can be considered as a sufficient replacement of backup, as they are serving completely different purposes; so, keep that in mind.

Secondly, backup restore points should occupy less space than replica ones do, as they are stored in highly compressed and deduplicated state. Thus, the results you saw are not expected. Can you tell what backup mode you were using? (forward or reversed incremental one)? Didn't you perform only full backups, by any chance? If not, what were the sizes of full backup and subsequent increments?

Thanks.

Hello Eremin,

I've read the discussion about Backup vs Replication, since the post is from 2011 and it references to V6. I have searched in the help but did not find the maximun restore points allowed for backup and for replication in current version 7.

Some of that previuos post mentioned the backup is "more disk space efficient (compressed and deduped)", I would like to find how to take advantage of it but in my tests (hopping I'm doing the things well) the backup job needs about twice storage than replication jobs compared on the same period of time.

[veremin]

The maximum number of replica restore points is 28.

As to space savings, there are several options available for you:

1) Enable "transform previous full backup chains into rollbacks" option.
2) Switch to reversed incremental mode.
3) Wait till version 8 and put new forever incremental mode into use (the same mode that is currently available for backup copy jobs only).

Whatever option you choose, it should allow you to reduce space required for storing backup data.

Thanks.

[JosueM]

I did find some articles by Luca Dell’Oca where suggest an interesting option for scenarios like this one. It would consider using reverse incremental on main site and the backup copy to remote site, in theory seems a great solution. Will give it a try a then comment how it goes.

Thanks.

[veremin]

New forward incremental forever backup might be also your way to go. It works similar to reversed incremental mode, but puts less stress on the underlying storage. Thanks.

[dellock6]

Thanks for the mention Josue

[JosueM]

I did a test recovery but there are some issues with this:
1) a full vm backup is terrible slow (proxy and backup repositories are virtual VM)
2) an instant recovery allow to star the VM in a few minutes but it runs really slow, then using vmotion to move the iscsi storage is even slower, I noticed that the backup server (wich is runing Veeam Power NFS) and cpu is about 20%, memory about 50% and network usage below 10% and the proxy server is neither doing anything at all.

Any idea How can I improve restore speed in both cases ?

[veremin]

From which site to which you're trying to restore? Also, tell us a bit more about repository used. Thanks.

[JosueM]

Hello Eremin,

REstore was attempt to made from the remote site, reading data from the backup copy destination storage repository.

Thanks

[veremin]

Restore was attempt to made from the remote site

That's the reason. Restore can be as fast as corresponding link between two sites allows it to be. Thanks.

[JosueM]

notice that all the processing was done at remote site, the wan link was not using at all. cuz all the components: backup server, proxy , backup repository and new restore destination is on remote site.

I was just trying to restore the VM to test it was working.

thanks.

[foggy]

Make sure hotadd mode was used during full VM restore.