Import VeeamZip from SMB/CIFS share

[sethrandall]

As part of decommissioning our Data Domain, I am trying to move our VeeamZip backups to an SMB/CIFS share on our new ExaGrid. The share is set up and new VeeamZip files are going there. I have copied an old VeeamZip over and I cannot get it to import. I have tried rescanning the share and it doesn't find it. I have tried using the Import function and can see no way to select the share to Import.

How can I easily import these files?

Support helped me get 1 imported using the Import Backup tool, but I have 40+ VeeamZIPs across multiple sites and doing it manually would be arduous. A rescan of the CIFS share doesn't work because rescan only looks for vmb files. I asked why the scan doesn't grab vbk files as well and was told to post here with my case number for a response (so as to help others).

(I honestly don't understand why I can just right click on a bunch of VeeamZIPs and say "Move to another repository")

Case #05435720

[PetrM]

Hi Seth,

Basically, import by .vbk is a spare plan when .vbm is not available, for example it is lost or corrupted. Rescan works with .vbm files only because these files contain the serialized xml-description of the entire backup chain consisting of all files created by the backup job including increments .vib or .vrb. Thus, rescan can easily synchronize information about backups in database with the actual state of the file system.

I think "Move to another repository" for VeeamZIPs could be considered as a feature request, however we don't have a lot of similar requests so far. As usually, I cannot provide ETA but your feedback is much appreciated!

Thanks!

[veremin]

We have some cool feature scheduled for the next major product release (v12) that besides many great things should address and your case. Thanks!

[sethrandall]

Petr,
Out of curiosity, why aren't VeeamZIP files created as .vbm files in the first place? Couldn't they also contain a (presumably simple) xml-description that would allow rescan. It seems that having two separate formats would just mean more work for developers and more complicated code paths and feature requirements.

[PetrM]

Hi Seth,

The different formats solve different problems: .vbm contains backup chain metadata needed for rescan and .vbk is a container which is used to store actual data of full backup or VeeamZIP. Actually, it would be much more complicated to redesign the whole data storage architecture than to stick with the current one that exists many years already. Also, the usage of the shared format could provoke a lot of "corner cases" that will require extra attention from our quality control team.

In fact, your idea about storing xml-description inside backup itself is absolutely valid from technical point of view. Moreover, .vbk files created in forward incremental mode already contain the description of dependent increments and this information is used during import by .vbk. In theory, it is possible to teach rescan to open every .vbk but we consider import by .vbk as a workaround when .vbm is unavailable. In the vast majority of cases, there are no issues with .vbm and I guess the best action plan for you is to wait for the v12 release which should address your case thanks to the feature mentioned by Vladimir.

Thanks!