Where does HBS 3 store it jobs' settings?

[TeraBit]

I'm trying to recover an HBS 3 local backup (from one volume to another) settings after my system volume (the source of the backup) has some issues and QTS refuses to use it. So I replaced the drive, restored the media from the backup volume. Now I don't want to copy over (=overwrite) the tera-bytes of data from the source volume (that I just recovered from backup volume). This is redundant and would take hours. HBS provide an option to relink a backup job, but that fails with a non-informative error message, and QNAP support, so far, hasn't been able to help.
Then I tried connecting that problematic system volume to a PC and it seems I can access all the data there. Now I'm wondering: Where are HBS jobs' setting are stored? Maybe I can simply recover the job directly from the the previous system volume.

Can anyone point me in the right direction?

[Toxic17]

probably here: /share/CACHEDEV1_DATA/.qpkg/HybridBackup/CloudConnector3/db_backup

look like sqlite databases

[TeraBit]

probably here: /share/CACHEDEV1_DATA/.qpkg/HybridBackup/CloudConnector3/db_backup

look like sqlite databases

Thank you. I'll poke around that db and see what I can find. Also, I'll report back my findings.

[TeraBit]

OK, the path name (and the contents of that directory) suggests those are backups made of jobs that ran. The original file seems to be stored in a different partition/ext3 FS which is/was located at /mnt/sda_root\.config\cloudconnector\CloudConnector3\ (or /mnt/HDA_root), maybe it was changed in some update.
I got both the original and the latest backup and, surprisingly, they are not identical. the back contains 2 additional tables. As expected, they are, sqlite DBs.
Seems like there are two courses of action I could take here:
Plan A
0. Stop HBS 3.
1. restore config.db, db_backup and a bunch of log files laying around
2. Hope I didn't forget anything and it's all consistent.
3. Start HBS 3.
4. Cross fingers and let it run.

Or

Plan B
1. Recreate, manually, the job.
2. Compare the DB entries of the job created in 1. against the backup
3. replace the unique ID in .syncmeta located at the destination folder with unique ID of the newly created job in 1 (not accessible in the UI, taken from the jobs table in the config DB.
4. Cross fingers and let it run.

What would you consider the safest approach? I'm leaning towards Plan B.