Limitazione degli utenti alla COPIA SOLO di backup

Sto cercando di distribuire il log shipping nel mio ambiente di produzione. Ciò significa che dovrò gestire catene di backup che potrebbero essere interrotte da persone che eseguono backup per aggiornare gli ambienti di sviluppo. Se ho un errore e desidero utilizzare i backup del log per ripristinare in un determinato momento, avrò bisogno anche del backup eseguito dallo sviluppatore.

Ciò non accadrebbe se gli sviluppatori usassero solo backup SOLO COPIA. Quindi la mia domanda è: esiste un modo per limitare gli utenti a poter eseguire solo backup COPIA SOLO?

Non è necessario che vengano utilizzati COPY_ONLY. Solo un intermedio LOG BACKUPSromperà il LSN. Quello che puoi fare è esplicitamente DENY BACKUP LOG to [user|group]privilegiare gli sviluppatori o il gruppo di sviluppatori. In alternativa, basta creare un RUOLO e negare il registro di backup a quel ruolo. Quindi tutti gli utenti in quel ruolo erediteranno le autorizzazioni.

per esempio

USE test_kin
GO
CREATE ROLE [deny_log_backups]
GO
USE [test_kin]
GO
CREATE USER [Kin] FOR LOGIN [Kin]
GO
ALTER USER [Kin] WITH DEFAULT_SCHEMA=[dbo]
GO
use test_kin
GO
DENY BACKUP LOG TO [deny_log_backups]
GO
USE test_kin
GO
EXEC sp_addrolemember N'deny_log_backups', N'kin'
GO

Ora provalo:

backup database [test_kin]
to disk = 'C:\crap_test\kin_test_full.bak'
with compression, stats =10, init

---- ### success for FULL BACKUP 

backup log [test_kin]
to disk = 'C:\crap_test\kin_test_log.log'

 --- $$$ ERROR MESSAGE 

Msg 262, Level 14, State 1, Line 3
BACKUP LOG permission denied in database 'test_kin'.
Msg 3013, Level 16, State 1, Line 3
BACKUP LOG is terminating abnormally.

Bella domanda per la quale non riesco a trovare una buona risposta, ma eccone una. Che cosa succede se hai rimosso tutti dall'avere il ruolo di backup e poi hai creato un'attività che ha utilizzato il comando execute per un utente specifico che elimina il file di backup copy_only in una posizione specifica?

Quello che potresti essere in grado di fare è 1) negare i backup (log e / o completi) a tali utenti ma comunque 2) consentire loro di avviare un processo che esegua il backup di sola copia di un database specifico (in esecuzione con un account concesso permesso di backup). Ho una tale soluzione in atto per automatizzare una PROD a PRE-PROD ripristini automatici di database a fini investigativi; utenti specifici hanno accesso a un lavoro (in PRE-PROD) che esegue un backup di sola copia in PROD, sposta il file da PROD a PRE-PROD e quindi ripristina il backup spostato sul server PRE-PROD. Assicurandosi così che tali utenti non abbiano modo di violare la logica di backup su PROD.

(Durante l'analisi dei problemi, gli sviluppatori potrebbero essere tentati di eseguire un backup completo per ripristinarlo su un server di prova spostando effettivamente il file dall'origine al server di prova senza sapere che stanno rompendo la logica di backup ... quindi sono d'accordo che forzare la presa della copia -solo i backup sono importanti.)