April 10, 2016 at 9:39 am
Out infrastructure department is looking at using Asigra backup software for use in backing up our servers. This would include our SQL servers.
In the past we have looked at some third party backup software tools, but have always reverted to using the native SQL Server backups for full and transaction log backups.
Has anyone experience with using the Asigra SQL Server backup software? What good points/advantages/disadvantages/problems have you encountered?
Thanks
April 10, 2016 at 11:50 am
I have no experience with Asigra at all, but I'm a fan of using native SQL backups. That's what we use and they haven't failed me yet.
April 10, 2016 at 2:30 pm
Ed Wagner (4/10/2016)
I have no experience with Asigra at all, but I'm a fan of using native SQL backups. That's what we use and they haven't failed me yet.
Ditto that. I'll also add that I've found no particular advantage to using 3rd party backup software. The disclaimer there is that I've also not had to maintain a hundred systems like some folks. It may help there but I don't know for sure.
--Jeff Moden
Change is inevitable... Change for the better is not.
April 11, 2016 at 5:44 am
I also much prefer native backups.
April 11, 2016 at 6:50 am
Also no experience with Asigra backup.
However, I can tell you one thing about ANY third party backup, make them do a restore. Make them do a point in time restore. If they can't successfully do both these tasks without error and with little or no increase in the amount of time it would take you do them using native backups, then toss the tool. If they pass these tests, meet your RPO & RTO, and improve your management in some manner, go for it.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
April 11, 2016 at 11:04 am
How big are your databases?
I'm a big fan of native compressed SQL backups to disk or a shared NFS which is the subsequently backed up for redundancy.
However, some databases are big enough to make that not an option. In such cases I've had success with: SnapManager for Microsoft SQL Server
I hope that is somewhat helpful. I've never heard of the product you're using.
April 11, 2016 at 1:18 pm
I have no personal experience with Asigra, but I have worked about a year for a company that offers backup solutions based on one of their competitors (Ahsay). I assume that Asigra works more or less the same, but you should double check. I worked as DBA/developer on their own database backend, not in the sales or support process, but I do know a bit about the product both from the work I did and from them using it for their own backups as well.
How Ahsay works is that it makes SQL Server do a native backup, then copy that backup to the offsite storage and remove the backup file from the server. The backups are done using standard T-SQL so you can find information in msdb, however the backup files are not there so you cannot script a restore from SSMS and run it. I never tried a restore through the Ahsay UI. I once needed to create a copy of a production database, for which I first had to ask the sysadmin to copy the backup file from remote storage to a local drive and then I could restore from it.
My gut feeling is that Ahasy, and probably Asigra and all similar products, are ideal for small shops that do not have sufficient SQL Server knowledge. The backup and restore process can be done through the UI, probably at the expense of a lot of options. (I do know that Ahsay has support for both simple and full recovery. I also know that tech support at that company where I worked told their customers to just use simple, "because full is too hard to set up". (Which in the case of most of their customers is probably true).
For companies with SQL Server-savvy people, it's less ideal. I never liked the backup process at that company much, and if I had stayed there longer I would probably have pushed to let me handle backups to local storage, and let Ahsay do backups from there (without deleting the files, just like it handles all files system backups). That would allow me more flexibility and independence, and I would have only needed to access the offline storage when a volume is actually lost.
All that being said - these offsite backup solutions actually offer a very good deal - most of the time they offer the security of offsite storage, making a restore possible ever after losing an entire data center, for a fraction of the cost of any "home-brew" offsite storage.
April 11, 2016 at 2:09 pm
I have been using Asigra for a little over 2 years. I like the interface and think it's pretty streamlined and to the point. Not only that, it's Cloud-based. You have the option to also save a local copy for speed and in case something happens to the cloud site.
The SQL Server backup allows you to run a DBCC before each backup, stop on DBCC errors and also backup transaction logs. These are all optional. You have a few database dump policies are well for a full dump: always, differential or incremental. you can also choose to backup the pipe or buffer. Buffer will save locally. Pipe will not take additional space. It will read from the pipe on the source db. If you db is too big to be dumped to a file on either the db server or the buffer.
I have never had to restore a db as of yet, but the process is pretty simple. It lets you restore any day (of course) and each db associated w/the db, i.e. master, model, instance... etc...
One great feature is retention. You can setup for as much or little copies of the data you want. Now if you are worried about filling your storage, Asigra uses block-level technology, meaning when you backup every night, you will only backup changes made to the data, not the whole db/file. This also goes for if you already have the same system files for other database backups. It is smart in the fact it only keeps 1 copy of files.
Hope this helps!
April 11, 2016 at 5:45 pm
gdrummer83 (4/11/2016)
I have been using Asigra for a little over 2 years. I like the interface and think it's pretty streamlined and to the point. Not only that, it's Cloud-based. You have the option to also save a local copy for speed and in case something happens to the cloud site.The SQL Server backup allows you to run a DBCC before each backup, stop on DBCC errors and also backup transaction logs. These are all optional. You have a few database dump policies are well for a full dump: always, differential or incremental. you can also choose to backup the pipe or buffer. Buffer will save locally. Pipe will not take additional space. It will read from the pipe on the source db. If you db is too big to be dumped to a file on either the db server or the buffer.
I have never had to restore a db as of yet, but the process is pretty simple. It lets you restore any day (of course) and each db associated w/the db, i.e. master, model, instance... etc...
One great feature is retention. You can setup for as much or little copies of the data you want. Now if you are worried about filling your storage, Asigra uses block-level technology, meaning when you backup every night, you will only backup changes made to the data, not the whole db/file. This also goes for if you already have the same system files for other database backups. It is smart in the fact it only keeps 1 copy of files.
Hope this helps!
Just a suggestion, test a restore as soon as possible. You don't want to be in an emergency situation doing restores for the first time.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
Viewing 9 posts - 1 through 8 (of 8 total)
You must be logged in to reply to this topic. Login to reply