Jeff Moden (8/24/2016)
BTW... if the table isn't critical to a DR restore, you might want to simply move it to another database and add a synonym for it. That would allow it to be backed up on a different schedule that the rest of the original database and allow restores to a Dev box to occur more quickly. If you keep an empty copy of the table in the original database as a standby, you could restore the original database and just repoint the synonym at the empty table and Bob's your uncle. I AM in the process of doing just that with some of my larger audit tables, which make up about 70% of the total volume of my main "money maker". This will allow for much quicker "get back in business" DR restores for me.
A total restore of the entire database (and yes, I do test it regularly) takes on the order of 30 seconds. I do a full backup every night, a differential backup every hour and transaction log backup at :15, :30 and :45. Never had a failure yet, and I regularly 'restore' the most recent backup under another name to use as my development DB. This setup is not time-critical. One time a disk drive borked just as some of us were leaving town for several days for a conference. The solution was to shut down the server and deal with it when we came back. Remaining users simply did other work (of which there is plenty) for the few days I was gone. Came back, plugged in a new drive, let the RAID array put itself together overnight and the next morning, everything was like new. This is a very low-key environment. Correctness of data and having me available for quickies far outweighs any concern over things like percentage of uptime.