So far the method for seeding off-site backups (or backup copies) is to run the job locally, transport the file to the other site/repository, re-map the job then wait whilst it calculates digests etc. and for large backups/vms this can be a time-consuming process.
Wouldn't it be useful if Veeam could actually "wizardise" the process so that it controls every aspect of the task, including perhaps creating some sort of checksum or similar for the final file being transported, such that the whole calculating digests process would no longer be required as it can guarantee that the contents of the file haven't changed?
I'll add that I'm no expert in such matters, just someone that finds myself occasionally needing the functionality so would love for it to be quicker
Hi Paul, not sure if it is applicable in your case, but there's a way to avoid jobs re-mapping (and hence digests calculation) if you just keep the repository itself moving it to remote site and changing the underlying IP (only DNS update will be required to switch and continue).
Yeah that certainly makes sense if moving the whole repository but I'm talking in cases of re-seeding jobs across already-existing sites/repos.
Whilst I'm talking about it, it'd be REALLY useful to be able to seed just a single VM (into an existing per-vm backup job) e.g. if bringing into scope a large VM not previously covered by Veeam (let's assume we've just P2V'd a physical for example) I'm not aware of any way that you can introduce that server into an existing backup job other than re-seeding the whole job?
Not a regular occurrence by any stretch but the whole seeding thing I think could do with some TLC from the coding genius's at Veeam
Hmm, I think I recall seeing that topic referenced before. I'll have to take another look when I've had some fresh coffee - bookmarked for later perusal, thanks
