Yes, I think it's a good idea to describe this scenario in our user guide, let me work with the technical writers team, we'll update it soon.
With regards to #2: yes, you can still run standalone jobs. However, please consider 2 possible scenarios:
A) Create a policy and process all databases on this server by policy (the same approach as implemented for SAP and Oracle).
In this case, existing standalone jobs will require a full backup on the file system (note: this full backup can also be created by a policy). This will create a new backup chain in a new folder: "PolicyName" / "ServerName". If a full backup exists, standalone jobs will continue to work and will create their backups in the location associated with the policy.
B) Create a policy for some databases, but process other databases that are not added to a policy using standalone jobs (new functionality available for SQL only).
To do this, you need to configure a repository for standalone jobs using the following configuration tool command:
--set-repository
After that, you can specify which databases you want to process in manual mode only:
MSSQLConfigTool --exclude-from-managed-mode --instance "INSTANCE" --d "database"
If you select the same repository as was used for standalone jobs, these jobs will continue working and will not require a full backup.
Answering other questions:
1. Speaking of automated restores, it is possible to run automated restores centrally using
PowerShell for Veeam Explorer for SQL Server.
2. When you create a protection group, VBR takes "ownership" of the plug-in server, and it starts operating in managed mode. In managed mode, as I mentioned above, you can still run standalone jobs, but please keep in mind scenarios A and B.
3. There is no need to create a protection group for each SQL Server or cluster unless there is a specific need to differentiate them, such as different sites, rescan schedules, or other options.
Thanks!