sql backup to avamar

Question

sql backup to avamar

Viewing 11 posts - 16 through 25 (of 25 total)

You must be logged in to reply to this topic. Login to reply

windba1 Valued Member Points: 67 More actions · Answer 1

How's EMC Avamar for SQL backups? Researching issues, concerns on this product in real DBA world. Environment is heavy I/O, physical sql servers with clusters on SQL 2008R2.Any input is highly appreciated. Thanks.

matjcyr Old Hand Points: 320 More actions · Answer 2

I'd suggest to backup to a local disk and have EMC back that up, clearing the local backups to purge every 2-3 days or so, whatever your space will allow you to save. Worst case, you have to restore at the file level, then run a restore from the file level.

ganci.mark Hall of Fame Points: 3533 More actions · Answer 3

I have been using avamar for SQL about 2 years. Initially we used the Avamar with the built in grid storage.

We didn't use the avamar scheduler to run SQL backups but used our enterprise scheduler to run batch scripts on each SQL client. Avamar has a Command Line interface in addition to the GUI. Our environment consists of SQL 2005 on Server 2003 to SQL 2012 on Server 2012 and everything in between.

For almost two years we experienced issues where the backup executables would hang and not complete. This required us to have to kill the processes and restart. This could happen couple times a week or a night.

Recently we migrated the storage off of the avamar grid to our Data domain storage. The ablility to do this was a recent addition to avamar software. After doing this the performance is much better and the hangs seem to have disappeared.

I only perform FULL backups using avamar. I use native scripts for the transaction log backups and back them up directly to our Data Domain.

Let me know if you have any other questions.

Thanks

Mark

ErrLog Ten Centuries Points: 1040 More actions · Answer 4

This is an old thread but I just thought I would post my comment:

I just had a discussion with our SAN Admin and I told him that my team leader won't listen to me anyway but we are probably wasting space backing a SQL backup directly through Avamar. We have a 150 GB database and through native compression it gets down to 33 GB if we do it locally. SAN Admin mentioned that he "doesn't worry" about space because of the dedup functionality - so according to him Avamar backups a 150 GB file but then after, the dedup tool come into picture and it shrinks the file by comparing it to the previous day backup file. :w00t:

Restore scenario - From SQL, if we take a differential backup, it won't be of any use if the full backup is lost. In Avamar, it doesn't save the whole file every time, but when you try to restore, it "somehow" know of the "FULL" (the first file) even though through the dedup it only stores the "differential" changes. How does this actually work?

I appreciate your response.

ganci.mark Hall of Fame Points: 3533 More actions · Answer 5

Hello.

As I understand it the dedup in Avamar is based on your entire backup pool.

So it will use deduplication not only based on the database being backed up but also it can use data from another database not even on that server or platform. This makes it more powerful. So if you have 5 Full backups in Avamar, you really only need to know that you have 5 full backups. In the Avamar Admin Console it will show 5 different full backups while on disk or storage it does not store 5 times the database size. Avamar uses some complex algorithms and processes to store the data in a deduped and compressed fashion leverage data that it already has matching data you are backing up. I hope this helps. Please let me know if you have other questions.

Thanks

Mark

ErrLog Ten Centuries Points: 1040 More actions · Answer 6

Thanks, Mark.

Yes, when I check through the Avamar console (we have read access, YAY) - it indeed shows the similar size for all the previous backups. So basically you are saying that on the storage system it won't necessarily have the size that is displayed in the console. One last question - Is it possible to actually compare the size that show in the console vs the storage disk for any given file ?

ganci.mark Hall of Fame Points: 3533 More actions · Answer 7

I think depending on the version and level of access you can see on one of the admin screen percent free of the entire allocated storage whether Grid storage or other like the DD990 like we use.

As for individual files (databases) I don't know. I will ask our storage admin if we can drill to file level or domain level.

Also there is an "Activity" tab in the admin console that shows the backups , restores and replications. It details the Size of the back with percent new.

So we have a database that is 1.8 TB and the full backup might show 1.8 TB with "2% new".

(That's 2% of 1.8TB or 36GB that actually crossed to the storage)

What version are you using?

we have 7.1 server with mostly 7.1 clients.

Mark

ErrLog Ten Centuries Points: 1040 More actions · Answer 8

Awesome. Yes, we use 7.1.1 also - in the activity monitor I just verified for a 743 GB database the "New Bytes" column shows 7.4% - so on the storage end it probably used only 54 GB of "actual space". Interesting how this all works - so when Avamar takes the SQL database backup it stores the whole 743 GB until the comparison is complete and then releases the space.

I will bug our SAN Admin too to see if he can spot the individual files, in this case the 54 GB file.

Thanks for your help on this.

ganci.mark Hall of Fame Points: 3533 More actions · Answer 9

There are dedup processes that happens on the client that doesn't require the entire database to be sent to the Avamar Storage. So when you see 7.5% new, only that 7.5 % was transferred , not the whole thing.

This is great for network traffic also and overall performance. Our 1.8 TB takes only 1.25 hours to backup using only 6 Threads and 1GB Ethernet. (If Avamar is using DDBoost and Data Domain for storage, up to 10 Threads are available)

That is because it is only sending non duplicate data. Of course the first time you back it up it would take longer, but not as long as you think because the deduplication is system wide, meaning any data even from other servers/databases can be used in your database backup.

One thing to watch is client server resources. During backups make sure you are not using all the RAM or filling up one of the local drives where temp files are created.

My storage admin is looking for the process to determine specific "file" or domain storage sizes.

He said he thinks there is a way but it may not be that simple.

Additional Info: (added 11:49am)

Our Avamar/storage admin directed me to the builtin reports to drill into some details.

The reports are in the avamar admin console under Tools - Manage Reports. You will need admin level permissions to access. two reports that may help drill into some details you will be interested in are Misc STATS1 and DPN Summary.

I hope these help.

Regards

Mark

ErrLog Ten Centuries Points: 1040 More actions · Answer 10

ErrLog

Ten Centuries

Points: 1040

January 30, 2016 at 4:22 pm

#1855536

Thank you so much for the information.

peter.lafay Grasshopper Points: 17 More actions · Answer 11

Avamar Version 7.2.1.32 w/Avtar
SQL Server 2008 R2 & 2012 Enterprise Versions

I realize this is an old thread, but after reading several posts I felt compelled to chime in on our experiences with this product if for nothing else then to vent a little.

1. Doesn't handle multiple backup requests on the same instance. This is particularly an issue if you have multiple instances on a single server (clusters, 2008 R2/2012, etc...). For example, if you run a backup on Instance A, then try to run a backup on Instance B while Instance A is still running Instance B will fail.
2. Other backup processes affect performance. For example, we replicate backups from our primary local Avamar server to a DR facility with a second Avamar server. Replication runs for 18-19 hours and never completes. What is worst, when replication, tape backups, or any other type of non-SQL backup is running, it negatively affects the backup/restore times of my SQL backups with Avamar to the data domain.
3. Speed difference between Native and Avtar with Avamar is negligible. None of our databases are large, nothing over 500GB. When other processes are running on Avamar, backup times are longer than Native.
4. My experiences with EMC support for this product have been dismal & depressing. There only seem to be one or two guys who know their stuff but finally obtaining one of them is difficult and typically very time consuming.

I have other complaints, those are my top 4. My recommendation would be to stay away from this product if at all possible.