Move backups within the same SOBR

[perjonsson1960]

Folks,

We have a SOBR that now consists of three extents. One of them is an old extent that will eventually be removed from the SOBR, and the other two are new extents in a new server. Previously we have already evacuated three other "old" extents to the new server. However, we don't want to evacuate the last "old" extent because there is a large GFS chain of approx. 270 TB on it, and it will take about nine days to move it to the new location, during which time we cannot do any new backups of that server, since the extent then would be in Maintenance Mode.

On that "old" extent are also 60-ish VMs created by a few different jobs. Most of the VMs backed up by those jobs are already on the new extents due to the previous evacuations. How do I move the remaining 60-ish backups to the new extents, and thus leaving only the large 270 TB GFS chain on the only remaining "old" extent?

When the 60-ish VMs have all been moved to the new extents, we are going to seal the last "old" extent, and perform an active full backup of the server owning the large GFS chain. The full backup, approx. 24 TB, will hopefully have time to finish in two days, over a weekend.

Bottom line: How do I move backups of invividual VMs from one extent to another within the same SOBR, and let the backup jobs know that some of its VMs have been moved?

We are running VBR v11, we are using per-machine backups, and the SOBR is configured for Data Locality, so all the backup files for a certain VM are on the same extent.

Kind regards,
PJ

[Mildur]

Hi PJ

The procedure is documented in our user guide. You will loose Fast Clone space savings with this procedure.
https://www.veeam.com/kb3100

For Local SOBR:
1. Stop and Disable the job associated with the backup files you will be moving.

2. Move backup files between extents as needed.
Keeping in mind the details above about folder paths and vbm placement.

3.In the Veeam Console, under Backup infrastructure > Scale-out Repositories, right-click on the affected SOBR, and select Rescan.
rescan sobr

4. Enable/run the job.

Best,
Fabian

[perjonsson1960]

Fabian,

Thank you! This seems to be a fairly simple and straightforward operation.

PJ

[perjonsson1960]

As I understand it, if I move backups manually from one extent to another, I lose the benefit of dedupe and Fast Clone, right?
Will that correct itself automagically over time even when only synthetic fulls are used, or do I have to do an Active Full or some other measure?

[Mildur]

if I move backups manually from one extent to another, I lose the benefit of dedupe and Fast Clone, right?

Right.

Will that correct itself automagically over time even when only synthetic fulls are used, or do I have to do an Active Full or some other measure?

To enable FastClone, you must run an active full backup or backup file compaction operation for the affected backup jobs.

https://helpcenter.veeam.com/docs/backu ... ml?ver=120

After you have enabled Fast Clone for existing repositories as described in the previous paragraph or have manually moved backup chains to backup repositories with Fast Clone support, you must create active full backups for backup chains stored in / moved to the repositories to activate Fast Clone. You can also schedule the backup file compact operation instead of performing active full backup.

Best,
Fabian

[perjonsson1960]

And how do I do a defrag and compact manually? As far as I know, that option is disabled when synthetic fulls are created periodically.

[Mildur]

Unfortunately, there is no manual command for it. Run an active full backup instead.

Please note, the active full backup won't bring existing VBKs in a FastClone enabled file.
It just allows you to write new synthetic full backups FastClone aware.

Best,
Fabian

[perjonsson1960]

Thank you!
If I set a job to create a synthetic full and an active full on the same weekday, will the active full take precedence, or will the job do both?

Edit: Never mind, I guess I can just disable the synthetic full, and enable the active full, on the same weekday. And then change back when the active full has been done.

[Mildur]

Active Full has a higher priority than synthetic full. Therefore Active Full backup would run on that day.

Best,
Fabian

[perjonsson1960]

Thank you!

[perjonsson1960]

We are using NAS/File share backups. It seems that VBR has scattered at least metadata on all four previous extents that we had in the SOBR.
We have now evacuated three of the extents to a new repo server, but not the fourth extent, which we instead are going to seal. The NAS backup folders have been removed from the first three extents during the evacuation process, but they still exist in the fourth extent. The "data" folder is empty, but there is metadata there. I renamed the NAS backup folders, and tried to do a restore, but then it complained about that it could not find the metadata, and aborted the restore. When I renamed the folders back again, the restore worked.

How do I get rid of that problem? Can I simply rename/remove the NAS folders and do a rescan of the SOBR, as I did when I moved the regular backups manually from the same extent?

PJ

[perjonsson1960]

If I don't get a fairly simple solution to this, then I will have to delete all the primary file share backups, seal the extent, and then start over with new full backups. We still have the backup copies on a different SOBR. By the way, in this case, can I use the same backup jobs after I have deleted the backups? And what happens to the backup copies then? Will it continue to build on the existing copies, or do I have to create completely new jobs altogether in order to keep the existing copies?

[Mildur]

Hi PJ

Let me run a short check in my lab.
I'll get back to you.

Best,
Fabian

[Mildur]

Hi Per

I run a Extend Evacuation with just NAS backup files on the extend. Backup data and metadata was moved by it to another extend.
Did you let Veeam evacuate the NAS backups or was it a manual move with windows explorer?

Best,
Fabian

[perjonsson1960]

Veeam evacuated the first three extents, no manual moves from those.
The fourth and last extent in the old servers has not been evacuated. It contains a large GFS chain with 280 TB data, and the NAS-backup folders that seem to contain only metadata. That is all there is left on that extent.

[Mildur]

Thank you.
I suggest to open a support case and let them recommend the best way to migrate or remove that metadata.

Best,
Fabian

[perjonsson1960]

Case #06033582