Seeding v7 backup copy

[Dsmelser]

I'm looking to use the WAN accelerated backup copy feature of v7.
Is there any way to seed the remote copy?

[tsightler]

Sure, it's a very simple process. Since backup copy jobs are simply copying from one repository to another, you can pretty much use any copy of the repository as a seed. For example, make a copy of the local repository to USB, ship it to remote site, copy it to it's final destination, then configure that destination as a repository in the Veeam console. Once done, create a Backup Copy Job and choose the target repository and map to the specific backup. Even cooler, this seeded backup will be used to populate the global WAN cache on the target side as well (happens automatically during the first run if the cache is not yet initialized). This will take some time and use some disk I/O on the target, but will use almost no WAN bandwidth at all.

[ManuelRighi]

Hello,
I try to test WAN Accelerators.
I have big VM size and 2 Mbps internet connections.

It's possible to make a copy and take it (trivially with a usb hard disk) in the datacenter and later run the wan accelerator job ?

[foggy]

Sure, this process is called seeding and is described in the post above in detail.

[Ejdesgaard]

Hi,

I have upgraded from 6.5 to 7 with a ESXi-5.1 backend and the old jobs run as usual, but when I try to make a backup copy job, to replaec the offsite-* jobs, where I add a VM "From Backup" and then try to map it to the backup on the remote Repository, that 6.5 took backup to and v7 with the 6.5 jobs currently takes backup to, I get the this error: "No backup it attached. Cannot map backup." Even tho I pointed at the backup job that contains the latest offsite backup.

So why doesn't the backup copy job reconice the backups on the remote repository?

Regards
Heðin

[foggy]

Heðin, if you've specified correct backup repositories and still cannot get the job mapped, I suggest to open a case to review the logs, they should clearly tell the reason of this error.

[foggy]

It turns out that backup copy job can be mapped to a single full backup file only while you're trying to map it to the existing backup chain (that already contains increments). You can temporarily offload everything except the latest vbk to some other folder and retry mapping. After the required number of restore points is created by the backup copy job, that temporary folder can be removed.

[Dave-Departed]

I'm seeing a similar behaviour... Except I am indeed trying to map the job to the latest vbk file, and no other increments reside in the folder with the vbk file. I've rescanned the offsite repository, as well as importing the backup, and it just doesn't show up in either a normal backup job OR a backup copy job, when I try to map the backup.

For the record, the test backup/backup copy jobs that I've created from scratch in my test v7 environment work fine.

[foggy]

Dave, actually, your case is totally different (and you've already created a separate topic for it, so let's discuss it there).

[b.vanhaastrecht]

Hi,

We have two sites. One in a DC which is the primary. Backup Job specs:
- Backup to NAS
- Multiple VM
- Reversed Incremental
- 14 restore poinst
- DisableVBKRename regkey set to 1

The secondary site, also has a NAS. We currently do a RSYNC between the two NAS devices, but this is a very inefficient sync protocol. So we want to switch to Veeam Proxy/Sync, posibly with WAN acceleration. I've setup a proxy and repository to the NAS. Then I did a 'Rescan Repository', the backup showed up. When I try to map this backup to the copy job, the I get a error "No backup is attached. Cannot map a backup".

I've seen other posts about this same error, they stated it has something to do with the incrementals. So I placed the .vbk file without the meta file in a seperate directory. Then i did an import. But then the imported backup is not attached to a repository, this field stays empty. And therefore it's not selectable in the "Map backup" wizard.

What I would like to know if I can use my RSYNC'ed backup to attach to my Copy Job? I would not like to resync the whole backup again, as the block are there already... Got to figure out a way to use them.

Thanks in advance! Kind Regards,
Bastiaan

[foggy]

Bastiaan, most likely you've used the full backup from the existing backup chain, while you can only map backup copy job to the separate active full backup for which there are no any incrementals present (so basically, to the backup chain containing just a single VBK file). Here is a procedure that can be used to create such single VBK from an existing backup chain with incrementals.

[b.vanhaastrecht]

Bastiaan, most likely you've used the full backup from the existing backup chain, while you can only map backup copy job to the separate active full backup for which there are no any incrementals present (so basically, to the backup chain containing just a single VBK file). Here is a procedure that can be used to create such single VBK from an existing backup chain with incrementals.

Foggy, do I understand correctly, I cannot use a 1:1 copy of the 'Backup Job' to map on a 'Copy Job' connected to the same 'Backup Job' ? All the blocks are currently there on my remote site, doing the procedure you refer to would mean another USB disk transport to the remote site.

To me this make no sense, or I don't understand correctly.

I have a support case running on this "#00433593", I've just got a indication for support that this issue could be a bug.

[foggy]

Foggy, do I understand correctly, I cannot use a 1:1 copy of the 'Backup Job' to map on a 'Copy Job' connected to the same 'Backup Job' ? All the blocks are currently there on my remote site, doing the procedure you refer to would mean another USB disk transport to the remote site.

You understand it correctly, however there is no need for another USB disk transport to the remote site, as you can perform the same procedure right in the remote location (the procedure for that case is described in the same topic referred above, right in the next post).

[b.vanhaastrecht]

You understand it correctly, however there is no need for another USB disk transport to the remote site, as you can perform the same procedure right in the remote location (the procedure for that case is described in the same topic referred above, right in the next post).

Our difference with smassey's setup is that we did not have a Backup Job to the offsite repository. In our setup we do a local backup to NAS, and the NAS RSYNC'ed this data to the offsite NAS. Now we setup a Proxy and Repository to use the same offsite NAS. And hopefully utilize the already RSYNCED Veeam backup data to use for the Copy Job we want to setup from local to offsite. I cannot perform the procedure described by smassey to create a Copy Job to create a full backup as I have no current Backup Job running to the offsite NAS/repository.

[foggy]

Well, there is still a solution, though a bit..mm..let's call it "creative".

You could do the following:
1. Create an offsite repository with the backups located at the remote site and rescan it to populate backup console with these backups.
2. Create a fake backup job and map it to these backups.
3. Create a backup copy job selecting that fake backup job as a source and run it to get a newly created full.
4. Create a new backup copy job and map it to the previously created full.

Obviously, not tested, however, looks workable.

That said, as I've already stated in the topic referred above, since you already have backups at the remote site, you probably do not need to map anything at all. Just register the backup repository in your backup console and backup copy job will populate WAN accelerator cache with the OS data stored in the backups from this target repository. This will reduce traffic to be transferred over WAN link when backup copy job processes VMs using the same OS's.

[Savashopress]

Hello all,

We are currently in the proces of setting up Backup Copy jobs for our locations overseas. Germany, Singapore, Sweden etc.

For a couple of those locations, the network line speed isnt that great and we can't seem to get a first initial backup copy to complete for locations in singapore, sweden. This is mostly due to having the normal backup running @ night and then the backup copy running during the day. But as those locations already have a limited bandwith we have those backup copy jobs Throttled which in turn doesnt let the jobs complete.

Im pretty sure it's due to the line speed cause other backup copy jobs complete as intented and are waiting for the new interval

So i am wondering if there is a way to prestage most data from the offsite locations to our main location?. After that it should only be incremental right ?

Thanks in advance.

Arnold

[foggy]

Arnold, yes you can pre-seed the backup copy using the procedure described at the beginning of this thread. Thanks.

[Savashopress]

Thanks foggy. will check it out. Seems i didnt look good enough on the forum. my bad.

[Mr_OCD]

Hi All,

I have spent the last few days with my head buried in the new v7 admin guide to find out how is best to define my disaster recovery plan round Veeam B&R.

We are presently backing up all of our VM's from a SAN to a NAS locally on site.

Now assuming I'm correct I would then need to create a backup copy job of each backup and then move this to the offsite repository, rescan the repository and create new backup copy jobs that utilise the backup copy job I created earlier.

Easy right? ... I wish

... transferring the backup copy job from the local NAS to the remote site is very very slow. Therefore I had the idea of copying from the local NAS to a local USB disk, delivering to the site and copying to the remote NAS.

- regardless of if I use file copy job or simple cut/paste of directories it is taking around 48hrs to copy data to the USB drive (approx 800GB) ... any suggestions on how to speed this up?

We are using a 10mb leased fibre line and I've WAN accelerators enabled between onsite and offsite.

- I tried a simple (small) backup copy job and then moved over to the remote site and resync the remote respository... but to get this working properly I had to 'map' the backup ... I don't fully understand why it is necessary to do this?

I was basically hoping to deliver the .vbk and .vbm files for each backup copy job to the remote site, resync the offsite repository and Veeam then sends over only the data blocks via CBT for minimal data transfer?

Initial impressions seems it might be a bit more involved than that.

At the moment it seems I'm making a copy of a backup locally, to then copy that copy to the offsite repository... add in seeding, mapping and slow transfers and its getting rather confusing as to what is best practice!

Any advice appreciated.

[foggy]

- I tried a simple (small) backup copy job and then moved over to the remote site and resync the remote respository... but to get this working properly I had to 'map' the backup ... I don't fully understand why it is necessary to do this?

I was basically hoping to deliver the .vbk and .vbm files for each backup copy job to the remote site, resync the offsite repository and Veeam then sends over only the data blocks via CBT for minimal data transfer?

Scott, you need to point (i.e. "map") the job to existing backups so that it could calculate differences between backup files and start transferring them.

[k00laid]

Ok, on recommendation by Rick Vanover I'm posting this here. I've been having lots o' frustration getting backup copy working in our environment, specifically getting backups to map to seed the copy job. The existing setup has 4 separate jobs run each night for local backups with an identical set of jobs run each night to our offsite repository.

My initial understanding was that I would be able to use (and IMHO should be able to use) the existing offsite backups to seed the backup copy because the backup files contains the exact same VMs as are backed up in the original jobs I would like to start copying. As you can probably guess that was a misunderstanding on my point and doesn't work. I then began reading this post and independently spoke to the presenter at the latest Columbus, OH VUG about this and took from that essentially copying the latest vbk and vbm for my reverse incremental job would allow me to seed the job. I just yesterday orchestrated getting the data physically moved for this and again, that didn't work. Finally I called support about it this morning and learned that that doesn't work either, rather you have to either

