Network Computing is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

De-Dupe Dos & Don'ts: Page 2 of 3

Compression and encryption algorithms take fixed-size data blocks and transform them to do their work. If 1 byte of the data changes, the compressed and/or encrypted data block changes dramatically so a variable block data de-duping solution like those from Quantum, Dell, EMC, or Data Domain can't see the changes.

Since most de-duping solutions, with the obvious exception of NetApp's A-SIS, which is targeted more at primary storage than backups, compress data after de-duping, there's no good reason to compress before.

I've never thought encrypting disk data in the data center, as opposed to tapes you're going to put in a truck, added significantly to real security, so turning off encryption doesn't really bother me. It does mean that you'll have to spool data off to tape through your backup media servers until the vendors of VTLs and backup software work out APIs that allow direct export to LTO-4 drives using the drive's encryption engine and key management in the backup app.

Don't interleave/multiplex
While interleaving made a lot of sense when you were trying to keep a high-speed tape drive fed, disk backup targets can accept data at any rate without shoe shining. Like compression, interleaving disturbs the data stream so the de-duping algorithm will see part of file A that it previously backed up mixed with file B that's new and think the whole stream is new data.

While a content-aware system like Sepaton's could demultiplex and possibly decompress the data before de-duping, there's no good reason to make the VTL CPU work harder than it has to.