Icon View Thread

The following is the text of the current message along with any replies.
Messages 1 to 10 of 10 total
Thread Encrypted backup & restore
Wed, Jun 3 2009 10:01 AMPermanent Link

Roy Lambert

NLH Associates

Team Elevate Team Elevate

Just finished encrypting my test database and then tested backup and found compression is lost. I would expect this if I used an external utility because the encrypted data is non-compressible or almost so. I had hoped that ElevateDB would decrypt, compress and backup.

With the default compression my test shrank from c1Gb to 300Mb so very useful. Encrypted it stayed at c1Gb.

I don't know about others but I'd be willing to trade speed for compression either via a new flag or as a separate command.

Roy Lambert
Wed, Jun 3 2009 2:43 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Roy,

<< Just finished encrypting my test database and then tested backup and
found compression is lost. I would expect this if I used an external utility
because the encrypted data is non-compressible or almost so. I had hoped
that ElevateDB would decrypt, compress and backup. >>

That would require that EDB individually decrypt every single row, page, or
BLOB block individually to separate files and then run the backup on them.
IOW, it would take longer than it would to just backup the raw files.
Remember, all of this is possibly occurring during multi-user usage, so the
most important aspect of the process is that it be quick.

--
Tim Young
Elevate Software
www.elevatesoft.com

Thu, Jun 4 2009 2:53 AMPermanent Link

Roy Lambert

NLH Associates

Team Elevate Team Elevate

Tim

>That would require that EDB individually decrypt every single row, page, or
>BLOB block individually to separate files and then run the backup on them.
>IOW, it would take longer than it would to just backup the raw files.
>Remember, all of this is possibly occurring during multi-user usage, so the
>most important aspect of the process is that it be quick.

Agreed, recognised and understood with one exception. Speed is often (possibly generally) the most important but sometimes size is a big factor.

If speed is the only factor to be considered then with encrypted tables I'd guess that a simple copy command would be faster and all you loose is the fact that its in a single file.

Its not something I'm going to get to upset about either way. If others are interested maybe they can add their opinion on either side.

Roy Lambert
Thu, Jun 4 2009 1:50 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Roy,

<< Agreed, recognised and understood with one exception. Speed is often
(possibly generally) the most important but sometimes size is a big factor.

If speed is the only factor to be considered then with encrypted tables I'd
guess that a simple copy command would be faster and all you loose is the
fact that its in a single file. >>

No, that wouldn't be the only thing you'd lose - you'd lose the protection
that EDB provides to ensure that only readers (not writers) are permitted
during the backup operation.  These aren't just text files, after all. Wink

--
Tim Young
Elevate Software
www.elevatesoft.com

Fri, Jun 5 2009 3:28 AMPermanent Link

Roy Lambert

NLH Associates

Team Elevate Team Elevate

Tim


>No, that wouldn't be the only thing you'd lose - you'd lose the protection
>that EDB provides to ensure that only readers (not writers) are permitted
>during the backup operation. These aren't just text files, after all. Wink

Yeah but think about it ElevateDB took c2mins, Copy c15secs so  for 15 secs no one is allowed to do anything <vbg>

Roy Lambert

ps all timings performed using the clock on my desk.


Fri, Jun 5 2009 6:09 AMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Roy,

<< Yeah but think about it ElevateDB took c2mins, Copy c15secs so for 15
secs no one is allowed to do anything <vbg> >>

Did you turn off the compression for the backup ?

--
Tim Young
Elevate Software
www.elevatesoft.com

Fri, Jun 5 2009 7:18 AMPermanent Link

Roy Lambert

NLH Associates

Team Elevate Team Elevate

Tim


No - I thought ElevateDB would detect automatically that the table was encrypted and wouldn't bother with compression. If it doesn't shouldn't it?

Roy Lambert
Fri, Jun 5 2009 2:41 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Roy,

<< No - I thought ElevateDB would detect automatically that the table was
encrypted and wouldn't bother with compression. If it doesn't shouldn't it?
>>

Probably, but for now you should turn it off.

--
Tim Young
Elevate Software
www.elevatesoft.com

Sat, Jun 6 2009 3:43 AMPermanent Link

Roy Lambert

NLH Associates

Team Elevate Team Elevate

Tim

>Probably, but for now you should turn it off.

I hope that means it will soon, and on an individual table basis.

My major app is a recruitment one so there is some data that I want encrypting "just in case" eg contacts, emails other data eg job codes, std codes, spam won't be encrypted so a backup will be a mixed bag. As I said before I'd like to get compression even at the expense of a bit of speed. In my case backups can be set to run late at night when no-ones around. I know some people will have 24/7 apps and need speed at the expense of compression.

Roy Lambert
Mon, Jun 8 2009 2:57 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Roy,

<< I hope that means it will soon, and on an individual table basis. >>

I'll see what I can do.

--
Tim Young
Elevate Software
www.elevatesoft.com

Image