La sauvegarde est prête : déconstruisons les mythes à l'occasion de la fête

La sauvegarde n'est pas une technologie à la mode qui se crie sur tous les toits. Elle doit simplement exister dans toute entreprise sérieuse, c'est tout. Dans notre banque, plusieurs milliers de serveurs sont sauvegardés – c'est un travail complexe et intéressant, et je souhaite parler de certaines subtilités à ce sujet, ainsi que des idées reçues typiques concernant les sauvegardes.

Je m'occupe de ce domaine depuis presque 20 ans, dont les deux dernières années – au Promsvyazbank. Au début de ma pratique, je faisais des sauvegardes presque manuellement, avec des scripts qui copiaient simplement des fichiers. Puis, des outils pratiques sont apparus sous Windows : l'utilitaire Robocopy pour préparer les fichiers et NT Backup pour la copie. Ensuite est venu le temps des logiciels spécialisés, en particulier Veritas Backup Exec, qui s'appelle maintenant Symantec Backup Exec. Donc, je connais bien les sauvegardes.

Pour simplifier, la sauvegarde consiste à conserver une copie des données (machines virtuelles, des applications, des bases de données et des fichiers) à intervalles réguliers pour une éventuelle récupération. Ce cas se manifeste généralement par une défaillance matérielle ou logique entraînant une perte de données. La tâche du système de sauvegarde est de réduire les pertes dues à la perte d'informations. Une défaillance matérielle, par exemple, est une panne du serveur ou du stockage où se trouve la base de données. Une défaillance logique se produit lorsque certaines données sont perdues ou modifiées, y compris en raison d'une erreur humaine : suppression accidentelle d'une table, d'un fichier, exécution d'un script défectueux. Il existe également des exigences réglementaires concernant la conservation de certains types d'informations pendant une longue période, par exemple, jusqu'à plusieurs années.

L'utilisation la plus typique des sauvegardes est la restauration d'une copie sauvegardée des bases de données pour déployer divers systèmes de test ou des clones pour les développeurs.

Autour de la sauvegarde, il existe plusieurs mythes typiques qu'il est urgent de dissiper. Voici les plus connus.

Mythe 1. La sauvegarde n'est plus qu'une fonction mineure au sein des systèmes de sécurité ou de stockage.

Les systèmes de sauvegarde restent jusqu'à présent une catégorie indépendante de solutions, avec une grande autonomie. Ils ont une mission trop importante. En effet, ils représentent la dernière ligne de défense en matière de sécurité des données. Ainsi, la sauvegarde opère à son propre rythme, selon son propre calendrier. Un rapport quotidien est généré pour les serveurs, et des événements agissent comme déclencheurs pour le système de surveillance.

De plus, le modèle de rôle d'accès au système de sauvegarde permet de déléguer une partie des autorisations aux administrateurs des systèmes cibles pour la gestion des sauvegardes.

Mythe 2. Quand il y a du RAID, la sauvegarde n'est plus nécessaire.

Certes, les matrices RAID et la réplication des données sont de bonnes méthodes pour protéger les systèmes d'information contre les pannes matérielles, et la présence d'un serveur de secours permet de basculer rapidement vers celui-ci en cas de défaillance de la machine principale.

L'excès et la réplication ne protègent pas contre les erreurs logiques commises par les utilisateurs du système. Un serveur de secours avec un enregistrement différé peut effectivement être utile si l'erreur est détectée avant la synchronisation. Et si ce moment est manqué ? Alors, seule une sauvegarde effectuée à temps pourra aider. Si l'on sait que les données ont été modifiées hier, on peut restaurer le système à son état d'avant-hier et en extraire les données nécessaires. Étant donné que les erreurs logiques sont les plus fréquentes, la bonne vieille sauvegarde reste un moyen éprouvé et indispensable.

Mythe 3. La sauvegarde est quelque chose qui se fait une fois par mois.

La fréquence de sauvegarde est un paramètre configurable, dépendant principalement des exigences du système de sauvegarde. Il est tout à fait possible de trouver des données qui changent rarement et qui ne sont pas particulièrement importantes, dont la perte ne serait pas critique pour l'entreprise.
Celles-ci peuvent effectivement être sauvegardées une fois par mois, voire moins souvent. En revanche, les données plus critiques doivent être sauvegardées plus fréquemment, selon l'indicateur RPO (Recovery Point Objective), qui définit la perte de données acceptable. Cela peut être une fois par semaine, une fois par jour ou même plusieurs fois par heure. Pour nous, ce sont les journaux de transactions de la base de données.

Lors de la mise en service des systèmes en exploitation industrielle, la documentation sur la sauvegarde doit être validée, détaillant les éléments principaux, le règlement de mise à jour, le processus de restauration du système, les modalités de stockage des sauvegardes, et ainsi de suite.

Mythe 4. Le volume des copies augmente sans cesse et occupe entièrement tout l'espace alloué.

Les sauvegardes ont une durée de conservation limitée. Il n'est pas logique, par exemple, d'accumuler pendant un an les 365 sauvegardes quotidiennes. En général, il est acceptable de conserver les copies quotidiennes pendant 2 semaines, après quoi elles sont remplacées par de nouvelles, et pour un stockage à long terme, la version réalisée en premier dans le mois est conservée. Celle-ci, à son tour, est également stockée pendant une période déterminée - chaque copie a une durée de vie.

