Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM Enhancement Requests and Suggestions » View Thread |
Messages 1 to 10 of 10 total |
Encrypted backup & restore |
Wed, Jun 3 2009 10:01 AM | Permanent Link |
Roy Lambert NLH Associates 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 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. 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 AM | Permanent Link |
Roy Lambert NLH Associates 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 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. 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. -- Tim Young Elevate Software www.elevatesoft.com |
Fri, Jun 5 2009 3:28 AM | Permanent Link |
Roy Lambert NLH Associates 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. 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 AM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. 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 AM | Permanent Link |
Roy Lambert NLH Associates 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 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. 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 AM | Permanent Link |
Roy Lambert NLH Associates 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 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. 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 |
This web page was last updated on Wednesday, April 24, 2024 at 11:07 AM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |