Unconventional setup I must admit. I presume you know that any write to the db will failed and as such it is 100% failing ....
A restore will need to create a temp table, so I'm not sure you are on the right path.
You may want to debug this by starting your director with bareos-dir -f -u bareos -g bareos -d250
and observe the error ;-)
It may not be impossible to setup a pooler in front of the database that would redirect all write to the main instance and read on the replica, to be tested.
BTW, you mention that remote browsing and database is slow: this sound like
Mis(un)-configured database server : quite often people use the default of PostgreSQL which allow 131 MEGA Byte of shared memory, which force postgresql doing of lot of sorting, join, temp operation on disk instead of memory. The thumbs rule here is to allow 1/4 of the total ram, or try to have at least enough to put the bareos indexes on ram.
psql
show shared_buffers
bareos-# ;
shared_buffers
════════════════
8GB
(1 row)
With using the profile OTP in
https://pgtune.leopard.in.ua/ you will get normally a quite reasonable configuration for your bareos database cluster.
Also if you use the webui, it is recommended to preload the bvfs_cache (see documentation), which also need a correctly configured database.