Replicating backups offsite

[jpaul]

What is the suggested way to replicate our vbk and vbr's offsite?

I work for a var and we have customers who are using Veeam backup but also want us to get their data back to our datacenter. Im considering a few things but not sure what works well, and what Veeam supports.

My first thought would be to use some sort of block level replication at a SAN level... this doesnt work for customers who dont want to invest in a backup san.

Next thought, use Veeam's file copy feature... but will this only copy files that have changed ? Is it efficient enough to be used over WAN?

last thought was rsync.... thoughts ?

Thanks in advance.

[Gostev]

Hello Justin, it is rsync. A lot of customers are using it today successfully!

Search for rsync on this forum for more information, there are many detailed discussions on this topic, for example:
Replicating .vbk Files Using DFS-R
off-site backup ideas
Veeam Off Site Backup/Replication
Backup to offline/removable storage

[egroeg]

[merged with existing discussion]

Any recommendations from the forum for decent off-site remote backup for veeam backup files.

Customer is a single site without the infrastructure or geographical split to utilise Veeam replication over the WAN, so simply wish to write Veeam backup files to a datastore and then send these VIB files off site with an third party product.

Anyone doing this or any open recommendations?

[gshaw]

[merged with existing discussion]

Was just wondering if this is somehow possible without using 3rd party file replication tools?

What I basically want is to have the Veeam backup files in two locations but without having to run two backup jobs (seems a bit pointless doing all the work re-examing the VMs when all I want is a replica of the files).

I understand best performance is most likely going to come from a physical server using SAN mode but I can't keep a full-blown server anywhere else apart from the server room. Obviously the thought of that being the only copy of the files makes me somewhat nervous so I'd also like to have a 2nd set of backup files on something like a QNAP NAS over CIFS, is there any way to do this?

[Vitaliy S.]

Hi Gerrard,

If you don't want to use 3rd party utilities (such as rsync), the only way out would be to create another Veeam backup job and point it to the offsite location. Thanks.

[Gostev]

And in this case you will want to backup to a Linux target (to enable the job to use remote agent in an offsite location). This is actually quite typical offsite backup architecture for many Veeam customers. There are many topics around discussing it, if you want to learn more about this approach. Thanks.

[derekf]

Hi all,

I'm new and this is my first post, but we're very excited about the possibilities that are offered to us using Veeam as a new tool in our virtual environment.

I've been looking through this thread and the other links referred to it (a great forum and a great resouce), but want to clarify the idea I've currently got.

The situation is that we have an ESX host in a production location which we will run Veeam backups on to create local backups (and might use rsync to get another copy onto removable media as that looked like a good tip). Veeam backup server will initially be a virtual machine, but if it requires moving to a physical machine also in the production site we'll look to do that in the future.

However, in addition to the above we want to be able to have a DR site where we can spin up VMs in the case of a disaster.

So what I was thinking was that in addition to the production backup server backing up the ESX host locally I'd create a replication job to replicate the VMs to an ESX server in the DR datacentre (we have a private 100Mb link we can use for this).

This strikes me as providing a way for bringing up the servers in the DR site quickly in the event of a disaster at the production site. I also like some of the links for testing that are in the forum so that's a bonus.

