Moving Existing Jobs to New Scale-out Repository

[Stokkolm]

What is the best way to move existing backup files to a new Scale-out repository? I tried simply moving the backup files to one of the volumes in the scale-out repository and then pointing the old job to the scale-out repository, but it would not properly locate the old backup files. I kept getting an error message telling me to first move all of the backup files to the new repository. I decided to just recreate the job for times sake today, but is there documentation or a suggestion on moving old backups to a new scale-out repo?

[nielsengelen]

You can just add your excisting repositories to a scale out repository and everything will be done for you (changing job targets). Do keep in mind that if you are saving rhe backup configuration on your repo you will need to add a seperate repo for this (for example d:\backupconfiguration) as this is currently not supported. Also if you want to benefit from the per-vm backup chain you will need to run an active full on each job (unless this was already configured on the original repo).

[Stokkolm]

You can just add your excisting repositories to a scale out repository and everything will be done for you (changing job targets).

That worked fine for the jobs that were targeted at repositories that I added to the scale-out repository, but what about for jobs that are targeted at other repositories (repositories that aren't going to be added to the scale-out repo) that I now want to move to the scale-out repository. As I said, I tried just copying the backup files and then pointing the existing job at the scale-out repository, but it wouldn't recognize that the backup files existed on the scale-out repository.

[foggy]

So you want to move the backup files from the repository to another scale-out one, without placing the repository itself into scale-out as an extent, right?

[Stokkolm]

Yeah, basically I have two storage platforms, EqualLogic and Synology. Some of the jobs that are targeted at Synology volumes are taking an unacceptably long time to merge once the backups complete (I'm talking some in the range of 30+ hours). I'd like to move them over to the EqualLogic arrays, but I just created a Scale-out repo that encompasses all of the EqualLogic volumes. In the past I've been able to just copy the backup files to the new volume and adjust the backup target repository within the existing backup job. I tried this with the scale-out repo and it doesn't recognize that the backup files exist.

[foggy]

Got it. So you've performed the standard procedure for moving backups to a new repository and it doesn't work? I need to check whether it is supposed to...

[Stokkolm]

That's correct.

[EugeneK]

The standard procedure should work, we migrated files around using it, when the new SOBR was introduced by a few of our clients into existent environments.
https://www.veeam.com/kb1729
When you rescan the repository, does it pick up the old job files that you just moved? It'd show as "Disk(imported)".
If so, when you edit the job settings to point it to the new repository, the software validates the presence of Backup files at the new location.
I'd recommend to make sure the path selected to files is correct - can it be that the SOBR repo is mounted to a different path than the files were copied to?

[Stokkolm]

The standard procedure should work, we migrated files around using it, when the new SOBR was introduced by a few of our clients into existent environments.
I'd recommend to make sure the path selected to files is correct - can it be that the SOBR repo is mounted to a different path than the files were copied to?

How would I know the path that the SOBR repo is mounted to? I definitely placed it in the mapped path of one of the volumes within the SOBR repo, for example "E:\Backups".

[foggy]

If you've copied the files into the folder that is one level down the path used by one of the extents, it should be ok. For example, if the extent points to E:\Backups, then folder containing the backup files for the migrated job should be copied there: E:\Backups\Job1.

[Stokkolm]

If you've copied the files into the folder that is one level down the path used by one of the extents, it should be ok. For example, if the extent points to E:\Backups, then folder containing the backup files for the migrated job should be copied there: E:\Backups\Job1.

I can confidently say that that does NOT work if you move the backups to only one of the volumes within the SOBR. I'm on version 9.0.0.1491. I've tried moving the files with File Explorer (right click -> copy; right click -> paste) as well as with robocopy. Here are the procedures I used:

The SOBR is made up of three volumes: G:\, H:\, & L:\ and mapped to the "Backups" directory within each.
I also have three stand-alone repositories: I:\Backups, J:\Backups, and K:\Backups.

1. Copy entire backup job directory from I:\Backups\DNS Servers to L:\Backups\DNS Servers. All that exists within the DNS Servers folder are the backup files, there are no nested folders or anything like that.
2. Rescan my SOBR repository. During this process all 3 volumes within the SOBR show "0 added, 0 encrypted, 0 removed, X skipped".
3. Attempt to point existing backup job at SOBR repository. At this point I receive an error message stating: "Move all backup files to the new backup repository first."

I also tried copying the full backup directory to one of the volumes and then adding an empty folder on each of the other volumes, did a rescan again, but got the same results.

I'm guessing that because there are multiple volumes within the SOBR it's not as simple as just moving the backups to one of the volumes and re-scanning anymore probably due to the way the backup files are tracked within the SOBR. I'll open a support ticket if needed, just let me know if I should do that instead of proceeding further on the forums. Thanks!

[foggy]

Yes, please proceed with opening a case, for some reason the copied backups are not detected during rescan.

[pkelly_sts]

I've just skim-read this post & I'm not sure if you're having a fundamental issue with moving backup files to a new location, or if it's because you're moving them into a SOBR location.

If I were looking to achieve the same as you, and assuming the reason you don't want to just add the containing simple repository into the SOBR is because there are perhaps other backups on the same repository that you DON'T want to move to the SOBR, then I would maybe try this approach (though let someone respond first as to whether this is actually a sensible approach!):

Assuming that on your existing repository host you have a repository mounted at E:\Backups.
1. Create a new folder E:\Backups-temp
2. Move the backup files related to the job from E:\Backups to E:\Backups-temp (a move rather than copy should be very quick)
3. Create a new simple repository to your infrastructure, pointing it to E:\Backups-temp (and allow the rescan to see the files you've moved there)
4. Edit the job pointing to the original repository and follow standard procedures "Map" it to its new location
5. Once you know the job is happy with the backup data in its new (temp) location, then you can add that (temp) repository to your SOBR.
6. The backup data should now be migrated into your SOBR and the job should have been automatically updated
7. Now you should be able to put the temp repository into "Maintenance" mode
8. You should now be able to "Evacuate" the temp repository which will automatically re-distribute your backup data
9. Once the repository has been evacuated, you can delete the extent from the SOBR, then you can delete the simple repository

It looks like a reasonable feature-request would be for some kind of process to do the moving of these files for you. Although it generally works, it does feel slightly clunky to me that we have to manually do all the moving, rescanning, re-mapping processes when we want to move things around. It would be great to have the chance to simply right-click on a backup file within the GUI and say "Please move this backup chain to there" and have it just get on with it. It sounds like most of the logic is already written for SOBR migration but would still be useful in more simple scenarios where SOBR perhaps isn't used.

[foggy]

Thanks, Paul! Looks like a viable approach to me. Actually, I've checked with QA and it seems that the standard procedure with simply moving files from a simple repository directly to a SOBR extent doesn't work in all cases due to some limitations SOBR applies to the folder and VBM file naming. So, to comply with these limitations, the job should exist on the extent at the moment it is added to SOBR, otherwise the backups can be skipped during SOBR rescan (which occurs in John's case). In your procedure everything should be smooth.

[pkelly_sts]

...the job should exist on the extent at the moment it is added to SOBR, otherwise the backups can be skipped during SOBR rescan (which occurs in John's case). In your procedure everything should be smooth.

Although this isn't really my use-case I'm still curious but don't understand this part? Do you mean that the simple repository & the job pointing to the files on it should all be in a "consistent state" before you add that extent to the SOBR?

In other words, don't move the files in the background /then/ add the extent to SOBR /then/ re-map the backup? (this approach doesn't' sound the best to me anyway).

[foggy]

I mean that copying the job folder from simple repository to the SOBR extent directly is not the right approach. Instead, you need to "introduce" the job to a SOBR by adding the simple repository where the job is stored to SOBR as an extent (so that SOBR could perform some naming modifications).

[pkelly_sts]

Ah, understood, thanks for clarification.

[electricd7]

We have a large backup job which has been writing to a normal repository. I would like to move this job our scale-out repository. Is it just as simple as find a member of the scale-out with enough space to hold it all and move it and repoint the job? We have our scale-outs set to put incrementals on any member, but in this case I would think I would have to have them all on the same member to be recognized? Any advice?

[foggy]

Not that simple, please review the thread above.

[electricd7]

OK, have added the repo to my scale-out, put it in maintenance mode, and then evacuated the data. I closed the window, so how do I now check the progress of the evacuation to know when it is safe to remove the extent from the scale-out?

[electricd7]

Nevermind...status appears in the History tab under "System".

[rogerdu]

Good morning!

I've copied the latest .vbk file from my main repository (single file, not on a scale out repository) to a Scale Out repository on my remote site... When I rescan the remote site Scale Out repository, it skips 3 files... Then, when I try to map the remote copy to the full, it does not present it as a choice... I can only assume that I have not done something correctly...

Any suggestions?

Roger

[foggy]

Hi Roger, the procedure is a bit more tricky. Please review the thread above.

[rogerdu]

Well... that didn't work...

File System structure and backup repository:


Messages from Repository creation and backup import:


Choices for mapping the backup copy job:

[rogerdu]

Do I make the backup target the new temp repository (that has the .vbk file in it)? as opposed to mapping the backup to the .vbk file?

THEN move the repository into the SOBR. offline, move etc??

Here are my choices when I try to map the backup...

[rogerdu]

It would seem that one needs to do a backup copy from the backups not the backup jobs... RTFM.... /sigh

Thanks for the procedure on page 1.. worked like a charm.

[stevil]

I have a similar conundrum with a new scale-out repo I created. I added three repositories into a SOBR, two of them were new, one of them already has 25TB of backup files in it. All goes well, the jobs are all reconfigured to point to the new SOBR. When I run the job it works, but all the traffic is pointed towards the original BR, the other two new ones are untouched. This is with an incremental and an active full. How do I get the active full to start populating the other repositories in the SOBR?

[dellock6]

This is expected for an incremental to keep using the same extent as long as it has enough space, but an active full should recalculate the best placement. Maybe the existing storage still has the biggest amount of free space even if it's already used? Because free space is the main criteria for the selection as of now.

[stevil]

Thanks for the reply. It seems to be working by design now, I'm wondering if it was a permissions issue on the two new repositories. All three have the same amount of space free. I'm using 3 Different IP's on the same NAS device (DR4300) to increase throughput since the RapidCIFS driver is not compatible with veeam sadly

[Highside1100]

Hi Guys,

We have ran out of space on a repository and have some storage that can be presented from 3par in order to get us out of a black hole for the time being

My question is , if I configure a scale out repository ,add the 2 disks as extents , point the job at it, will the job run an active full the next time it runs ?