Yes, this is a very valid way of doing it. One of the things I love about EXECUTE AS is being able to make stored procedures to do things that users wouldn’t normally have access to.

Rob

Using copy_only:
Create a stored procedure and give execute permissions to the developer group. Next when you create the stored procedure include execute as self in the create script so the stored procedure can run backups. This way developers dont need sysadmin or db_backupoperator rights and can still run backups. I have the sproc outputting backups to a share that the developers have access to.

Ok, so put “Junior DBA” in there instead of “Developer”. I’d expect that a junior DBA would at least have db_backupoperator rights.

The situation still applies. A backup which might seem safe can still wreck the restore sequence, but this can be avoided using COPY_ONLY.

Rob

BACKUP DATABASE and BACKUP LOG permissions default to members of the sysadmin fixed server role and the db_owner and db_backupoperator fixed database roles.

So, you are okay with developers having SYSADMIN or db_owner of DBs in production?

“It’s not a new option (it just wasn’t part of the dialog box)…”

You need to put “WITH COPY_ONLY” on your backup.

Rob