The reason for replication is that we can spin up quickly, with full I/O and without the requirement or reliance on the Veeam backup server which may have gone down with the disaster affecting the primary site (we'd use vCenter or vSphere Client to spin up from the remote site in DR mode).

My questions are:

1. Does this sound like the best option to allow for local backup in the production site and a replicated DR solution in the DR site?

2. I've seen that it's not possible to concurrently perform replication and backup on the same VM - does that mean that I need to schedule backups and replication to avoid clashes?

3. Should I consider using an additional Veeam backup server at the DR site and use that to perform the replication job instead to allow me to have Veeam backup server control

4. If we had the DR server spun up and running and the production site came back on line and tried to perform a replication what would happen and what should we do to avoid this?

5. Finaly, we use vCloud DIrector for user access to VMs in the DR site. I don't think that should be a problem as we can create the replicated VM using Veeam backup server and then look at importing it into vCD for user access via console etc, but wondered if anybody had seen this sort of setup.

Thanks

Derek...

[Vitaliy S.]

1. Does this sound like the best option to allow for local backup in the production site and a replicated DR solution in the DR site?

Yes, this is one of the most commonly used DR scenarios for now.

2. I've seen that it's not possible to concurrently perform replication and backup on the same VM - does that mean that I need to schedule backups and replication to avoid clashes?

That's right. You should use different time schedules to backup those VMs. For example you may want to daisy chain those backup/replication jobs with the help of PowerShell scripts.

3. Should I consider using an additional Veeam backup server at the DR site and use that to perform the replication job instead to allow me to have Veeam backup server control

The answer depends mainly on the host type at the DR site. If you have ESXi host deployed in the DR site, then you definitely want to install additional backup server to get better performance rates while running replication jobs. Please search these forums for more information about replication to a remote site.

4. If we had the DR server spun up and running and the production site came back on line and tried to perform a replication what would happen and what should we do to avoid this?

I'm not sure I got your question completely, but once you have the production site brought back you can create replication jobs and migrate VMs back to the production hosts.

5. Finaly, we use vCloud DIrector for user access to VMs in the DR site. I don't think that should be a problem as we can create the replicated VM using Veeam backup server and then look at importing it into vCD for user access via console etc, but wondered if anybody had seen this sort of setup.

I haven't seen that, but I do not expect to have any problems with that.

[derekf]

Hi Vitaly

Many thanks for the reply.

We are using ESXi so will look at a host on the DR site (although that gives initial seed problems - roll on v6!!!).

What I meant in question 4 was if we powered on the DR machine and it's running and the original site came back on line and it's Veeam backup server tried to replicate data over what would happen? I would hope that VMware would have effectively locked the vmdk etc of the running DR machine and that the Veeam backup server logged an error. I know we'll want to disable replication as soon as possible from the source, but just wanted to check if there are possibilities for corruption I need to consider

I do like the replication back to the target site after a disaster - makes life easier, and if the DR site has the veeam server on it then we could use the initial seed method I assume...

[Vitaliy S.]

What I meant in question 4 was if we powered on the DR machine and it's running and the original site came back on line and it's Veeam backup server tried to replicate data over what would happen? I would hope that VMware would have effectively locked the vmdk etc of the running DR machine and that the Veeam backup server logged an error.

The original replication job would fail, because the VM running on the DR site would lock its vmdk file.

I do like the replication back to the target site after a disaster - makes life easier, and if the DR site has the veeam server on it then we could use the initial seed method I assume...

That's correct.

[bbeavis]

[merged]

Background about th issue:
I imagine this topic comes up from time to time. We recently had our annual DR test and honestly Veeam would score a D-. In prior years, Veeam has been the MVP of the DR test. Perhaps this year we pushed it too hard. Here is our setup:
SRV1 runs ESXi 4.1U1
SRV2 runs ESXi 4.1U1
SRV3 runs Windows 2008 with current SP, this is our vCenter/Veeam/Backup/etc system.

Everything is local storage, i.e. no SAN. Veeam backs up from ESXi to a removable USB drive(encrypted) plugged into SRV3. Synthetic backups 1 full and 6 reverse incrementals per week, USB swapped weekly and sent off-site.

All seems to work out fine. Upon DR, we discover one of the backups will not import. So those systems are restored from a second USB. Not necessarily the fault of Veeam, however I called support and asked for help. Told to call DR, then Cell, then email in that order and that we were DR Testing. My hope was to get instructions on how to rebuild the backup through some utility. I received, quite later, and email telling me to re-run the backup. Exactly how I am expected to do that in a "Disaster" is beyond me. Because I could not install Veeam on our Windows 2008 system (later discovered a SQL Express issue), I installed Veeam to a Windows XP system and restored from there. Because the XP system was on a 100 Mb segment, some restores ran all night. And thankfully Microsoft automatically rebooted the systems because of automatic updates. One job (600GB) was 56% complete and the other was 96% complete. As far as I could tell there is no resume feature for restore, I HIGHLY RECOMMEND ADDING THIS FEATURE IF NOT ALREADY. So I was forced to restart both jobs. The 600GB never restored as it would fail with different errors. Luckily, that was the file server data which I had on tape. I was hoping to use this test to eliminate tape.

Sorry for rant, but it gives background it how we use different tech and he problems we have faced. So I ask, what are people using for off-site backups?

I have been playing around to improve our setup. I will be changing the backup from straight to USB to a landing zone mirrored to USB. This should stablize issues with the DB being inconsistent with the USB. I will also be reverting back to VM Copy process for at least 1 Domain Controller. I am nervous about the backup files being inaccessible. I would like to be able to replicate to a folder on SRV3 through NFS, but I can't seem to get that to work. VM Copy with change block or replication to a removable device would be awesome. Any thoughts, feedback, suggestions? Thanks.

[rmeyerowitz]

[merged]

Hi,

I am looking for advice on backups a replication. Customer has limited bandwidth. Production VMware datastores are being replication with array based replication. Customer backups up with Veeam in Production datacetner. Customer only wants to replication Veeam backups to DR. I believe that array based replication will have issues replicating synthentic fulls because all the blocks would change and over 800GB of data will have to be replicated. Any advise? Should I create 2 different backup servers? 1 in Prod and 1 in DR? Will the DR backup server be able to backup prod vm's over the wan?

[wmad]

[merged]

Currently, I would like to send my Veeam backup jobs offsite. Is it as simple as pointing the the backup file location (.vbk, .vrb) and moving it offsite? Will my restore points become affected? Or does anyone suggest a better solution?

Regards,
Brandon