Apologize as my Spanish is minimal.  I would think that you would be able to have a repository at whatever location you’re targeting and then should be able to create a backup copy job to that location and use that backup copy as a seed.  If that is not an option and you need to physically transport the data, I would take a full backup of the VM in question, physically move the VBK to the repository at the target location, and then rescan the repository.  Once you have the VM showing as a restore point in the repository at the target location, I would think you should be able to use that as seed data for the replica.  Let me know if that works for you as I haven’t tried this but I’m not sure that I see why it wouldn’t work.

Why not using Quick Migration to move VMs?

https://helpcenter.veeam.com/docs/backup/vsphere/quick_migration.html?ver=110
(WARNING: pay attention to check box in wizard for delete origin vm after migration if needed or not)

Just to add some infos (maybe unnecessary): after migration, Veeam see VMs on new host with a different ID and you need space for a full backup on backup repositories. That can be your seed for future incremental as @dloseke said rescanning repository after physically move that backup repository.

This is a good idea.  My concern is that if it takes a LONG time to copy it across whatever link is there, then a Quick Migration may end up with a large snapshot to commit at the end when it’s done (assuming that the source VM isn’t deleted which I think would be the case since the OP is trying to create a replica). 

With a backup copy job, it may take a long time for the copy to complete, but at least the source VM would be unaffected.  Physical copy is going to be more work intensive, but probably faster.

Maybe I’m wrong, but with a quick migration isn’t time halved instead backup copy job/restore?
It’s an interesting topic @dloseke :)

That’s an interesting thought.  I guess I haven’t used QuickMigration enough to tell if there would be a difference between that and a copy job.  At least with the copy job there should be no restore as it can just us the backup repo for seed data.  I actually do that quite often if I have copy jobs targeting the same location as replica’s.  That said, I suspect the WAN link or whatever is going to be the major contributing factor.  I’m not sure what kind of compression is available with QuickMigration.  Perhaps something interesting to test out….you know….in my “free time”.  And by free time, I mean when I should probably be sleeping.  :-)

@CesarTAC @marcofabbri @dloseke  I am moving this content to VUG Spain. 

@Madi.Cristil ¡Claro! 

@HunterLF 

Hola, me habéis pillado en vacaciones!

esto hace mucho tiempo lo hice, pero vamos a hablar de manera teórica:

Yo lo que haría sería tomar un full de una máquina, y llevarlo a un repositorio en el sitio remoto, una vez allí, configurar la tarea para tener los increméntales a partir de ese full.

una vez todo probado, restaurar un backup de la máquina origen en el nuevo destino.

la teoría es muy buena, vas a tener downtime, ya que deberás apagar el origen, y restaurar el destino (tiempo de restauración).

Haz una prueba con una máquina pequeña, para que veas tiempos y configuraciones, y puedas “estimar” tiempos y procedimientos.

echa un ojo a este kb donde tienes el proceso de cambio de repositorio de backups y re encadenado de tareas, es un in viejo, pero te dará una idea.

https://www.veeam.com/es/kb1729
 

comenta cómo te va!

saludos.

Muchas gracias a todos por su gran ayuda, sus recomendaciones son muy importantes
Saludos desde Perú

Thank you all very much for your great help, your recommendations are very important
Greetings from Peru

Hi @CesarTAC :) Nice to have you in the Veeam Community  There is a VUG Latin America, if you would like to be part of it , in case you have more questions.