The next logical step was to develop methods of monitoring changes within files, rather than simply note that the files had changed. Developers started breaking files into small blocks that can be used as a basis for for CRC comparison. Only the blocks with changes would require backup--typically, 70 percent less data than before, though results could vary widely.
This was a substantial improvement, to be sure. However, block technology had a drawback: It wouldn't let you store less than a full block of data, regardless of the actual size of the change.
The next step was to drill down and examine byte-size changes. By handling a file as a binary string rather than a collection of blocks, products could extract byte-level differences and compile a delta (difference) file from the combined changed data of the entire backup set.
This proved to be an even smaller subset than block-level data--a 3-byte change in the data could be saved to the delta file as only 3 bytes, as opposed to a full block. The delta file of all file changes could then be compressed, sent to a server and stored sequentially. This procedure made it possible to restore or roll back files to a specific point in their backup history.
Of course, this level of file analysis required more computing power at both the client and the server end. Moreover, software had to be developed to track and manage the substantially more complex data sets and system information needed. Recognizing the limitations of a one-size-fits-all approach, IBM further refined the process, applying a combination of techniques so that files could be handled differently according to size.
Bob Friday, Chief AI Officer for Juniper Networks, explains how the advanced technology is transforming operations.
Contact center leaders from 8x8, Awaken Intelligence, and 360insight discuss the importance of agent experience.
AI may force enterprises to rewire parts of their data centers so they are fully optimized to run such workloads. The question is do you use Ethernet or InfiniBand?
