Frequently Asked Questions

Does InMage support data deduplication?

InMage does not support index-based data deduplication like that supported by deduplication vendors, but provides a compelling alternative. In normal operation, InMage deals only with change data. If you were to attempt to deduplicate data that InMage is transferring over LANs or WANs, you would get very low data reduction ratios since we have removed all the redundant data before we ever take the data off the production server source(s). We are sending extremely capacity optimized data sets over networks as a result of this approach (both the LAN and the WAN), and ultimately storing data in a very capacity optimized manner in the target storage repositories. Applying deduplication to data managed by InMage  will not achieve much savings in terms of storage capacity.

Continuous Backup: Experience a Revolution in the Backup/Restore Paradigm

You're backing up because you need to recover, not because you like doing backups. Backups are a pain. They take up your time, they impact business operations, and after all that effort, they don't even always support reliable recovery.

There are two key problems with conventional backup. One is that conventional methods treat backups as a discrete operation, resulting in the "pig through the snake" problem. At a given time, you try to take all the changes since the last backup and push them through your network all at once. As your backups get bigger and your networks don't, you will eventually not be able to complete your daily backups in the available time frames. The second (and related) problem is that tape is still the predominant backup medium. Tape is a sequential access medium whose performance characteristics do not mesh well with the requirements of backups and frequent, object-level restores.

InMage solves this problem in a way which eliminates backup as a discrete operation (hence no more "backup window" problem), allows you to meet the most stringent RPO/RTO requirements, and improves recovery reliability relative to tape at the same time. InMage leverages disk-based recovery, a design decision which gives us access to disk-based technologies like CDP and replication that can eliminate backup impacts while actually improving your recovery capabilities. Using CDP, we stream writes from production servers as they occur throughout the day to our disk-based repository, moving backup from an impactful, discrete operation to a continuous operation that generally imposes no noticeable impacts on the network. Data streams from each server are annotated with time stamps and other tags that mark business process points that are relevant for recovery as well as a number of other business operations (reporting, test, maintenance, etc.). When a disk-based copy of what the production data looked like at any point within that data stream is needed, an administrator can retroactively select that point, generate a disk-based copy, and mount it on any desired server. The creation of these images imposes no impact whatsoever on production servers, and allows administrative operations of all sorts which use copies of production data to be time-shifted to any convenient time, a capability that can help optimize operator productivity.

Think what this means for backup. Since I can effectively create a disk-based copy of production data whenever I want, I can create the optimal disk copy to meet any recovery scenario. Do I want the latest data state so as to minimize data loss on recovery? Do I want the most recent application-consistent point in time (referred to in InMage parlance as an AppShot) to minimize recovery time? Am I recovering from a data corruption problem, in which case I may want the most recent known good data state prior to the corruption event? Do I want several disk-based images clustered around a given point in time to use for root cause analysis? InMage allows you to immediately create any of these recovery points without having to handle any tapes.

InMage customers generally define a retention period of from several days to several weeks across which the data streams from each protected server will be retained. Administrators can retroactively create any data state within that retention period. Companies that do not retain backup data longer than several weeks (and we're defining backup data as separate from data retained to support DR requirements) may be able to entirely dispense with tape handling, not only at centralized sites but also at remote office locations. InMage  can be used to automate data protection operations at these sites, which means that manual processes are not required on a daily basis to maintain appropriate levels of protection.

Even if companies do eventually want to dump data to tape, InMage offers significant benefits by front-ending existing backup infrastructure. Any existing backup software can be used to back up AppShots to tape without imposing any business impacts. A common scenario in our customers who do still want to eventually migrate data to tape is the following: they are able to move from a situation where they back up to tape daily to one where they back up to tape weekly or even monthly, retaining intervening data states in the InMage  repository to support near term recovery requirements. Note that this repository can exist in the remote site, in the local site, or in both sites at once (a configuration which leverages InMage's 1 to n replication capability).

When deploying InMage, you can potentially replace backup and other agents that reside on production servers for the purpose of giving an application access to that server's data. Backup agents sit on servers to administer backups, interact with applications to perform on-line backups, and support other functionality (like source-based data deduplication). Agents can impose significant server overhead, and can present maintenance challenges. Multiple agents can potentially be replaced with the InMage data tap, a lightweight filter driver, and any application-specific tasks such as backups, reporting, etc. can be performed from AppShots created by InMage. In this way, InMage can reduce the number of agents required (and their associated patch management, maintenance fees, etc.), backup and otherwise. When using InMage to shift backup operations off-host, you may designate a single, centralized server as the backup server, mounting AppShots on it to perform backups to tape. This server would still need a backup agent, but this approach will allow you to eliminate a large number of backup agents and their associated costs.

Finally, the fact that all near term recoveries are coming from disk and do not require tape handling will have a very positive impact on recovery reliability.