March 31, 2017 at 7:41 am
We are in the middle of implementing Actifio as our backup strategy. Obviously as a DBA I'm reluctant to relinquish control of the database backups to another solution. The native solutions I have in place are working well and provide confidence that we are covered for the SLA's required for each system. Actifio is here to stay in our environment, but thankfully my input as a DBA is valued and we will be evaluating whether or not to use it for SQL. This could mean we don't use it at all, use it fully or in mixed cases. Adequate storage is the primary drawback to native SQL as I'm always struggling to maintain backups for the required retention periods which is one area that make Actifio appealing. It also has some nice features for presenting restores. I'm still fiddling with it and I do like some of what it offers. Although I do find the GUI could stand some improvement in the friendly department.
Has anyone made the switch? If so can you provide any pro/con feedback that would be helpful.
Thanks,
Duke
April 1, 2017 at 8:06 am
Hi,
I work for Actifio, and wanted to offer assistance. If it would beneficial, I would be happy to provide you with more details on how Actifio works with SQL or even a live demo. I can also connect you with some SQL users if that would be helpful. (I am not sure about how many of our users participate in this forum.)
If you want to reach me you can reply to this thread or send an email to my first name at actifio dot com.
Thank you,
Jay
Edit: Fixed links.
April 1, 2017 at 8:18 am
Thanks. We have contacts and support with Actifio. I'm looking for feedback from those with experience using it in the real world.
April 1, 2017 at 10:57 am
tsduke - Friday, March 31, 2017 7:41 AMWe are in the middle of implementing Actifio as our backup strategy. Obviously as a DBA I'm reluctant to relinquish control of the database backups to another solution. The native solutions I have in place are working well and provide confidence that we are covered for the SLA's required for each system. Actifio is here to stay in our environment, but thankfully my input as a DBA is valued and we will be evaluating whether or not to use it for SQL. This could mean we don't use it at all, use it fully or in mixed cases. Adequate storage is the primary drawback to native SQL as I'm always struggling to maintain backups for the required retention periods which is one area that make Actifio appealing. It also has some nice features for presenting restores. I'm still fiddling with it and I do like some of what it offers. Although I do find the GUI could stand some improvement in the friendly department.Has anyone made the switch? If so can you provide any pro/con feedback that would be helpful.
Thanks,
Duke
Here is some info to chew on.
Large data manipulations (index maintenance included) wreak havoc on the dedupe.
The interface leaves much to be desired.
On the pro side of things, they do allow you to prevent the most recent n backups from being deduped (essential for ensuring you have a good backup since deduped backups can all get hosed if you lose the wrong backup).
Even with this tool, the general recommendation is to perform native backups and then allow the tool to backup your native backups.
Jason...AKA CirqueDeSQLeil
_______________________________________________
I have given a name to my pain...MCM SQL Server, MVP
SQL RNNR
Posting Performance Based Questions - Gail Shaw[/url]
Learn Extended Events
April 1, 2017 at 11:14 am
Thanks SQLRNNR! Thanks exactly the kind of feedback I'm looking for. I've been curious what the impact of index maintenance would have on the dedup and how much storage savings there could be over native as a result. I've not used it much yet other than setup on test server.
What impact does Actifio have on the native backup chain?
April 1, 2017 at 5:14 pm
If you do native backups and then just use actifio to backup the flat backups, then no impact on the native chain.
If you have a full + diff backup plan implemented with native backups, then actifio would break that chain if you perform a backup of the databases with it. It is the same effect as any 3rd party util.
The same backup chain problem can be seen if they perform snapshots of the host. Most apps will create a backup entry to be inserted into msdb and reset the recovery lsn for the db - this is a bad practice. I have run into far too many non-recoverable situations with this scenario because the databases are not properly backed up.
Jason...AKA CirqueDeSQLeil
_______________________________________________
I have given a name to my pain...MCM SQL Server, MVP
SQL RNNR
Posting Performance Based Questions - Gail Shaw[/url]
Learn Extended Events
April 1, 2017 at 8:38 pm
SQLRNNR - Saturday, April 1, 2017 10:57 AMEven with this tool, the general recommendation is to perform native backups and then allow the tool to backup your native backups.
I agree with that. The system we have at work is similar to Actifio in that it "de-dupes". They also told us that it's a bad idea to use compressed backups for the same reason. And, that made things slow because you had to transmit about 4 times as much data when uncompressed. I finally convinced them to let me try compressed backups with some buffer and packet size tuning and that's what allows us to backup a 2TB system in an hour.
--Jeff Moden
Change is inevitable... Change for the better is not.
April 1, 2017 at 8:51 pm
Jeff Moden - Saturday, April 1, 2017 8:38 PMSQLRNNR - Saturday, April 1, 2017 10:57 AMEven with this tool, the general recommendation is to perform native backups and then allow the tool to backup your native backups.I agree with that. The system we have at work is similar to Actifio in that it "de-dupes". They also told us that it's a bad idea to use compressed backups for the same reason. And, that made things slow because you had to transmit about 4 times as much data when uncompressed. I finally convinced them to let me try compressed backups with some buffer and packet size tuning and that's what allows us to backup a 2TB system in an hour.
I have the same thing going on with a 2Tb database. I can finish a native backup in under 30 minutes where the tool takes 4+ hours. Performing the restore on the other hand takes me about 2hrs with the native and 3x longer (minimum) with the tool. I have measured three different tools on this database and all turn out about the same.
Jason...AKA CirqueDeSQLeil
_______________________________________________
I have given a name to my pain...MCM SQL Server, MVP
SQL RNNR
Posting Performance Based Questions - Gail Shaw[/url]
Learn Extended Events
April 1, 2017 at 9:11 pm
SQLRNNR - Saturday, April 1, 2017 8:51 PMJeff Moden - Saturday, April 1, 2017 8:38 PMSQLRNNR - Saturday, April 1, 2017 10:57 AMEven with this tool, the general recommendation is to perform native backups and then allow the tool to backup your native backups.I agree with that. The system we have at work is similar to Actifio in that it "de-dupes". They also told us that it's a bad idea to use compressed backups for the same reason. And, that made things slow because you had to transmit about 4 times as much data when uncompressed. I finally convinced them to let me try compressed backups with some buffer and packet size tuning and that's what allows us to backup a 2TB system in an hour.
I have the same thing going on with a 2Tb database. I can finish a native backup in under 30 minutes where the tool takes 4+ hours. Performing the restore on the other hand takes me about 2hrs with the native and 3x longer (minimum) with the tool. I have measured three different tools on this database and all turn out about the same.
I thought I was doing well at 60 minutes. To get it down to 30 minutes, are you backing up to the same disks on the SAN as where the data lives? I'm backing up across the pipe to some NAS... fast NAS, but still a NAS and still have to go through the pipe to get there.
--Jeff Moden
Change is inevitable... Change for the better is not.
April 1, 2017 at 9:46 pm
Jeff Moden - Saturday, April 1, 2017 9:11 PMSQLRNNR - Saturday, April 1, 2017 8:51 PMJeff Moden - Saturday, April 1, 2017 8:38 PMSQLRNNR - Saturday, April 1, 2017 10:57 AMEven with this tool, the general recommendation is to perform native backups and then allow the tool to backup your native backups.I agree with that. The system we have at work is similar to Actifio in that it "de-dupes". They also told us that it's a bad idea to use compressed backups for the same reason. And, that made things slow because you had to transmit about 4 times as much data when uncompressed. I finally convinced them to let me try compressed backups with some buffer and packet size tuning and that's what allows us to backup a 2TB system in an hour.
I have the same thing going on with a 2Tb database. I can finish a native backup in under 30 minutes where the tool takes 4+ hours. Performing the restore on the other hand takes me about 2hrs with the native and 3x longer (minimum) with the tool. I have measured three different tools on this database and all turn out about the same.
I thought I was doing well at 60 minutes. To get it down to 30 minutes, are you backing up to the same disks on the SAN as where the data lives? I'm backing up across the pipe to some NAS... fast NAS, but still a NAS and still have to go through the pipe to get there.
Local first and then file copy off to SAN after that. Takes another 30 minutes-ish to get it to the second location.
Jason...AKA CirqueDeSQLeil
_______________________________________________
I have given a name to my pain...MCM SQL Server, MVP
SQL RNNR
Posting Performance Based Questions - Gail Shaw[/url]
Learn Extended Events
April 2, 2017 at 5:05 pm
SQLRNNR - Saturday, April 1, 2017 9:46 PMLocal first and then file copy off to SAN after that. Takes another 30 minutes-ish to get it to the second location.
Thanks, Jason. I've found the same to be true so I took the "local first" out of it for a total of an hour to push it all to that second location. Just wanted to make sure I didn't do something wonky compared to the 30 minutes you talked about.
--Jeff Moden
Change is inevitable... Change for the better is not.
April 3, 2017 at 6:53 am
Hi Everyone.
My name is Anoop and I too am an employee at Actifio. I first started in professional services where i deployed the product across hundreds of customers and showed them the value of Actifio in their environment. I know the ins and outs of Actifio very well.
Specific to SQL Server, we support all the configurations of SQL Server all the way up to 2016. Actifio took a unique approach to SQL Server backups that actually helps to make the backup process very efficient but more importantly, makes the recovery process very efficient as well.
The Actifio connector deploys a driver that's responsible for capturing incremental block level changes inside of any MDF/LDF files belonging to a database. We leverage VSS to quiesce the DB and snap the volumes to get an Application Consistent point in time of the database or databases. This means that after the initial capture, the subsequent backups are very very fast. On the order of minutes for backups of very large multi TB databases. Actifio can also capture the archive logs thus giving you point in time recovery capabilities as well. The backup chain should not be affected with Actifio either.
Index maintenance can cause a snapshot job to run a little longer but it should still be less than the amount of time it takes to do a native backup. Additionally, once the snapshot (capture) is done, the dedup is done in the background and has no impact on the server itself.
Our mantra has always been "How can we get the data out as fast as possible? and How can we give it back as fast as possible?" With the above described solution, you get your database back up and running within minutes as opposed to hours. The simple reason for this is that you normally would have to take the native backup, read it and then import it into a database. That can take hours. Actifio simply attaches the MDF/LDF files, creates a database and restores any logs (if needed) and brings the DB online. That's it. That will always take minutes to accomplish regardless of the size of the DB.
The value here is that you're not only doing very fast backups but also doing extremely fast recoveries for production environments, test & dev environments, QA, and other environments that might need a fresh copy of production data. All of the above can be scheduled or run on-demand so that DBAs have full control over what's going on in their environment. There's also a PowerShell module that yours truly maintains that helps to script tasks very easily using a restful API.
If you're not seeing what I described above in your environment, I'd recommend we get together on a webex and figure out why you're not seeing the benefits of our platform in the environment. I can also put you in touch with several customers to answer any and all questions you might have.
A quick run down of the features
Individual or Multiple DBs snapped simultaneously, or Instance level captures as well so that DBs are auto detected and auto protected. FCI, Always On, supported natively for capture and recovery. Archive log captures as well so that PIT for a database can be accomplished. Fine control of when a backup runs that the DBA can manage very easily through a self service UI or via API. Super fast recoveries for test/dev/staging/qa etc. Each point in time with Actifio can be virtualized to create multiple copies in various different environments without consuming any additional storage.
Thanks!
Anoop
April 3, 2017 at 7:07 am
Anoop,
I find it interesting that you say Actifio is basically faster in every way. On my test server both the log backups and daily snaps are taking longer than native log backups and daily differential backups. Actifio takes minutes where native SQL takes seconds. As for recovering a database, the test I did took about 40 minutes for a few mb database to mount a Y and Z drive and restore the database. I could have done a simple restore of the database in a couple minutes.
April 3, 2017 at 7:41 am
tsduke - Monday, April 3, 2017 7:07 AMAnoop,I find it interesting that you say Actifio is basically faster in every way. On my test server both the log backups and daily snaps are taking longer than native log backups and daily differential backups. Actifio takes minutes where native SQL takes seconds. As for recovering a database, the test I did took about 40 minutes for a few mb database to mount a Y and Z drive and restore the database. I could have done a simple restore of the database in a couple minutes.
Hi tsduke,
Is the few MB database a good representation of the environment? What do the times look like for a larger database? Say 10s of GB? For DBs that are only a few MB, there's very little to actually backup and the changes are probably slim to none.
I'd also be interested in seeing the process you're doing to recover the data. Can we perhaps discuss this over a webex? 40 minutes is a really long time for any kind of Actifio recovery.
Thanks.
April 3, 2017 at 7:51 am
tsduke - Monday, April 3, 2017 7:07 AMAnoop,I find it interesting that you say Actifio is basically faster in every way. On my test server both the log backups and daily snaps are taking longer than native log backups and daily differential backups. Actifio takes minutes where native SQL takes seconds. As for recovering a database, the test I did took about 40 minutes for a few mb database to mount a Y and Z drive and restore the database. I could have done a simple restore of the database in a couple minutes.
This is my experience of it too, although I haven't used it much yet.
Viewing 15 posts - 1 through 15 (of 15 total)
You must be logged in to reply to this topic. Login to reply