Blogs

Chaque année, je rappelle à notre clientèle de ne pas oublier d’inclure les nouvelles bases de données dans leurs processus de sauvegarde. Le système avec lequel je travaille dispose chaque année d’une nouvelle base de données. Il s’agit donc d’une quantité importante de données, d’autant plus si on y ajoute les environnements de tests, de développement ainsi que les sauvegardes journalières ou hebdomadaires.

Dans la période sans précédent que nous traversons, on court davantage le risque que des utilisateurs se mettent à créer des bases de données sans l’autorisation des responsables des sauvegardes.

Cette période de l’année offre aussi l’occasion de se demander quelles sont les anciennes bases de données qui doivent être conservées. Des bases de données peuvent-elles être mises hors connexion voire supprimées pour améliorer la performance des systèmes ? Peut-être le fait de retirer des données désormais redondantes des années précédentes pourrait compenser quelque peu l’ajout de données aux sauvegardes journalières ?

Toutes les semaines, j’avais des problèmes d’espace de stockage sur les supports physiques dont nous disposions et me demandais constamment d’où provenait le flot incessant de nouvelles bases de données. Ces temps-ci, je suis en télétravail, comme le sont les autres utilisateurs ; je sais donc encore moins quand ou pourquoi une nouvelle base de données est soudainement apparue. Comment savoir quelle base de données est temporaire, laquelle doit faire l’objet d’une sauvegarde et à quelle fréquence ? Même si nous disposons de technologies conçues spécifiquement pour gérer les sauvegardes, la difficulté est de savoir quelles données doivent être sauvegardées et pour combien de temps. Les utilisateurs et les administrateurs système ont donc toujours leur rôle à jouer.

Le manque d’espace sur les serveurs est un autre problème auquel nous sommes confrontés. Il arrive qu’une base de données soit créée avec des options qui ne reflètent pas la stratégie de sauvegarde en vigueur. On trouve un exemple dans les journaux des bases de données, qui sont utiles pour rétablir une base de données jusqu’à un point précis dans le temps. Si on procède à une récupération suite à une défaillance générale du système, la base de données pourrait être rétablie jusqu’à un certain point précis en se basant sur les données du journal dont nous disposons. Qu’en est-il toutefois si une différente stratégie de sauvegarde nous permet d’effectuer cette même tâche en utilisant un mécanisme différent ? Nous n’aurions alors plus besoin de ces journaux. Sans gestion appropriée, les fichiers journaux peuvent accaparer beaucoup d’espace disque sur un serveur et pourraient finir par le bloquer. Je tremble en y pensant car mon expérience m’a montré que ces blocages se produisent, hélas, bien trop souvent.

Cela me mène à un autre sujet – la récupération d’urgence. Que faire si le pire se produisait ? Quels sont les systèmes qui sont essentiels à nos opérations ? Combien de données pouvons-nous nous permettre de perdre ?

Il s’agit d’une conversation importante à tenir avec les utilisateurs. Nous avons tous l’habitude de saisir des données, d’apporter des modifications à des documents et à des bases de données et nous nous attendons naturellement à ce que, si une défaillance du système devait survenir, nos données ne soient pas perdues. Le problème est qu’on ne dispose pas toujours de la technologie ni du matériel nécessaires, et même si c’était le cas, toutes les données ne seront pas nécessairement conservées.

Par exemple, le système que j’utilise le plus est une application de planification de cours et de réunions. En temps normal, un utilisateur apporterait des modifications aux données puis, à certains périodes de l’année, telles que maintenant, il produirait l’emploi du temps des cours de l’année à venir. Le nombre de données qu’il pourrait se permettre de perdre dépendra du système et de la base de données dont il s’agit. Pour certains systèmes, c’est la survie de l’organisation qui serait en jeu

J’aimerais terminer ce blog par une liste de recommandations issues de ma propre expérience. La liste prend aussi en compte la situation actuelle, qui rend encore plus difficile la communication entre les administrateurs système et les utilisateurs. Vous jugerez peut-être opportun de vous poser les questions suivantes :

• Les utilisateurs sont-ils en mesure de créer de nouvelles bases de données ?
• Comment contrôler la taille de vos sauvegardes ?
• Quelles sont les bases de données qui pourraient être mises hors connexion voire supprimées ?
• La journalisation des bases de données est-elle nécessaire, et si oui, comment la gérer?
• Quels nouveaux aspects du système ont été mis en service et quel impact auront-ils sur le nombre de données ?
• Quand avez-vous revu pour la dernière fois votre plan de récupération d’urgence ?
• Y-a-t-il des systèmes qui sont devenus plus urgents depuis la dernière vérification ?
• Pour chaque système, combien de données pouvez-vous encourir le risque de perdre ?
• Testez-vous régulièrement la récupération de vos bases de données à partir des sauvegardes ?