If you want to add repositories as extents to a scale-out backup repository, and Veeam Plug-in backups are present on the source repository, you must do the following:
Copy the Veeam Plug-in job folder (the whole folder) to an existing scale-out backup repository extent.
Delete the backups from the source repository.
Rescan the source repository.
Add the repository as an extent to the scale-out repository.
Rescan the scale-out repository.
Set the scale-out repository as target in the Veeam Plug-in settings.
Map the imported backups using the following command:
sudo SapBackintConfigTool --map-backup
I can't wrap my head around these steps. After step c, the backup is no longer present within Veeam Console since it no longer exists in the original repository. In step d, I am supposed to add "the repository" to the scale-out repository. But since I am expected to copy to an EXISTING scale-out extent in step a, I don't know what repository I am supposed to add in step d. Also, if I copy the backup files to and existing performance extent and rescan, the backup won't show up in Veeam console. If I copy the backups to an existing repository and rescan first and try to add to scaleout afterwards, Veeam refuses because incompatible backups are present. I am confused.
But the original repository is empty since I was supposed to delete the backups from the original repository? I am generally really happy with the Veeam docs and I think I might just be missing some key points here. My ultimate goal is to add a capacity tier to a regular direct attach storage repository to copy and move existing and future HANA backups to S3.
You need to add original repository to Scale-Out Backup repository, only if you want to use it as an extent. Otherwise (you do not need original repository any more) you can skip the step D.
The backups should become visible after you rescan Scale-Out Backup repository. Check whether the backups are shown under Imported node. If that does not happen, feel free to reach our support team for further assistance.
From my point of view this part of documentation is confusing and we should think about possible improvements.
@mfirewalker Do I understand correctly that: you have a repository on which you store plug-in backups and you want to convert this standalone repository to SOBR extent in order to use Capacity Tier afterwards?
Okay, thanks for clarifying. So basically, I should be able to copy the backups around between normal and scale-out repositories and they should show up as imported. On my first tries, I did not see the backups after copying them to an performance extent of a scale-out repository. As soon as I move them back to a regular repository, they show up as imported. I will try again and open a case if they fail to show up.
Hi PetrM,
That's exactly what I am trying to achieve. And yes, I think the section could use some revision.
In fact, we can shorten the sequence of required steps:
1. Select backup on the existing standalone repository and remove this backup from configuration
2. Add the existing repository as an extent to SOBR
3. Rescan SOBR. Backup will appear in the list of imported backups
4. Set SOBR as target in plug-in settings
5. Map the imported backup (sudo SapBackintConfigTool --map-backup)
The workflow which is described on our help center contains some extra steps, for example it's not clear why should I copy backups to an extent if I want to use my existing repository as a part of SOBR. We'll update the help center page accordingly soon.
I tried the steps outlined by you but this still won't let me do it. The error message when trying to add the repository as a performance extent does however change from "because it contains one or more backup files which are not supported by a scale-out backup repository." to "because it serves as the target for one or more job types which are not supported by a scale-out backup repository." after removing the backup from the configuration. So it seems more like a code issue to me since SOBR now do support Plug-ins for Enterprise but the creation of SOBR cannot handle this. It still recognizes the target of the backup job and won't let me add it. According to my findings, I probably would need to change the repository on the source backup host first and run a backup, but at this point, the new target repository cannot be created. I hope you get my point. So the original steps seem to be there for a reason even though they are confusing.
because it serves as the target for one or more job types which are not supported by a scale-out backup repository
Just our of curiosity - what jobs does the error message list? Plug-in ones? Or it complains about other jobs? Say, configuration backup or similar? Thanks!
Yes, the error message is expected because I forgot to mention one step: to remove a corresponding plug-in job. We've just updated our help center:
a. In the Veeam Backup & Replication console, select Veeam Plug-in backup files that reside in this backup repository and remove them from configuration.
b. In the Veeam Backup & Replication console, delete the Veeam Plug-in backup job.
c. Add the repository as an extent to the scale-out repository.
d. Rescan the scale-out repository.
e. On the Veeam Plug-in server, set the scale-out repository as the target for backups.
f. Map the imported backups.
This seems like the way to go and Veeam actually now recognizes the existing enterprise application backups during the SOBR creation asking whether I want to copy them to the capacity extent or not. So there seems to be a logic for existing enterprise apps backups but it is not covering the entire process of turning a regular backup repository into a scale-out. However, the existing backup still do not show up in the backups pane neither as on disk nor as imported. Funny enough, there were 2 additional enterprise apps backup that have been copied to the repository with copy jobs and Veeam did not even care about them in the first place. I did not remove them from the configuration and it would still let me create the sobr with them in the database.
The reason I still created a case (#04822011) now is because the backup that I removed from the configuration does not show up as imported, as mentioned above, and therefore I cannot map the backup on the source host.
SAPHANADB:~ # SapBackintConfigTool --map-backup
Repository HANA Scale-out Backup Repository 1: failed to map: Imported backup was not found on repository HANA Scale-out Backup Repository 1
When scanning the scale-out repository, all the backups are correctly detected ("skipped: 3"), but only 2 from the copy jobs show up under Backups node. This is the same thing I experienced earlier when I copied the backup over to any entirely new scale-out repository with freshly created extents.
Just adding the final result here since this can potentially affect other installations as well: The original job folder and job file (vacm) had whitespaces and parenthesis in their names (auto-generated by Veeam) and the SOBR cannot handle those. Replacing both with underscores allowed the original backup to be imported as part of the SOBR. See More Information on https://www.veeam.com/kb2236 which seems to be still valid for v11.
Thanks for sharing the solution with the Community! I believe we should investigate this behavior a bit deeper in order to asses possibilities of further improvements in the algorithm.