Il est assez souvent négligé par les administrateurs de systèmes SQL Server que le fait de donner un peu trop de droits aux gestionnaires applicatifs de bases applicatives peut être néfaste à la gestion de la sécurité des données. Notamment, le fait de distribuer à tout va les droits de sauvegardes de bases de données peut au final nuire au plan de sauvegarde global, et même le mettre totalement à plat.

SQL Server propose trois types de sauvegardes de bases de données :

• les sauvegardes complètes
• les sauvegardes différentielles
• les sauvegardes de journaux de transactions

Nous nous concentrerons ici sur les deux premiers types, et nous montrerons notamment un cas relativement simple dans lequel une sauvegarde mal maîtrisée peut empêcher une restauration de base de données normalement disponible d’après le plan de sauvegarde.

La sauvegarde complète, comme son nom l’indique, permet de faire une copie de l’ensemble des données telles que disponibles à l’instant t.

La sauvegarde différentielle contient les données modifiées depuis la dernière sauvegarde complète. Ainsi, si l’on effectue par exemple une sauvegarde complète tous les dimanches soirs et une sauvegarde différentielle tous les autres soirs de la semaine, chaque sauvegarde différentielle s’appuiera sur les données de la sauvegarde complète du dimanche précédent.

Ceci étant dit, supposons que l’administrateur du serveur attribue le rôle db_backupoperator (ou même le rôle db_owner) à un responsable applicatif. Ce responsable applicatif peut avoir besoin d’une sauvegarde de la base de données à un moment précis (par exemple lorsqu’un utilisateur lui signale un problème fonctionnel). Et sans forcément le savoir, il peut potentiellement mettre totalement à plat le processus de sauvegarde principal.

Ainsi, supposons que le mercredi en milieu de journée, le responsable fonctionnel réalise une sauvegarde complète de la base de données, dans le but de récupérer ce fichier de backup et de le transférer au support niveau 3 pour analyse. S’il n’applique pas de processus particulier, les sauvegarde différentielles planifiées automatiquement le soir s’appuieront jusqu’à la fin de semaine sur cette sauvegarde « sauvage ». Le processus standard de restauration, consistant à restaurer le backup complet du dimanche soir suivi du backup différentiel souhaité, ne sera donc plus valable pour cette fin de semaine.

Pour éviter ce genre de mésaventure, il convient de former les personnes habilités à effectuer des sauvegardes de bases de données à la sauvegarde « pour copie ». Ces sauvegardes enregistrent les mêmes données que les sauvegardes par défaut, à la différence près qu’elles ne viennent pas s’intercaler dans un cycle de sauvegardes complètes-différentielles.

Pour utiliser ce genre de sauvegardes, deux possibilités :

• soit via l’interface graphique de SQL Server Management Studio

• soit via une commande T-SQL

BACKUP DATABASE [Test]
	TO  DISK = N'C:\Program Files\Microsoft SQL Server\MSSQL11.MSSQLSERVER\MSSQL\Backup\Test.bak'
	WITH  COPY_ONLY
		, NOFORMAT, NOINIT,  NAME = N'Test-Full Database Backup', SKIP, NOREWIND, NOUNLOAD,  STATS = 10
GO

Et si la consigne n’arrive pas à passer, d’autres solutions sont toujours possibles, comme par exemple le fait d’enlever le droit de sauvegarde, et de le remplacer par l’accès à une procédure stockée qui fera l’opération comme il se doit…