They don’t have to worry about what servers are on what schedules or when the peak loads are – they just have one easy task to back up that network share. Back up everything on that network share once a day, and get it offsite ASAP. Tell them that it pays for itself by eliminating the need for backup agents on each SQL Server, plus it simplifies their lives because they can just have one backup policy. The SAN & backup admins will need cost justification for a new dedicated array just for SQL backups.
Cost justify the network share with lower licensing costs & simpler backups. Disk backups, on the other hand, are always available. At our shop, if multiple people need to do simultaneous restores or backups, there can be a lag time of hours. When the DBA needs a restore right away, the tape drives aren’t necessarily sitting idle. However, there’s a limited number of drives available. Tape drives these days are fast enough that the vendors like to say DBAs should go straight to tape, and they’re technically right: tape backup & restore speed is not a bottleneck. In the event of a hardware disaster, I’ve been able to point to my junior guy and say, “Go build a new server and start doing restores from the network share while I try to resuscitate this server.” Back up databases to a fileshare, then back the share up to tape.
If the SQL Server crashes, especially due to a hardware problem or a severe OS problem, the local drives may not be available. I won’t address log shipping or snapshots this time around. All of this is my own opinion – your mileage may vary – but I’ll try to explain the reasoning behind the choices I make. I’ve been backing up SQL Servers for almost a decade now, and it’s time to share the lessons I’ve learned.
0 kommentar(er)
