> On 04/04/2012 10:32, Vlad Khorsun wrote:
>>> On 04/04/2012 10:14, Vlad Khorsun wrote:
>>>>> Getting half-crypted DB copy is something too exotic :-)
>>>>       Physical backup is "physical backup", i.e. page-level copy of a 
>>>> database. It have
>>>> nothing common with encryption state, and i see no problem if physical 
>>>> backup of
>>>> half-encrypted database is also half-encrypted. For the paranoid admins we 
>>>> can make
>>>> option in nbackup to encrypt pages before writting them into backup (of 
>>>> course file
>>>> system copy will be half-encrypted, but admins are informed and have a 
>>>> choice).
>>>>
>>>>       I see no reason to disallow backup's while encryption is in progress.
>>>>
>>>>
>>> And what about the contrary?
>>>
>>> If database is in backup-mode and you start encryption, original
>>> database will be maintained unencrypted
>>      Yes
>>
>>> and it will be rewritten encrypted in the delta file?
>>      Delta file will contain encrypted pages, yes. And at the merge step 
>> they will go to
>> database file.
>>
>>> Then whole delta file will be rewritten to the database when backup ends?
>>      At merge step - sure.
>>
>>> Sounds not wise.
>>      What the problem ? While "encryption in progress" state we anyway have 
>> part of
>> database encrypted and other part non-encrypted. Why physical backup confused
>> you ?
>>
>>
> It don't "confuse me". It's just dumb.

    Hmm...
 
> You ask for encryption, but a file is maintained unencrypted, and it 
> will be reported as encrypted (cause header page was rewritten in delta).

    You refer to the case, when encryption is finished while physical backup is 
in progress ? 
>From the logical POV, database is *really* encrypted in this case. Because 
>database is 
database file *plus* delta file. If you look at database file only, you look 
not at database
but at backup of level 0 at most.

> It will rewrite data two times (encrypt in delta, merge delta), and 
> since the main file is maintained unencrypted until the merge, it's just 
> dumb.

    Do you have better idea ? Disable backup is a smart ? Note, nobody forced 
DBA to
make encryption and physical backup at the same time. BTW, are you going to 
disable
sweep, for example, while physical backup is active ? ;)
 
> Considering that backup is happening doing more IO, it will just slow 
> things down for no reason.

    There is reason : sometime backup *must* be made despite of all else. If 
DBA can live 
without backup, it should not run it while database is not finished encryption 
process.
 
> The only reason to accept this scenario is that it will work 
> automatically, but as I said, it's not wise.

    I still see no reason to disable something just because it is not 
effective. Sometime
efficiency is not a primary goal and could be sacrified by security. This is 
DBA who
run backup and this is DBA who run encryption. Our task is to document how 
operation
should be made and to warn about possible issues.

Regards,
Vlad

------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second 
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel

Reply via email to