Am 05.11.26 um 10:59 schrieb Marcin Haba:
Yes, I think your assumption is correct.
The FD data encryption is interesting case in the restore verification
meaning. This means that the restore destination host should be able
to decrypt ivy-fd backup data.
The simplified definition of restore destination is:
Restore destination = API host + Bacula FD
But it is not possible to have:
Restore-destination on host B ("ivy") ... with key to encrypt
API-Host on host A ("tx100"): running bacularis and bacula-director
Bacula-FD used on host B ("ivy") ... with the needed keys for decrypt
?
You can install, as you wrote, API host on that ivy-fd host, then
connect this API host to Bacularis web interface. At the end, the new
restore destination should use this Bacula FD. It should work because
ivy-fd will be able to decrypt this data.
Persoanally I would advise to create a dedicated restore destination
for the restore verification tests. This separated host could have API
host and Bacula FD installed. This Bacula FD could be able to decrypt
ivy-fd data (with configured key), and you could use this host for
other restore tests for other jobs as well.
Hm, OK. In my test-case there's only 2 or 3 hosts in the game.
But if I think of customers this would mean that the one dedicated
restore destination would have to have all the keys of the various file
daemons, right? I see some security concerns here ... but maybe I am too
sensible here.
It would be better to test restores on the separate fds in my opinion:
key only on that specific file daemon.
Regardless the way you choose, the most important is:
- have API host and Bacula FD on the restore destination
- Bacula FD used in the test should be capable to restore decrypted data
I will try my best to get that working on my test boxes asap.
thanks!
_______________________________________________
Bacula-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bacula-users
