[Info-vax] backups and compaction or nocompaction might be better

[AEF]

On Jan 29, 10:11 am, Stephen Hoffman <seaoh... at hoffmanlabs.invalid>
wrote:
> On 2013-01-29 14:43:53 +0000, pcovie... at gmail.com said:
>
> > details vms 8.3-1h1  lto4 tapes 8 tape autoloader with encryption. San
> > clones/copies for backup source. so the tapes raw capacity is 800gb and
> > below is a chart of what approximately goes to each tape per night, it
> > does vary. something else that may make a difference is that the
> > databases that reside on the disks are cache which is fine but they too
> > are encrypted. I can use as few as 3 tapes and as many as 5.
>
> Compression[1] and encryption are similar processes of looking for and
> eliminating patterns in data, but applied toward different goals.
>
> Always compress your data first, then encrypt it.
>
> Don't bother trying to compress encrypted data.  Properly encrypted
> data should never[2] be compressible.  (In practice, I've encountered
> cases where attempts to compress encrypted data produced larger outputs
> than what was input, too.)
>
> There's no point in encrypting already-encrypted data, either.  That's
> CPU intensive, and for no gain.
>
> Run your tests with just compression (either at VMS or at the device,
> but not both) enabled, and see what you get for data volumes.
>
> Then turn on encryption of the compressed data, and test again.
>
> I'll presume you know that BACKUP /IGNORE=INTERLOCK is a bad backup;
> that both overt and silent corruptions are permissible within the
> created saveset.
>
> ————
> [1]VMS calls data compression compaction, when it's performed at the
> device level.
> [2]If the encrypted data is compressable, then the encryption is badly broken.
>
> --
> Pure Personal Opinion | HoffmanLabs LLC

So if properly encrypted data isn't compressible, why bother with the
compression step?

AEF