Seeding a backup (not replication)

[sk40]

I just want to make sure I am not missing anything for seeding a remote repository:

1) Create job and target local repository
2) Run Job
3) Connect to and install the remote repository
4) Copy and "sneaker net" the backup data to the remote repository
5) Rescan remote repository, locating the copied job
6) Delete the local backup data (to remove confusion)
7) Edit the job targeting the remote repository and map the backup
Run the job and verify that only changes are sent to the repository

Have I missed any steps here or other things I need to be considering?

[Gostev]

Looks good to me! Thanks.

[bmcchesney-nv]

[merged]

Hello,

I've had a good search - perhaps I don't know the correct terminology in Veeam for what I'm looking for - but can anyone tell me if Veeam supports seeding for backups?

I'm talking here about having two sites (A and B) with a backup repository each. The local repositories serve as the first point of recovery for their respective sites. However, I want to 'replicate' or copy these backups across the WAN, so that A's backup repository has a copy of B's backups and vice versa. It's definitely not replication of the VMs that we're after, as we need recovery points in case the damage was n recovery points ago. (As this is D2D2D I'm using incremental forward forever.)

Copying from scratch is out of the question. The data at site A is nearly 1TB and we have a 1Mbps upload speed, so that would be nearly 102 days? Changes every day are small, so if I could seed it would be ideal.

Is this possible? I've not seen a way. Even if it involves a hack I'd be very happy. e.g. Backup from site A to repository A. Disable backup job. Copy the backup from repository A to an external drive. Delete from A. Physically transport. Copy to repository B. Hack the job file on A so that it points to repository B. Resume backup job. Veeam would be 'fooled' into continuing the incrementals where it left off. Voila.

I really hope this is possible. Can anyone please help?

Regards,
Bob

[Vitaliy S.]

Hi Bob,

Yes, that's possible, no need to perform any hacks Please review the procedure you need to follow in the post above.

Thanks!

[bmcchesney-nv]

Hello,

Excellent, and thanks for the fast response. Procedure makes sense and looks very easy. I will report back to confirm how I get on.

Bob

[sdelacruz]

Can we do this process for a replication job? I started a replication job for a 200 GB server sending the replica on a WAN 20 MB fiber connection to my DR site and it has been more than 3 days. I am currently at 70% but I have not been able to run regular daily backups on this VM since its being used by the replica job.
I really liked the feature on the older versions of veeam where it would let you copy the startup copy to a removable drive, then physically move that and restore on DR site then start replication. I did not see this feature on v 6.1 Enterprise of veeam.

I need to also send I replica of an 800 GB server, but I cannot wait that long without backing it up.

Thanks

SAM

[Vitaliy S.]

Hi Sam,

Yes, you can perform initial seeding for replication jobs too, see this topic for further instructions: v6 Offsite Replication : Seeding How To

Thanks!

[sdelacruz]

Tahnk you very much Vitaliy for your fast response. I will do this on my next VM server.

[bmcchesney-nv]

Worked exactly as you described. Thank you very much.

Bob

[rawtaz]

Hi,

I've read the initial post in this thread, but something isn't clear to me. Short elaboration:

- I have a local Linux backup repository on which I store the backups for two jobs (the second running after the first).
- I'm setting up an offsite Linux repository as well, and want to seed it.
- I'm running B&R 6.5p3, and the jobs are reverse incremental only.

In summary, the instructions suggest to create a new job (for the offsite backup) and putting it initially on the local repository. Then running it and copying the backup files from the local to the remote repository, and finally changing the job to point to the remote repository.

However, this requires that I perform a full backup of my VMs locally, in order to create the seed backup files. I am wondering if I can instead copy the already existing backup files (for the two jobs I already have, on the local repository) to the remote repository, and then set up a/the new job (for the offsite backup) directly targeting the remote repository (without Veeam needing to read the backup data on the remote repository back (to scan it or whatever), as that would take a looong time)?

