Sql-server – failed with the following error: “Write on ”…bak” failed: 27(error not found) BACKUP DATABASE is terminating abnormally

The Momentus XT is an "Advanced Format Drive" and I see that you are running Windows 7 SP1. If the drive runs 512e mode this can cause you a problem with SQL Server. This is because it can create sectors in some multiple of 512 byte boundaries, instead of always at 4096 bytes. (Your error was caused by a 6 * 512 byte sector.)

If that is the case, then you will need to take some corrective action. Microsoft has a blog post and a KB article for Windows 7 and Windows 2009 R2 on this issue which points on to other links.

http://blogs.technet.com/b/filecab/archive/2011/04/26/using-4k-sector-and-advanced-format-drives-in-windows-hotfix-and-support-info-for-windows-server-2008-r2-and-windows-7.aspx

http://support.microsoft.com/kb/982018

If this is your problem you may want to download the latest FSUTIL to investigate. http://www.microsoft.com/en-us/download/details.aspx?id=8903

This has not been the fix for everybody. In the MSDN forums I found a lengthy set of responses with various fixes. http://social.msdn.microsoft.com/Forums/sqlserver/en-US/5c090e72-e83d-4fca-a087-75a3df5d2b4f/localdb-cannot-start-strange-error-in-log-contains-sector-size-4096-and-is-now-on-a-volume-with

From this discussion you will see that some finally resolved their problems by updating drivers.

Speaking as someone who has taken over from multiple third parties who have done NetBackup database backups you can safely assume three things.

• Many of your servers and individual databases have not been backed up. You would do best to confirm yourself through msdb checks.
• The "tapes" being backed up to are probably not accessible, do not work, or otherwise don't exist.
• You can probably find a lot of NetBackup failure notifications in ErrorLog which have been ignored for days, months, and years.

Regarding your specific situation backups are meant to be taken to network shares and backing up to the same server is wrong. What is going to happen when your server VM crashes or becomes corrupt? You've lost all your backups.

Whatever security / audit issues have come up are obviously wrong and you should be rallying against them. Or - print out your ironclad disclaimer and get your manager to sign it - because they're going to be fired down the line when they lose everything and you don't want this to destroy your career along with their poor decisions.

Best practice? A network share like you mentioned, and standardise on Ola Hallengren's scripts like others mentioned.

Don't be afraid to modify the setup script a little (or add your own to run afterwards) to set up the jobs the way you like them and to schedule them; you can also stagger them server by server if you like to spread the load. I wrote a corresponding script in PowerShell to help do the deployments (create a folder on each server to store the output text files; grant the service account access; create the network folder and grant the service or network account access; then deploy the jobs in the way we want them and with appropriate schedules).

You should also prioritise setting up your registered server list so that in the mean time you can run mass checks of msdb catalogs to make sure you haven't missed anything.

Network and CPU going high doesn't mean anything unless it impacts Production; the only important thing aside from gigabit network interfaces is that the network share is somewhere relatively close to whatever network segments you have. And the initial FULL backups will always be an issue, that's why they're scheduled for weekends, then daily DIFF will be fine.

Otherwise the only databases where this really becomes a problem are when they start going over 1TB (especially if it's much higher, 5TB, 20TB) and those need special attention.