April 10, 2016 at 7:24 am
Jeff Moden (4/9/2016)
xsevensinzx (4/9/2016)
jay81 (3/31/2016)
Use Backup file Striping with the methods described in the below blog. I could reduce to backup times from few hours to with in an hour for large databases.Thanks for this!
Just be careful. Backup "striping" will make backups run slower if you happen to be backing all files up to the same physical spindle. Some sans will try to spread the load but (from what I've been told) that's not what it will always do.
To add to that, if you're backing up to a SAN that also has your SQL Server data/log files on it and you lose the SAN, your pretty much toast because no one keeps tape backups up to the second. Don't laugh... it happened to us two weeks ago. We were lucky that it was "only" a Dev system but we used the opportunity as a DR drill. The only good part about it was that I got to say "I told you so".
Oh, I understood that when reading the article. We're using NetApp and everything is virtualized. I have no dedicated IO from what I can tell. But, it's good to know for the future if I ever can ensure it's not on the same physical spindle.
On the other, I'm working with a data warehouse that is purely batch with data refreshes once a day in simple recovery. All LUNS and SQL Server are backed up by global IT daily. I also have a secondary physical DR array that was left over from a previous acquisition that is backing up the compressed backup files locally and in a private "cloud" for extra padding just because we can.
Like the OP, our database is over 1 TB, so it's always good to read techniques with restoring huge databases.
Viewing post 31 (of 30 total)
You must be logged in to reply to this topic. Login to reply