On 04/04/12 17:49, Adriano dos Santos Fernandes wrote: >>> 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. > > You ask for encryption, but a file is maintained unencrypted, and it > will be reported as encrypted (cause header page was rewritten in delta). > > 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. > > Considering that backup is happening doing more IO, it will just slow > things down for no reason. > > The only reason to accept this scenario is that it will work > automatically, but as I said, it's not wise. >
I agree with Adriano - doable, but not wise. On my mind we should protect people from things, that will definitely make it work worse. Moreover, it can easily happen that nbackup is started automatically by cron. It does not mean that admin wanted to do it, he just forgotten to stop background task. We should not punish people with additional performance degradation for it. Suggested by Adriano approach with delaying encryption for nbackup time will work, and may be it's the best way to go. The fact that we get half-encrypted copy is certainly surprising at the first glance, but if we take into an account that database itself is currently in such state and that encryption will be resumed automatically after restore - why not? ------------------------------------------------------------------------------ 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