The purpose of doing what I ask about above is in part to have the history of the local backups (that's been running a while) in the offsite repo as well, and also to avoid having to do a full backup of everything again.

Please let me know if anything is unclear. Thank you!

[Vitaliy S.]

Hi,

I am wondering if I can instead copy the already existing backup files (for the two jobs I already have, on the local repository) to the remote repository, and then set up a/the new job (for the offsite backup) directly targeting the remote repository (without Veeam needing to read the backup data on the remote repository back (to scan it or whatever), as that would take a looong time)?

Yes, you can re-use existing backup files, just setup the new job and map it to the copied backup files.

Thanks!

[rawtaz]

Hi, Yes, you can re-use existing backup files, just setup the new job and map it to the copied backup files.

Thanks!

Sweet!

Should I rename the backup files and/or folders after copying them and before pointing the new job to them/the repo?
The folder is named e.g. "linux1" and the files in it "linux1*", and the new job will be e.g. "linux2".

[Vitaliy S.]

There is no need to rename the backup files, everything should work with the same file names.

[rawtaz]

There is no need to rename the backup files, everything should work with the same file names.

If the files are not renamed automatically, can I do it manually without issues? I simply don't want to have backup files that are named differently than the job they correspond to.

[Vitaliy S.]

Yes, I believe you can, at least I do not see how it can affect your new job.

[rawtaz]

I see. Then let's try it! I was just thinking that there might be some occurence of the backup job name in the files' contents as well, and that it might be unhappy if I renamed the files. Thanks!

EDIT: I see now that there is metadata in the .vbm file, referencing the backup name and files. That one probably need to be edited, unless of course it's kept up to date by Veeam.

[tuscani]

One of clients has VEEAM setup and does a backup of a single VM locally. We want to create a second job that replicates back to our data center as well. I seeded the backup, created a new job, yet the job still tries to do a full backup over the the WAN.. what am I missing?

Here are the steps I followed:

1) Create new job and target local repository to USB drive
2) Run Job
3) Connect to and install the remote repository
4) Copy and "sneaker net" the backup data to the remote repository
5) Rescan remote repository, locating the copied job)
6) Edit the new job targeting the remote repository and map the backup
7) Run Job

[foggy]

Justin, if you followed the given instructions, the job should perform incremental run. Have you selected the Low bandwidth connection check box in the job properties and mapped the job to the seed?

[tuscani]

This isn't a replication job (job is a backup) so I do not believe there is a low bandwidth option.. I have WAN selected for storage optimazation and yes I did map the backup.

[foggy]

Yep, sorry for confusion. The mapping feature for the backup job is at the Storage step of the wizard.

Anyway, if the provided instructions do not work, you may ask support for assistance in setting this up. Btw, what makes you think that the job performs full backup?

[tuscani]

Ok thanks.. What you mean about the the job performing a full backup?

I don't think I ever said it would.

I may just hold off until v7 releases as that seems more friendly for WAN targets and creating jobs for DR sites.

[veremin]

Based on my understanding, Alexander was asking about this sentence:

yet the job still tries to do a full backup over the the WAN

So, the question was what made you think that it was a full backup, indeed, that was performed. Thanks.

[tuscani]

Because the job was running 20+ hours and was much larger than other incrementals already present

[foggy]

Taking a look at the job log would most likely point out the reason of large increment so I suggest contacting support.

[veremin]

Because the job was running 20+ hours and was much larger than other incrementals already present.

Additionally, it stands to reason to check corresponding job statistics and confirm whether CBT was used or not. In case it wasn’t, VB&R definitely tried to read the whole VM image and see what blocks had changed since the last backup run. This, in its turn, might take some time, even 20+ hours, providing it's a big VM.

Thanks.

[nurbi76]

Hi,
I have a question about a way to do an initial full backup of a site, and move this datas to another destination.
I want to configure a multi-site backup, where the repository is on the Head Quarter A, and on sites B and C there are olnly backup proxies (with destination A).
Due to a slow WAN connection, I want to do the initial backup of B and C on a little NAS, or local esternal disk; then I want to take this full backup and move to central repository manually.
After have done this steps, is sufficient to change the path of the backup job to the new location? Next run of the periferical job, it will be an incremental backup using the datas transported?
Is there another efficient way to the first full backup without having to wait long time due to network limitation?

Thank you

bye

nick

[veremin]

Hi, Nick,

The procedure should look like this:

• Perform initial full backup locally
• Transfer resulting .vbk file to remote location
• Re-scan remote repository
• Change repository in the settings of backup job
• Map backup job

Thanks.

[nurbi76]

thanks eremin,
I was thinking about this procedure. Just to have confirmation.
Bye

nick

[danielchung]

In the offsite backup job, remember to add the target VM from the host or the vcenter which is the same setting in the local backup job. Otherwise the offsite job will take the VM as the a new one and will not use the seeded vbk, even the actual VM is the same one.

That's what I experienced in previous version, but I think it should be the same in v7.

[foggy]

In the offsite backup job, remember to add the target VM from the host or the vcenter which is the same setting in the local backup job. Otherwise the offsite job will take the VM as the a new one and will not use the seeded vbk, even the actual VM is the same one.

Yep, this is due to the fact that backup job mapping is performed with the help of VM ID, assigned by vCenter.