Il existe une protection contre la perte de données. La règle est la suivante : avant qu'une sauvegarde soit supprimée, la suivante doit être créée. Par conséquent, les données ne seront pas supprimées si la sauvegarde n'a pas été effectuée, par exemple, en raison de l'indisponibilité du serveur. Les délais sont respectés et le nombre de copies dans l'ensemble est contrôlé. Si le système stipule qu'il doit y avoir deux sauvegardes complètes, il y en aura toujours deux, et la vieille sera supprimée uniquement lorsque la nouvelle troisième sera enregistrée avec succès. Ainsi, l'augmentation de l'espace occupé par l'archive de sauvegardes n'est liée qu'à la croissance du volume des données protégées et ne dépend pas du temps.

Mythe 5. Une fois la sauvegarde lancée, tout se fige.

Il vaut mieux dire ainsi : si tout se fige, cela signifie que les mains de l'administrateur ne sont pas bien placées. En général, la rapidité de la sauvegarde dépend de nombreux facteurs. Par exemple, de la rapidité du système de sauvegarde lui-même : à quelle vitesse fonctionnent les disques de stockage, les bibliothèques de bandes. De la rapidité serveurs du système de sauvegarde : s'ils parviennent à traiter les données, à effectuer la compression et la déduplication. Ainsi que de la vitesse des lignes de communication entre le client et le serveur.

La sauvegarde peut se faire en un ou plusieurs flux, selon que le système à sauvegarder prend en charge le multithreading. Par exemple, le SGBD Oracle permet d'utiliser plusieurs flux, selon le nombre de processeurs disponibles, tant que la vitesse de transmission n'atteint pas la limite de bande passante du réseau.

Si vous essayez de faire des sauvegardes avec un grand nombre de flux, il y a un risque de surcharger le système en fonctionnement, ce qui peut le ralentir. C'est pourquoi un nombre optimal de flux est choisi pour garantir des performances suffisantes. Si même la moindre diminution des performances est critique, il existe une excellente option où la sauvegarde est effectuée non pas depuis le serveur de production, mais depuis son clone – standby dans le jargon des bases de données. Ce processus ne surcharge pas le système de travail principal. Les données peuvent être récupérées via un plus grand nombre de flux, car le serveur n'est pas utilisé pour le service.

Dans les grandes organisations, un réseau séparé est créé pour le système de sauvegarde, afin que la sauvegarde n'affecte pas le système de production. De plus, le trafic peut être transféré non pas par le réseau, mais par SAN.

Nous essayons également de répartir la charge dans le temps. Les sauvegardes se font principalement en dehors des heures de travail : la nuit, le week-end. De plus, elles ne sont pas lancées toutes simultanément. Les sauvegardes des machines virtuelles sont un cas particulier. Le processus n'affecte pratiquement pas les performances de la machine elle-même, ce qui permet de répartir la sauvegarde sur le temps diurne, plutôt que de tout reporter à la nuit. Il y a beaucoup de subtilités ; si tout est pris en compte, la sauvegarde n'affectera pas les performances des systèmes.

Mythe 6. J'ai lancé le système de sauvegarde – voilà la redondance.

N'oubliez jamais que le système de sauvegarde est la dernière ligne de défense, il doit donc y avoir encore plusieurs systèmes garantissant la continuité, la haute disponibilité et la résilience des infrastructures informatiques et des systèmes d'information de l'entreprise.

Il ne faut pas espérer que la sauvegarde restaurera toutes les données et relèvera rapidement le service en panne. La perte de données entre la sauvegarde et le moment de la défaillance est garantie, et le transfert des données vers un nouveau serveur peut prendre plusieurs heures (ou des jours, selon la chance). Il est donc logique de créer de véritables systèmes de redondance sans uniquement compter sur la sauvegarde.

Mythe 7. J'ai configuré une fois la sauvegarde, j'ai vérifié que ça fonctionne. Il ne reste plus qu'à regarder les logs.

C'est l'un des mythes les plus nuisibles, dont la fausse nature ne se réalise qu'au moment d'un incident. Les journaux de succès de sauvegarde ne garantissent pas que tout s'est réellement bien passé. Il est important de vérifier à l'avance la restaurabilité de la copie sauvegardée. C'est-à-dire d'exécuter le processus de restauration dans un environnement de test et de regarder le résultat.

Un peu sur le travail des administrateurs système

En mode manuel, personne ne copie plus les données depuis longtemps. Les systèmes de sauvegarde modernes peuvent presque tout sauvegarder, il suffit de les configurer correctement. Si un nouveau serveur est ajouté, il faut définir des politiques : choisir le contenu à sauvegarder, indiquer les paramètres de stockage et appliquer un calendrier.

Cela dit, il y a tout de même beaucoup de travail en raison de l'ampleur du parc de serveurs, incluant des bases de données, des systèmes de messagerie, des clusters de machines virtuelles et des ressources de fichiers aussi bien sur Windows que sur Linux/Unix. Les employés qui maintiennent le bon fonctionnement du système de sauvegarde ne restent pas inactifs.

À l'occasion de la fête, je souhaite à tous les administrateurs des nerfs solides, des gestes précis et un espace infini pour le stockage des sauvegardes !

Source : habr.com