1. Dresser la liste des sinistres

d’entreprise.
Je place toujours cette étape en premier
parce que, en gardant ces possibilités
à  l’esprit, il sera plus facile de
choisir la manière de conduire les
autres stratégies que je suggère.
Après avoir planifié en vue des – ou
au moins avoir pris en considération –
les pires sinistres possibles et avoir déterminé
les actions possibles pour réduire
le risque, évaluez le ratio
coût/avantage de ces actions. Si la protection
de vos données contre un
événement catastrophique mais très
peu probable – comme la chute d’un
météore – coûte beaucoup d’argent,
vous pouvez décider de courir le
risque en ne vous protégeant pas
contre cet événement. Documentez
votre décision afin que les collègues et
les successeurs sachent que vous avez
au moins envisagé l’éventualité. Mais
vous pourriez bien découvrir que la
protection de vos données contre des
événements à  faible probabilité ne
coûte pas très cher. Par exemple, vous
pourriez déjà  stocker des sauvegardes
de la base de données à  l’autre bout de
la ville, mais qu’adviendrait-il si le météore
détruisait toute la ville ? Si votre
société envoie déjà  des sauvegardes
régulières pour un autre système ou
une autre application à  une autre ville,
le fait d’ajouter des bandes à  vos sauvegardes
SQL Server à  cet envoi peut
constituer un coût négligeable. Donc,
si la probabilité d’une chute de météore
est infime, le coût de sauvegarder
vos données en prévision de cet
événement improbable est lui aussi
minime.
Dans la liste des sinistres possibles,
il ne faut surtout pas oublier la terrible
« erreur d’utilisateur ». Les erreurs
d’utilisateurs peuvent être les sinistres
les plus difficiles à  prévenir et ceux
dont la reprise est la plus longue. Un
utilisateur peut accidentellement supprimer
des lignes de données, des
tables, ou toute une base de données.
Avec SQL Server, il est facile à  des
utilisateurs munis de hauts niveaux de
privilèges, de provoquer de gros
dégâts. Bien que l’intégrité référentielle,
le schéma binding et les déclencheurs
puissent aider à  prévenir la suppression
de lignes ou de tables par
inadvertance, SQL Server offre bien
peu de protection contre la destruction
d’une base de données entière.
Contrairement aux précédentes
releases de SQL Server, dans lesquelles
la commande DROP DATABASE ne
supprimait pas réellement les fichiers
physiques du système de fichiers,
quand vous transférez une base dans
SQL Server 2000 et 7.0, SQL Server
supprime les fichiers disque contenant les données, donc la base de données
a vraiment disparu.
Les utilisateurs peuvent aussi créer
le chaos en appliquant la mauvaise procédure.
De nombreuses procédures
ont des noms similaires et si, par suite
d’une erreur de frappe, un utilisateur
ou une application appelle la mauvaise,
vous risquez de ne constater les
dégâts que plus tard. Vous perdrez davantage
de temps pour traquer le problème
et encore plus de temps avant
de commencer à  le corriger et à  redresser
la situation.
Bien sûr, une sécurité inefficace ne
peut qu’alimenter les erreurs d’utilisateurs.
Des mots de passe faibles ou
non existants, trop d’utilisateurs disposant
de trop de privilèges, tout cela est
dangereux pour l’intégrité du système
et des données. Des suppressions accidentelles
sont également plus probables
quand les niveaux d’autorisation
accordés aux utilisateurs sont
excessifs.