what would be the right permission to allow everything else but overwriting or creating a database?

I have a test environment where the AD group mycompany\developers is currently sysadmin.

Recently I have had some issues, specially regarding to people restoring databases. My concerns are:

-
sometimes the database is involved in replication

-
the permissions are overwritten - the correct way is to save the
current permissions before the restore and re-apply them after the restore.

-
Have you checked the current available disk space in all drivers,
specially those used in this restore?

-
there might be other people using or working on that specific
database, and restoring over it without communication can cause
someone's else work being lost

-
in the dev environment the databases can be in simple recovery mode.
Have you shrunk the log and changed the database to simple recovery
mode.

-
in this particular case, the full backup for every user database is
going to run automatically every night. but anyways, have you
checked for scheduled backups?

-
have you deleted from the server the backup that you used to do the
restore?

-
the folders and drives or data and logs are different in live and
test. are you sure you moved the files to the right places?

-
Have you had a look at orphaned users and logins?

I particularly have concerns when developers create new databases, even in the dev environment. why?

because they start by creating the database in dev and then just ask me to copy it to live.
have you done any capacity planning for this database? how big it should be and how much it would grow in a month?

-
have you isolated or considered different filegroups for demainding
objects\indexes?

-
Have you checked the current available disk space in all drivers,
specially those used in this DB creation?

-
how big is the transaction log and why? Initially I like to set it
1.5 times the biggest clustered index.

-
what are the autogrowth settings?

-
what are the current permissions?

I have realised some people are not so easy to

TL;DR

In order to restrict the DEVs from doing anything "wrong" you have to at least remove the sysadmin SQL Server role.

Let's start

You could assign your DEVs the db_owner database role for each individual database. However that role will permit a user to perform a BACKUP DATABASE ... or BACKUP LOG ... which you mentioned you don't want them to be able to perform.

Solutions

Beginning with SQL Server 2014 you can then restrict a SQL Server Login with the db_owner role further removing individual privileges/permissions. One example is to remove the backup privilege on the database and transaction log level by issuing the following commands on the database:

USE 
GO
DENY BACKUP DATABASE TO 
GO
DENY BACKUP LOG TO 

Reference: DENY Database Permissions (Transact-SQL) (Microsoft Docs)

There are three levels of permissions.

GRANT  : You are granted/granting a specific permission  
REVOKE : A previously granted/denied permission is revoked (removed) again  
DENY   : You are denied/denying a specific permission

Alternative

Now because DENY has precedence over GRANT you could use the alternative solution of creating a new database role and adding the ` to that role:

USE 
GO
CREATE ROLE [deny_backup]
GO
DENY BACKUP DATABASE TO [deny_backup]
GO
DENY BACKUP LOG TO [deny_backup]
GO
EXEC sp_addrolemember N'deny_backup', N''
GO

Reference: Restrict Backup permission to user (Social MSDN)

Step by Step Guide

Because some people are sceptical about statements I have made in this post, I am adding the individual steps to show you how you can indeed DENY permissions from a SQL Login even though that login has the db_owner role.

-
Creating and Mapping SQL Login

Let's create a SQL Login and assign it the db_owner database role:

-
Deny Backup Database permissions

Now we switch to a higher privileged account like sa or a Windows Login (which would be you, the DBA asking this question) that has the sysadmin SQL Server role and DENY the right to backup database from the database principal hot2use:

In a perfect world you would also need to submit a DENY BACKUP LOG TO hot2use too.

-
Log in to server with hot2use and back up database

Seeing as hot2use has the db_owner database role for the Test database, we log in with hot2use...

...and try to back up the database:

Well that doesn't work and is what we expected. This is because the SQL Server login hot2use no longer has the privilege to back up the database even though the login still has the database role db_owner:

-
SQL Login wants to hack permissions

Seeing as the SQL Server login has the db_owner role and according to some people he can assign himself the permissions back, let's try that out:

(The test was conducted in a fresh database SQL Server Query window)

-
Summary

If you DENY permissions with a higher privileged account, then these privileges can not be GRANTed back from the lesser privileged account, even thought the SQL Login (e.g. hot2use) should have these privileges from the database role db_owner. This is something that changed in SQL Server 2014 (yes, the tests were conducted on a SQL Server 2014 instance).

Additional ressources

You can further restrict permissions according to the official overview which can be found here:

Permissions (Database Engine)

Further recommended reading:

Getting Started with Database Engine Permissions

Wait, restores...

Oh yes, we only denied the BACKUP DATABASE privilege didn't we? That has nothing to do with RESTORE DATABASE, or does it? Let's find out. I'll create a database backup with a higher privileged account/login:

Seems to work. Let's switch back to the hot2use SQL Server Query window and restore the backup:

As you can see, it isn't going to work, because the BACKUP DATABASE privilege also restricts the restore capability of that SQL Server login.

No backup privilege = No restore privilege.

How about DENY BACKUP DATABASE FROM SYSADMIN?

Well, since you asked. Let's try it out. I'll leave out the screen shots that show how I revoked the database role.

I assigned the SQL Login the sysadmin SQL Server role with:

ALTER SERVER ROLE [sysadmin] ADD MEMBER [hot2use]
GO

...and then removed the permission to backup the database with the above mentioned DENY BACKUP DATABASE.. commands and then performed a database backup with:

backup database Test to disk = 'C:\temp\Test_Full_Backup_20171121.bak'

... which resulted in:

So you can't DENY permissions from a SQL Login with the sysadmin Server role, but you can DENY permissions if the SQL Login does not have the 'sysadmin' database role.

Minimal permissions required to backup / restore a database

If I assign the SQL Server login absolutely no SQL Server roles and assign only the db_backupoperator` database role on a given database, then I can backup and restore the database. This is something that others believe the SQL login is un

StackExchange Database Administrators Q#191391, answer score: 3