Comprehensive data protection for all workloads
Post Reply
cip2013
Enthusiast
Posts: 29
Liked: 1 time
Joined: May 06, 2015 9:36 pm
Location: USA
Contact:

Best practice for replication to HQ

Post by cip2013 »

Can someone explain to me what is the best way to do this? We have a remote site that we want to replicate to our HQ and from there get a copy of the replica to tape for offsite storage and archiving. Currently I have it setup to replicate using Veeam to our HQ. That part works great and I have no issues with it. The problem is that you can't copy a replica VM directly to tape so I have to backup the replica with Veeam to a repository which then gets copied to tape along with the other normal backup jobs. I am getting the following error when backing up the replica: CBT data is invalid failing over to legacy incremental backup

The backups take a really long time and now I have about 10 orphaned snapshots on the replica VM. vCenter is saying that I need to consolidate. I have a feeling that I might be approaching this procedure wrong. It does seem to work for a while, but then the errors start popping up and eventually the jobs will fail. BTW, I asked Veeam support about this before I started it and they said that it would work this way.
PTide
Product Manager
Posts: 6436
Liked: 729 times
Joined: May 19, 2015 1:46 pm
Contact:

Re: Best practice for replication to HQ

Post by PTide »

Hi,

May I ask you about why do you want to place replica's on tape? Why don't you just place backups on tape?

Thank you.
cip2013
Enthusiast
Posts: 29
Liked: 1 time
Joined: May 06, 2015 9:36 pm
Location: USA
Contact:

Re: Best practice for replication to HQ

Post by cip2013 »

The source VM (small branch office) is on the other side of the country. I have three options for getting that data to our HQ site where the tape drive is; replication, direct backup over the WAN, or do a backup to a local repository and copy the backup data to the HQ. I thought the replication would be the best way to do this and it would also give us the ability to spin up the replica very quickly in the event of a disaster at the remote site. I would love to hear how other people are doing this.
PTide
Product Manager
Posts: 6436
Liked: 729 times
Joined: May 19, 2015 1:46 pm
Contact:

Re: Best practice for replication to HQ

Post by PTide » 1 person likes this post

Ok, I see.

First, restoring files from Tape can take lots of time, especially if we talk about large files (VM files) that are spread across the tape(s). In case of a disaster you can perform an instant recovery from your backup files that are stored in HQ. Also there is an option of to do replication from backup.

Second, though you can run backup from replica, indeed, there are some limitations.

Also, if you are on Enterprise Plus then you can utilize WAN acceleration for better replication performance on a slow link.

With all said, I think that the best option would be to run backup copy job to HQ with replication fom backup on the HQ side + archive backups to tape periodically.

Thank you.
cip2013
Enthusiast
Posts: 29
Liked: 1 time
Joined: May 06, 2015 9:36 pm
Location: USA
Contact:

Re: Best practice for replication to HQ

Post by cip2013 »

I understand. Part of the reason that we didn't do it that way initially is because it is recommended to perform a full backup occasionally (weekly or monthly). That means I have to transfer 1TB of data at least once a month across the WAN. That is going to require a large backup window to complete. How do you address this issue? We currently don't have Enterprise Plus.
PTide
Product Manager
Posts: 6436
Liked: 729 times
Joined: May 19, 2015 1:46 pm
Contact:

Re: Best practice for replication to HQ

Post by PTide » 1 person likes this post

That means I have to transfer 1TB of data at least once a month across the WAN. That is going to require a large backup window to complete. How do you address this issue?
You can perform periodic fulls on your branch-side - backup copy job will transfer only new blocks, not the whole backup. If you need full backups on your HQ side then you might want to utilize GFS retention - it will generate full backup file out of your HQ-incrementals without pulling fulls from your branch office.
cip2013
Enthusiast
Posts: 29
Liked: 1 time
Joined: May 06, 2015 9:36 pm
Location: USA
Contact:

Re: Best practice for replication to HQ

Post by cip2013 »

Ok, so you are saying to backup locally at the remote site and then do a backup copy job to our HQ which will only send the changed blocks on a periodic full? If that's the case then that would work. I will just need to get some backup storage out there for a repository.
PTide
Product Manager
Posts: 6436
Liked: 729 times
Joined: May 19, 2015 1:46 pm
Contact:

Re: Best practice for replication to HQ

Post by PTide »

you are saying to backup locally at the remote site and then do a backup copy job to our HQ which will only send the changed blocks on a periodic full?
Exactly. Actually, periodic fulls are not mandatory, though they may server two purposes:

1. It much safer to have more than one Full for the case if your hardware goes wild.

2. For faster recovery. The less incrementals you have between desired restore point and last full - the faster recovery procedure will go.

In case you don't want to utilize GFS feature you'll need to perform "compact full backup" operation periodically in order to save some space on your HQ repo.
cip2013
Enthusiast
Posts: 29
Liked: 1 time
Joined: May 06, 2015 9:36 pm
Location: USA
Contact:

Re: Best practice for replication to HQ

Post by cip2013 »

I usually do reverse incrementals. Does that pose any challenges in this scenario? Is one better that the other when dealing with copy jobs over the WAN?
PTide
Product Manager
Posts: 6436
Liked: 729 times
Joined: May 19, 2015 1:46 pm
Contact:

Re: Best practice for replication to HQ

Post by PTide »

In case of reverse incremental it still transfer changed blocks only, however there might be some challenges depending on your WAN link speed and on how often you are going to run your backup copy job. Please refer to this thread for details.
Post Reply

Who is online

Users browsing this forum: Google [Bot], Semrush [Bot], ybarrap2003 and 64 guests