Hello,
To *back up* data you do *not* need to decrypt it, you should back up
the "raw encrypted" data as it is (and, of course, to take care to back
up your encryption keys - but separately!).
It is probably a design fault in Bacula currently, not an intentional
design decision.
I believe (did not investigate Credant product) it is the same issue as
with unsupported EFS (Encrypting File System - a standard Windows 2000+
"non-home" feature).
Technically, one cannot use the "standard" BackupRead API function (the
one Bacula uses) to access encrypted data (this is a pretty strange
design decision in Windows; maybe it has something in common with extra
permissions checking beyond encryption itself, e.g. special privileges
needed?), one has to use dedicated xxxEncryptedFileRaw API instead
(again, to get *encrypted* data). Additionally, one has to "lift up" the
Bacula attributes infrastructure (to store the fact that a given file
was backed up "in encrypted state" to restore it appropriately if
needed) and this is the most complex part for me personally ;-).
Currently, encrypted data is not backed up at all. This might be an
issue when using Bacula for "Windows server migration" (if the server
utilizes EFS).
I have posted a feature request in summer 2008 but it has not been
implemented so far. If nothing good happens with it till the end of
January when my pretty heavy ongoing project should be completed I will
try to push my "neigbour" C/C++/Java gurus to help setting up a
development/test environment to fix the issue; unfortunately I am not a
C developer...
Alex Ehrlich
Kevin Keane wrote:
This is most likely by design. The whole point of encrypting hard disks
is to only allow "authorized" software access to the decryption key (and
to protect the hard disk if somebody has physical access to it). I am
not familiar with Credant, but there probably is a way to tell it that
the bacula-fd service is "safe" and should have access to the key. You
may want to browse the Credant support area and knowledge base for
information, and/or contact Credant.
I'm reasonably sure that this problem is outside of where this
bacula-related mailing list can help you.
s_mendes wrote:
>
> People,
>
> After my company implemented a program that encrypt the entire HD
> (Credant), Bacula can't access any file on clients that have this
> program installed. The message error is Cannot open C:\Documents and
> Settings\user\Local Settings\Application
> Data\Microsoft\Outlook/2008.pst: ERR=Access is denied.
>
> Is there anything to do about this issue? I can access the entire
> volume and any file on all clients; I don't know why babula can't access.
>
> Tks for any help!
>
> Sandro
>
--
Kevin Keane
Owner
The NetTech
Turn your NetWORRY into a NetWORK!
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users
|
