VeeaMover limitations

[DanielJ]

Feature request: to let VeeaMover move any backup from anywhere to anywhere. It's great that the function exists but its current limitations is giving me headaches. I have some backups in "vCD legacy backup copy" format on a StoreOnce, which I'm stuck with since they have GFS backups that won't expire until the mid 2030's, and it seems my only option for moving them is through the Files view, copy/pasting them to another repository - NOT the new Catalyst store where I would like them to be, but only to other types of repositories (linux). And since it's not VeeaMover moving them, but a simple copy function, they will be redryhated if I do that. Right? I want to move them from an old Catalyst store to a new one, since the new store has fixed block chunking enabled, and the current copy jobs are going to that store. Moving the old backups for the same vm's to that store will let me benefit from deduplication which is within each store only.

While I'm requesting things, let me also add that I would have great use for the possibility to merge backups into a single chain. This is for the same backups as mentioned above. Things like backup chain format upgrades and the introduction of features like fixed block chunking have left me with scattered backups which is a hassle for many reasons (including billing), and so much worse when GFS backups of 10 years or more are involved. Please let me build a single backup from these scattered pieces and move it to where it makes the most sense to keep it.

[Mildur]

Hi Daniel

but a simple copy function, they will be redryhated if I do that. Right?

If you use the files node to manually copy the backups, then it will be rehydrated. But our VeeaMover's "Copy" option is FastClone aware when the target has FastClone support. This means that we only need to copy and write unique blocks from the source to the target repository, without having to rehydrated backups. However, it's important to note that the copied backups will not retain the original retention policy. You can choose to specify a new retention policy, but it will be applied to all copied restore points.

Please let me build a single backup from these scattered pieces and move it to where it makes the most sense to keep it.

This type of move is already possible if you have backup files with "per-machine backups with separate metadata". However, I understand that you do not have this for the old backup chains.

Thank you for your request. I cannot guarantee that this will be implemented in the product. Partners/customers with long-term archive backups on disk may need to transfer such old backups to new hardware only every 4-5 years. Nevertheless, it has been noted as an improvement request. We will need to monitor the number of requests we receive for it.

Best,
Fabian

[DanielJ]

But our VeeaMover's "Copy" option is FastClone aware when the target has FastClone support. This means that we only need to copy and write unique blocks from the source to the target repository, without having to rehydrated backups. However, it's important to note that the copied backups will not retain the original retention policy. You can choose to specify a new retention policy, but it will be applied to all copied restore points.

I know this and I wish I could use VeeaMover for the scenario I described, and others.

This type of move is already possible if you have backup files with "per-machine backups with separate metadata". However, I understand that you do not have this for the old backup chains.

That's right, I don't, because Veeam made the arbitrary decision not to allow converting these backup chains to the new format. As I see it, it's all just a bunch of vbk's, which we know is portable, so there should be no technical reason those chains could not be converted (and then merged).

But since you say it's possible to merge chains as long as they are in the new format, can you describe how to do it? I thought it involved unsupported vbm editing (which I would also be interested in learning the mysteries of). It would at least solve parts of my problems.

[Mildur]

But since you say it's possible to merge chains as long as they are in the new format, can you describe how to do it? I thought it involved unsupported vbm editing (which I would also be interested in learning the mysteries of). It would at least solve parts of my problems.

You can move backups to another job/copy job:
https://helpcenter.veeam.com/docs/backu ... nother-job

Backup chains from the source job will be moved to the new location and attached to the target job. We just move the metadata file from each machine together with the backup files. No need to manually "hack" source VBM files. This is possible because each machine has it's own metadata file.

Best,
Fabian

[DanielJ]

Attaching the old chains to new temporary jobs and then move the backups between the jobs hadn't struck me, but that will work.Thanks for the tip.

[DanielJ]

Well, that didn't work. "Error: Unable to move Cloud Director vApp backups which are not assigned to a job". They most certainly are assigned to jobs (copy jobs), and both the old and new backups are in "Image level" format. There seems to be some unknown caveat with vCD backups (I think I experienced that once or twice before).