We resume our discussion of using a cache layer with Object Storage. We said we could let objects age before they make it to storage. There were several benefits to this approach. First we need store the objects as versions. Second we could take incremental backups. Third along with the backup we retained the ability to reconstruct the object though archived data is generally not retrieved. We utilize archiving techniques like deduplication to reduce the footprint of the storage. Also, the data is made invulnerable when the old data is not modified by the new data. The new data is written separately and the good data from the old is never lost. This is demonstrated by many of the public clouds. For example, Windows Azure uses extent and many storage appliances do something similar especially with stream storage. This holds true with reconstruction as well and not just with versioning. Consequently, even deduplication appliances practice data invulnerability with their efforts to find segments that change.
Why do we focus on reconstruction as opposed to versioning of objects from the cache? This depends entirely on the schedule of the backup of objects from the cache to the object storage and the footprint we want to keep in the storage tier. The cache layer and the storage layer are separate. Both of them can have processing that can make those respective layers smart.

When we have immutable representation of data no matter how it is stored, it can provide immense benefits to data security, audit and restore. This idea for invulnerability is seen in many different forms of technologies. It not only helps with preservation but also helps with error codes. As long as the data has not changed, the error codes do not change. This is primarily the motivation behind durability.