April 3, 2017 at 9:59 am
Sorry for the length of this posting. I wanted to to fill in the blanks on some relevant aspects of how Actifio works, to help eliminate the guesswork and hopefully make it easy to predict what you should expect when using it.
Actifio works on very different principals than native SQL dumps. Native dumps will perform 100% read operations across the entire database and dump that data to disk. The performance is driven by the infrastructure and some configuration options, such as compression. However, the trade-off is the disk space consumed by all the copies that get generated and impact to the production server while it runs (may or may not be an issue, depending on the nature of the application using the DB). As was mentioned, sometimes people will dump to local disk, and then copy to a remote disk, further elongating the overall process in order to reduce the time of the impact to the production database. After backups, to perform a restore requires you to read the backup file, possibly decompress it, and write the data back into the native database format (instead of the backup format). This sounds obvious, but as you'll see in a minute, it's a very different recovery method than Actifio uses.
Keep in mind, that if your databases are very small, just a few MB or GB, then the pain involved with backups and restores is minimal. Actifio is typically deployed to solve performance and storage consumption issues with larger environments (100's of GB to many TB per DB is common) as that's where our customers were previously experiencing pain.
Actifio takes a very different approach. We make a consistent copy of the underlying SQL database files rather than taking dumps of the data. This results in several significant differences:
Because Actifio leverages storage infrastructure to do the data movement, there is some overhead at the beginning and end of a job. This usually takes a few seconds, but sometimes can take a minute or two. In a misconfigured environment, it can take much longer (particularly if running SQL clusters under VMware). Our Customer Success organization can help resolve those configuration issues.
When it comes to deduplication, The Actifio deduplication engine is fine-tuned for efficiency when processing data captured using the Actifio standard capture methods. This does not include taking multi-tier backups (i.e. a backup of a backup). While the first generation of deduplication products were designed to process backups taken by a backup solution (or native SQL dumps), Actifio was designed to perform deduplication on a copy of the actual source data. This is a subtle difference, but an important one. It means that Actifio will be affected less by things like index maintenance because we just capture the blocks in the database that have been updated, rather than processing a streamed (and possibly compressed) SQL dump file. Combine this with the efficiencies in the way SQL Server writes data to disk and the result is a very high match rate with our deduplication so that the extra consumption resulting from index maintenance is minimal. We do, of course, have to process the higher change rate, and this is usually planned for when architecting a solution with our customers. While not common, we do have some customers who run index maintenance daily and experience excellent deduplication ratios.
If a discussion with experienced Actifio SQL Server customers is desired, please contact your sales team. They will be happy to arrange for a discussion and Q&A session with a customer who has an environment similar to yours and who can speak from first-hand experience.
Viewing post 16 (of 15 total)
You must be logged in to reply to this topic. Login to reply