let’s see your case -
SQL is real border between databases and your proprietary software,
SA (user SA = SystemAdministrator of SQL srv)
SA of your SQL server have(!) any permissions to backup your bases, regardless of that SW.
internal SQL permissions is totally different from internal rights of that application, and OS(vary)
Moreover - SA have full control for all bases, settings, etc on that srv = God mode )
You shoud ask who is SA of your SQL, and that person can make some native backup jobs by SQL-srv
Or, SA can create sql user for you with backup rights. (regardless of that SW, again)
May be, installers of that app - installs also your SQL srv,
but they must give SA (SQL) pwd to real owner of server, or delegated person like DBA,
System Administrator (OS) of that server, etc.
IMHO, SQL-backups is right way for your case, and should be primary.
How simple your it-environment?
As I see by your questions, you shold find/get SA password,
and set sql-backups by ask some DBA to set and check(!) it
You can DIY, manuals is not black secret, google it…
but do not start your DBA-way from games on production-server! )))
seriously, do not.
as for UrB - now I’m not use it for SQL, and also learn that possibilities,
but not for main variant in production.
You should understand, that your copy’s must be consistent, and relible as steel!
and 100% restorable. SQL bases is one about most expensive data / asset of your boss,
so you must have warranty of restore, etc disaster recovery, mean it.
UrBackup is great solution, but mainly for other, wide purposes (IMHO)
like workstations state(image), user stuff etc file backups on that machines,
file shares / file servers, and also servers image backups -
full partitions with system state, settings even with databases etc
(it’s very cool to rollup to bare metal if fail, but not always goes according to plan )))
Howewer, I make my SQL-backups by native utils.
More control, more possibilities, speed, actuality on closest before-fail moment.
Too demanding task for non-specialized SQL-backup solution
For restore - I must have only SQL srv and backups, no more else point of fail or dependencies.
UrB backups is not so relible for SQL-restore as native-SQL copy - more parts - more point of fail…
slq back is single file (variants… sometimes not exact so, but simle words…)
but UrB backups is not a file… that is a complex of depencies of files spread on file system/-s,
also hardlinks, and big set of database records,
where is parts and versions and how to assemble your copy for moment, on demand…
if something goes wrong = you fired…
paranoia is no longer a disease =]
poor english, sorry.