Can you dedupe, part 2

Several weeks ago, we already told you about the “common” file-based and more advanced ways of deduplication. If we are going to deploy deduplication to a backup storage, and that storage deduplicates automatically, that is cause for some question marks. Because isn’t it opposite? After all, if you are backing up, you want to have a duplicate! And there is absolutely no intention to delete this duplicate.

Double or nothing

In other words, if you want to back up on hardware that can deduplicate, it’s a good idea to make sure it does! That sometimes causes some problems. Suppose you make a daily backup and a particular file is not changed from Monday to Tuesday. The dedup then says, “I already have this file, I don’t need to save that again. You need to be aware of that, because you may well want to have the file stored extra.

Note the version!

Another point of interest in deduplication for backup is the dedup version used. The more simple, file-based dedup method does not significantly affect write and read speeds. The advanced version, on the other hand, has much longer work to check which parts of a file are already present and which are not, plus it takes more time to reassemble the file when queried.

Landing zone

As deduplication becomes more sophisticated, it requires correspondingly more computation time. These deduplication systems use a cache for this purpose, a piece of fast storage where the frequently used file resides. This is also known as the “landing zone. So: here are frequently used files, already assembled, and they are thus quickly retrievable. However, a complete backup is not in the landing zone, for the simple reason that a complete backup is too large for that. The backup data must then be rebuilt. In a major crash that cripples the entire company, that’s precious wasted time. Thus, it is good to carefully weigh the pros and cons of the various options!

Want to know more? Please inquire about the possibilities!