One of these days, I’ll automate the fire drill restore process so that each week it restores off the network share, but I haven’t quite gotten that ambitious yet. I acquired a pretty slow server with a huge number of internal drive bays, picked up a bunch of big drives off Ebay, and presto, I have a restore testbed.
![backup exec 16 server crash backup exec 16 server crash](https://aacable.files.wordpress.com/2014/06/b3.jpg)
Ask them to keep an eye out for leftover end-of-life servers in the shop that have enough internal drive space to do fire drill restores. Stay buddies with the system administrators. When the DBA team is separate from the backup administrator, just tell the backup admin that it’s a real restore need, like a developer lost something and needs it back from tape. Do regular fire drill rebuilds and restores.Īt least once a quarter, do a restore from tape. I want my backup guys to concentrate on getting the data to tape and getting it offsite rather than worrying about application problems. For example, if the nightly ETL jobs fail on a data warehouse, the DBAs can quickly pause the backup schedule or restore the databases without input from anybody else. I like having the control in the hands of the DBAs because they’re quicker to react to SQL Server problems. I steer clear of backup agents like Backup Exec, NetBackup and TSM because the schedules are generally dictated by the backup guys instead of the database administrators. Backup agents like NetBackup and Backup Exec mean giving up scheduling control. Before I started benchmarking, I’d expected my bottleneck to be my gig network cards, but it turned out to be a raid 5 SATA array.
#BACKUP EXEC 16 SERVER CRASH HOW TO#
I’ll write a separate article about how to monitor performance metrics during backups to determine where the bottleneck is. Raid 10 on SATA gets me the best balance of cost versus backup throughput. Raid 10 gives better write performance than raid 5, and while I’d love to have fiber channel backup drives, it’s cost-prohibitive. My sweet spot for the backup array is raid 10 SATA.ĭepending on the backup windows, multiple database servers may be writing backups to that same share simultaneously. The one reason it succeeded was because my backup array was on a different SAN than the production SAN. I was able to build new database servers using local disk & another SAN, and then restore databases & transaction logs from the network share. We had our production SAN go down for an entire weekend. This one’s not a reality for all shops, but it’s saved my bacon, so I have to mention it. 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.
#BACKUP EXEC 16 SERVER CRASH PLUS#
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.
![backup exec 16 server crash backup exec 16 server crash](https://www.builtbymike.ca/wp-content/uploads/2016/03/symantec800x1200.jpg)
Cost justify the network share with lower licensing costs & simpler backups. Disk backups, on the other hand, are always available.
![backup exec 16 server crash backup exec 16 server crash](https://www.windows-noob.com/forums/uploads/monthly_06_2011/post-8216-0-19649100-1308664374_thumb.png)
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.
![backup exec 16 server crash backup exec 16 server crash](https://nandusoftware.eu/media/catalog/product/cache/b6bf04180b70b7e04a910b7d9348c369/0/-/0-microsoft-visio-pro-2016.png)
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.