a) create a new active full backup (not good for the space constrained) and copy that or

b) create a new local repository, create the backup copy job pointed there, copy those files to USB or otherwise transport the files to the DR site, then remap the job.

In the end I am going with option c), setting a throttle on my WAN interface and letting the job just run continuously to see if I can manage to get the 4+ TB of data to sync in a week or so over a 50 Mbps link. As I am constantly space constrained in the local site and the DR site is 2 hours away with no local IT support, this is the least intrusive method at this point.

I believe that this feature is great, solving one of the original problems with Veeam, but in a general sense this is another case IMHO where Veeam needs to learn to be a little more generic, understanding that while you may have more than one job, those jobs may contain the exact same Virtual machine. I really don't understand why if I have backups of the exact same VMs in identical jobs other than the name of the backup is the same, why I cannot use that as a seed for the backup copy task.

[Gostev]

Hi Jim, we are planning to support more backup copy seeding scenarios in v8, however using reversed incremental backup chains for this purpose is one thing we decided not to do due to all the complexity involved. Thank you for your feedback!

[krismason]

Hi All,

I am running a backup copy at our source location to seed a backup to our data centre (9TBish)

This 'seed' is being written to the storage which I am going to reallocate to a data centre when the copy is finished so my backup copy seed source is the same as my target backup copy repository.

My source network is .1 and my target network is .55 so I will have to change the IP on my storage device once the copy has finished.

My plan is
- Run a 'seed' copy backup (which il refer to as D) to a storage device on .1 network locally
- Physically rellocate storage device repository and change IP from .1 to .55 network (.55 is network at remote location)
- Add backup repository for seeded Copy using its .55
- Repoint backup copy job from repository on .1 to newly mapped .55

I have already got a Veeam WAN accelerator at .1 and .55 which I will also modify the job to use.

I have referred to this article (http://www.veeam.com/kb1856) however this is when you copy your seed to a different storage device I am using the same device but will need to change the IP so I assume it is effectively going to be recognised by veeam as a new device? I am however aware that there is a complex algorithm for backup copies

Will this work?

Cheers

Kris

[foggy]

Kris, given all the steps outlined in the KB article are performed, your scenario should work. Please also review the existing thread discussing the seeding procedure.

[krismason]

This didnt work. I have spent nearly 2 days on this and the backup copy has a schedule to run daily at 5pm (seems to be the most infrequent I can set it too)

The job ran 4/15 VM's of mine seeded and wan accelerated after I physically relocated the gear to our data centre today.. about 1/10 TB as I only currently have a 20MB link to my data centre.

The job schedule kicked in and now I have 1 full and 2 incrementals.. If you change anything on the job it has to restart anyway so I couldnt change the schedule... and it was running so well now it doesnt seem to be running wan accelerated and just a normal copy..

Issue is I have lost my clean 'seed' source as my seed and target are one in the same I just re-ip'd and as backup copy doesnt parallel process my seed backup copy took over 14 hours... any idea how I can repoint it back to the seed again??

[krismason]

ive even throught to seed by running 15 backup copy jobs (1 per VM) so I have parallel processing..... ive just checked and its now running basically with 2.8x vs 999x before the 5pm scheduele..

[foggy]

Kris, I'm a bit confused by your posts. Basically all you have to do to seed a backup copy job, is create a first full run locally at the source site, copy it to the new repository in remote site, rescan the repository, and map your backup copy job to it. If you need assistance with this process, feel free to contact technical support and ask them for remote WebEx session.

[krismason]

Foggy your misunderstanding me - sorry

The backup copy has a time interval on it minute, hour or daily ( I had it set to run once daily at 5pm )

My seed had been all loaded I followed all of this process however what occurred it that my first copy run after seed failed as the schedule kicked in and restarted the sync which created a 2nd incremental point in time which means that my seed was no longer being referenced as it seems that when you seed it can only reference the original VBK if you follow if this doesn't complete and the scheduled backup copy kicks in it will interrupt your digests sync and starts a regular unseeded backup copy to a new incremental file - my question was - is there anyway to disregard these 2 incrementals so I can repoint to my original seeded VBK..

To further clarify this it seems the longest you can set this to is to run every 100 hours so if your first back copy post seeding doesn't finish in 100 hours your seed will be disregarded for that data

[krismason]

The error which on failure was " Incremental copy was not processed during the copy interval "

I have since changed my copy interval to 100 days which I will change after the first succesful post seed backup copy (which I am expecting to take more than 24 hours )

[veremin]

it seems that when you seed it can only reference the original VBK if you follow if this doesn't complete and the scheduled backup copy kicks in it will interrupt your digests sync and starts a regular unseeded backup copy to a new incremental file

I’m wondering whether it’s your understanding or you’re actually seeing the full restore point being transferred. I’m asking, since even if you map a backup copy job to a chain with increments, only differences should be transferred, not the image as a whole.

Thanks.