Selective Evacuation....

[SyNtAxx]

Is there a way to evacuate selectively a single but entire backup job that is configured as a 'per vm chain' on a SOBR? I need to relocate some data. Previously I'd just remove the backup from the config/db and manually move/map the files. i want to do this with out having to execute a new full cycle and per vm chain has complicated that. Is there anyway to do it? Thanks.

[Shestakov]

Hello,
Could you elaborate on the goal please?
Do you want to change the destination from the current SOBR to another repository without making a full backup?
Thanks!

[SyNtAxx]

Correct. Is the process the same as if I hadnt used a SOBR and per vm chains ?

[Shestakov]

Yes, it`s pretty much the same. Note that if you want to switch type of repository from per-VM to regular, you need to manually perform an Active full run.
Thanks!

[Gostev]

Nikita, did you confirm with the devs before posting? I was not sure if you can move files within SOBR as it will lose track of those... but thinking more about this, perhaps doing Rescan after the move will find them again (just need a confirmation). Thanks!

[Shestakov]

Yes I did.
There is a number of scenarios, like move backups between extents, exclude 1 extent, move from 1 SOBR to another, move from SOBR to standalone +per-VM/regular repo variations. All these backup migration types are possible.

[Gostev]

OK, good to know - thanks!

[dellock6]

We had with Misha this exact use case when presenting SOBR: you can move freely backup files among extents, and the rescan option (or even the infrastructure scan scheduled task) will re-align all the informations.

[michaelryancook]

Should the vbm be left in the original location?

[foggy]

VBM file should exist on every extent, so if you're moving backups to an empty repository, copy VBM there as well.

[michaelryancook]

What would you suggest if I was moving a subset of files from an extent? Leave the vbm? Or is moving some of the files not supported?

[EugeneK]

The files you move around should be the full chain aka all dependent files for the particular chain should be moved to the same extent, if data locality policy is selected. For performance policy, the use case may be different - incrementals can be placed on a different extent, while Fulls are on slower storage tier.

[veremin]

In either case if you're migrating some files to blank extent, be aware to copy .vbm file there as well.

[pirx]

I want to bring up this old thread. My use case is to move some backup chains from a large SOBR extent that is getting full. Using Robocopy etc I do not trust (no checksum by default, and I've to take care that nothing is using the backup files). Evacuate is taking a very long time as this is our BJC CIFS repo with spinning disks. Instead of moving the whole data, it would be much easier if I could select a backup job/chain with just a couple of TB and move it a different extent of my choice. This is something that is really missing in my opinion.

[veremin]

Thank you for the feedback - your request has been noted.

[768kb]

An additional Question to moving files around: If I want to copy files of two SOBR extents to one new bigger extent, I have two vbm files which I cannot merge. How do I handle this? manually edit the vbm? Delete both? Will a Rescan recreate a vbm?

[PetrM]

Hi Jan,

No, you must not delete .vbm because our rescan will not be able to detect a backup. The .vbm file contains full description of the backup chain, Veeam updates configuration database based on information from .vbm during rescan. You should use evacuate backups option but I'm not sure that I understand the purpose, why don't simply add a bigger extent to the existing SOBR?

Thanks!

[768kb]

Good morning Petr; I use(d) the evacuate function; while it evacuates, I see not a lot of disk traffic on the destination. The traffic spikes up for 1-2 seconds, goes to zero for 3-5 seconds, and spikes up again. If I copy the files manually using scp, I have good and constant speed. I don't know why evacuate takes this much time, and it would be great to analyze this with support. But our source storage system has a problem and we must evacuate as fast as possible. This is why I want to do it manually.

Now my question still remains: How do I merge a vbm from two sources without the evacuate function? Is it even possible?

[PetrM]

Hi Jan,

Yes, it's a definitely good idea to clarify the issue with our support team. It's not possible to merge 2 .vbm files into a single one and I'd rather use evacuate than move some files manually as our configuration database remains synchronized with the file system state when you use evacuate option.

Thanks!

[768kb]

I have now checked it by myself: if you have a Backup Job which used two or more extents of a SOBR, there's a folder with the backup Job name in both extents. In each extent's folder is a VBM file, which was my question how to merge them together. The answer should be: they are both the same, you can just delete one and keep the other. I compared both files, they contain files of all extents and are identical. Sometimes, they just differ in minutes and have 1-2 new files difference - where I keep the newer one.

Cloud someone from Veeam tell me, if I am right, or why this is not a good idea?

For PetrM: I cannot use evacuate because I have to move contents of 6 extens to 4 new extents, one after another. I cannot put all into maintenance mode at the same time, because evacuating one extent takes more than 24h. And if so, "evacuate" will put the files on the old extents instead of the new ones until the are in maintenenace mode too.

[PetrM]

Hi Jan,

Thanks for clarifications. I still have a lot of doubts regarding manual deletion of .vbm. That's true, each extent has an identical copy of .vbm but the fact that it worked in your case does not prove that the same approach can be safely used in another case. Also, such manual operations increase the likelihood of user's mistake and therefore can provoke different problems. That's why I'm convicted that Evacuate option is a right way to go. I would consider such a long lasting evacuation as a technical issue which must be investigated by our support team.

Thanks!

[768kb]

After manually moving files from one repository to another in my SOBR, I had a Veeam support case to clarify everything is still in sync in the database. And it is!

For my own *.vbm question: The VBM File must always be the same on all extents. So in fact, you can overwrite one with another or just throw the old into trash.

After moving all the data around, just do a SOBR rescan and Veeam will search all needed files over all known SOBR extents. If the file is found anywhere, it is remapped and everything works fine.

Hope this helps someone.

[PetrM]

Hello Jan,

Thanks for sharing the results! Glad to hear that everything is working fine in your case. However, I'm still convicted that it's better to avoid manual actions with .vbm files without confirmation of our support engineers. The .vbm contains the full description of an entire backup chain and it might be challenging to identify the most actual metadata file across all extents.

Thanks!

[768kb]

If anyone wonders, this can also be found in Veeams KB: https://www.veeam.com/kb3100

[lowlander]

Hi,

is this also possible when using a SOBR with capacity tier ?

As I understand the KB article extent names should be identical.

For example when having 3 drives : D:\ E:\ and F:\ the extent names should be named :

D:\performance-extent
E:\performance-extent
F:\performance-extent

and not

D:\performance-extent-1
E:\performance-extent-2
F:\performance-extent-3

Correct ?

Regarding ReFS, am I correct that when retention passes time, new incremental and synthetic full back-ups will benefit from ReFS while older back-ups fall out of the back-up chain ?