"Re-Seeding" on Copy Job.

[Berniebgf]

Hi All,

Can someone explain how / if any "re-seeding" options are available for the following scenario.

1. Backup Job - Reverse Incremental
WAN LInk
2. Copy Job - Copy Job with GFS.

If I have a working solution over a WAN link for the Copy Job, how can I "re-seed" if the data change rate @ the production site "blow's out" for a day or two not allowing the copy job to catch up within the Copy Job interval?

Thanks

Bernard.

[foggy]

Bernard, you will have to perform the normal seeding procedure in this case. Unfortunately, this will cause the backup copy chain to start anew.

[tsightler]

Actually, I've successfully used a somewhat "creative" method to get around this issue (re-seed while keeping the chain). Actually, it might not count as "re-seeding", but it's close. Here's the idea:

1. Stop the current Backup Copy (it's not finishing anyway)
2. Copy current VBK from backup chain to external media
3. Ship external media to remote site
4. Add external media as a repository
5. IMPORTANT -- create a dummy job to map to it
6. Modify the original Backup Copy job to use this external media repository as the source (you can specify the specific source repository on the VM selection page for the Backup Copy job.
NOTE 1 -- You may need to temporarily increase the interval so that the job will copy points older than 1 day. I usually just bump up the interval to 1 week or longer.
NOTE 2 -- If using WAN acceleration, you'll likely want to disable that temporarily for this portion
7. Run the Backup Copy, this will copy the new point from the temporary repository on the external media instead of from the source repo across the WAN.
8. Once that new point is finished copying, edit the Backup Copy back to the "normal" source repo and interval settings.
9. Remove the temporary job, repository (i.e. cleanup the changes)

I've tested this method in the field with good success. It's also useful in cases where a new VM, or small group of VMs, is added to a backup copy and they are too big to do their initial full across the WAN. You can use a slight modification of this method to "re-seed" the new VMs into the existing job while keeping the existing chain intact, and even keeping the existing chain of VMs running nightly.

Effectively you're temporarly forcing the Backup Copy to use a different source for the Backup Copy. It

[tfelice]

tsightler, great idea. I follow your logic except for step 5. Is the dummy job a backup job or a backup copy job? Either way, I don't see how you're using it. Why is it needed?

[veremin]

Based on my understanding, it should be a "dummy" backup job. Once created, the job is mapped to the external repository. The backup copy job, then, will be able to recognize restore point located on external media and copy it accordingly. Thanks.

[Berniebgf]

Thanks tsightler,

Can you confirm the following

1. Step 5 . Dummy Job Backup or Backup Copy?
2. Step 7. If Dummy job is a Copy job are we running the original or Dummy Copy Job in Step 7? (Wow! does that even make sense?)

Thanks for the idea!

Bernie.

[tsightler]

The "dummy" job is just a normal backup job mapped to that new repository so that you can easily use it as a "source" for the Backup Copy as imported backups can't be used as a source I don't believe. Creating a "dummy" backup job and temporarily mapping it to the imported backup allows it to be selected as a source in the Backup Copy job, that's really the only purpose it serves in this scenario. There might be a way to do without steps 5 & 7, perhaps it's possible to still select that repository as a source using the source button even without this step, but it didn't work for me so I just "hacked" around it with a dummy job. I'll try it again in the lab later in the week.

[ABCData]

Veeam B&R 7.0.0.871

Backing up 6 VMs at present, though that will increase as more servers are migrated to vSphere (3 hosts licensed via vSphere Essentials). Veeam runs on a physical Server 2012 R2 box which is also the on-site repository. It has a direct link into the iSCSI LAN to access the SAN.

There is a single job for the VMs, running each night at 21:00 and is set to keep 21 restore points. The report from last night's run says 14.9GB read and 3.3GB transferred.

A single Backup Copy job is set to run at 00:00 each night to copy the changes to another physical Server 2012 R2 box which is off-site (with 10Mbps upload bandwidth). The off-site server is configured as a Veeam repository. That job is set to keep 4 weekly backups, 2 monthly backups, 4 quarterly backups and 1 yearly backup.

One of the VMs is a file server and we want to move some other file shares to it. This will add at least 200 to 300GB to the server.

My concern is that will take days to replicate off-site at 10Mbps, so can I re-seed just that server off-site using a USB disk (whilst keeping the retention points in the off-site repository)? It's something I'd like to repeat as additional VMs are created and added to the main backup job. Could I:

• Suspend the Backup Copy Job
• Copy the whole local repository to a USB drive and take to the off-site server
• Attach the USB drive to the off-site server and add it as a new repository?
• When the Backup Copy Job is enabled, will it use the USB drive as the source rather than dragging everything over the WAN?
• Remove the USB repository in Veeam once done and then go back to replicating over the WAN again

Thanks,

Chris.

[foggy]

Chris, please review the procedure described by Tom above, should be exactly what you're looking for. Thanks.

[ABCData]

Thanks Foggy - searching had turned up a few posts but not that one - it looks like just what I need.

[Skyview]

Here's the scenario:

Local VMWare cluster backs up to a local windows file system repository. Then nightly a backup copy job is performed to an offsite windows file system repository.

A VM in one of the jobs (that includes about a dozen VMs) suddenly is getting an influx of about 1TB of data.

How do I seed my offsite backup repository with just this new data without having to do a full backup to some portable storage?
If I can't, does this mean I will lose my backup history at the offsite backup copy target repository?

[Shestakov]

Hi,
Seeding can be accomplished if you have .vbk file or the whole chain copied and rescanned on the target repo.
So you need to perform these steps for seeding.
Thanks!

[Skyview]

Just to be clear, you understand this is not an initial seed. This is a seed to deal with a sudden spike in data that I don't necessarily want to copy across the wire.

I know I can just perform the steps of an initial seed, but my concerns are:
A) That may be to much, in my case or others, for portable storage to handle easily
B) My existing history at the backup copy target repository will be lost. I may need that for compliance purposes.

[Shestakov]

I`ve got your point, but you need to seed the whole chain, not just a single file.
There is .vbm file containing information about the chain, if you copy the single .vib, its metadata will not be present in the .vbm file.
So you need to either copy the increment like it is or seed the whole chain.

My existing history at the backup copy target repository will be lost. I may need that for compliance purposes.

In both cases the information on the target will not be lost. Could you explain your concern here?
Thanks!

[foggy]

How do I seed my offsite backup repository with just this new data without having to do a full backup to some portable storage?

Please review the solution suggested by Tom above, should address your concern.