patternsqlModerate
Alternatives to Network Backup
Viewed 0 times
alternativesnetworkbackup
Problem
In our environment we have some servers that are in an Always On Availability Group, and some that are standalone.
We normally backup to a network share, but we have recently observed that as the databases are growing bigger the time taken is getting longer, which slows down the whole network.
Ola hallengren's script is being used with compression and also splitting the backup files. I am only performing daily "full" backups. The backups are going to the network share EMC isilon drive.
I am never comfortable with EMC DD Boost. The only alternative is to do a local backup and then copy to the same network share.
Is there an efficient way other than the above?
We normally backup to a network share, but we have recently observed that as the databases are growing bigger the time taken is getting longer, which slows down the whole network.
Ola hallengren's script is being used with compression and also splitting the backup files. I am only performing daily "full" backups. The backups are going to the network share EMC isilon drive.
I am never comfortable with EMC DD Boost. The only alternative is to do a local backup and then copy to the same network share.
Is there an efficient way other than the above?
Solution
There are ways to tune backups by messing with different knobs like MAXTRANSFERSIZE or BUFFERCOUNT, or striping the file (which you've noted you're already doing).
The problem is that touching those knobs may still result in hitting the limits of your network and/or storage, and them not having any real impact on backup time.
Your first job should be to benchmark the storage you're backup up to using Crystal Disk Mark or DiskSpd. That'll give you some idea of how fast you can expect writes to be at their best.
The next thing you need to test is reads from the drives you're backing up from. If you run a backup to NUL, you can time how long it takes just the read portion of your backup, without having to write it to disk.
With both those numbers in mind, you can start messing with other knobs to see which ones get you closest to them, regardless of if your backup target is local or networked.
The problem is that touching those knobs may still result in hitting the limits of your network and/or storage, and them not having any real impact on backup time.
Your first job should be to benchmark the storage you're backup up to using Crystal Disk Mark or DiskSpd. That'll give you some idea of how fast you can expect writes to be at their best.
The next thing you need to test is reads from the drives you're backing up from. If you run a backup to NUL, you can time how long it takes just the read portion of your backup, without having to write it to disk.
With both those numbers in mind, you can start messing with other knobs to see which ones get you closest to them, regardless of if your backup target is local or networked.
Context
StackExchange Database Administrators Q#246372, answer score: 15
Revisions (0)
No revisions yet.