Sql backups and multiplexing

[mitsuman]

Is anyone aware of the best practices where database (sql) storage policies and multiplexing are concerned? I've seen where its recommended to have different storage policies for data types so once we have that, what are the recommended settings for databases and file systems?

 

[birky]

Hi

Going to disk or tape as primary for fs and db's?

Recomendation for different Storage Policies is because fs and db write in different chunk sizes...filesystem backups = 2Gb and databases = 8GB...doesn't really make a difference whenwriting to disk for both but, could make a difference when mixing them onto the same tapes through using same SP.

 

[mitsuman]

Thanks Birky, the primary target is tape. I guess its just a matter of figuring out if its better to multiplex sql jobs but if we separate them (fs and db) onto different tapes by adjusting schedules and media pools we don't have concurrent writes so they won't land on the same tapes anyways. So, what is the best for sql, multiplex or not?

 

[birky]

I just usually leave db's as is and not multi stream them...you should see good thruput anyway.

 

[ARSponger0]

multiplexing decreases your backup time, and increases your restore time.

 

[birky]

not necessarily so ARSponger0...as long as you keep fs and db backups seperate then with CommVault you shouldn't see much difference with restore times because of the indexing method used.

 

[Frbutler]

I do disk staging of my SQL jobs with Aux to tape
0-streams to tape
2-Multiplexing to tape (just what I use)

10 streams to disk
0 Multiplexing to disk

You probably could match stream and multiplexing on tape with v6.1 without any degradation in restore times.

I backup about 500 - 600GB a night and run the aux the next day for offsite storage.

6.1 only backs up 1 DB at a time per subclient
In 5.9 I had 1 job per DB but it hammered the snot out of the SQL server when the tlog jobs ran every hour.

Nothing like kicking off 40 db backups all at once to bring a server to its knees