La sauvegarde ne fait pas partie des technologies à la mode dont on crie sur tous les fers. Il faut juste que ce soit dans n'importe quelle entreprise sérieuse, c'est tout. Nous sauvegardons plusieurs milliers de serveurs dans notre banque - c'est un travail complexe et intéressant, dont certaines subtilités, ainsi que les idées fausses typiques sur les sauvegardes, veulent juste être dites.
Je travaille sur ce sujet depuis près de 20 ans, dont les 2 dernières années à la Promsvyazbank. Au tout début de la pratique, j'ai fait des sauvegardes presque manuellement, avec des scripts qui se contentaient de copier des fichiers. Ensuite, des outils pratiques sont apparus dans Windows : l'utilitaire Robocopy pour préparer les fichiers et NT Backup pour la copie. Et ce n'est qu'alors qu'est venu le temps des logiciels spécialisés, principalement Veritas Backup Exec, qui s'appelle désormais Symantec Backup Exec. Je connais donc depuis longtemps les sauvegardes.
En termes simples, la sauvegarde consiste à conserver une copie des données (machines virtuelles, applications, bases de données et fichiers) au cas où avec une certaine régularité. Chaque cas se manifeste généralement par une défaillance matérielle ou logique et entraîne une perte de données. Le but d'un système de sauvegarde est de réduire la perte d'informations. Une panne matérielle est, par exemple, une panne du serveur ou du stockage où se trouve la base de données. Logique - il s'agit de la perte ou de la modification d'une partie des données, notamment en raison du facteur humain : ils ont accidentellement supprimé une table, un fichier, lancé un script tordu pour l'exécution. Il existe également des exigences réglementaires pour le stockage d'un certain type 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 le déploiement de divers systèmes de test, des clones pour les développeurs.
Il existe quelques mythes typiques autour de la sauvegarde qui devraient être dissipés depuis longtemps. Voici les plus célèbres d'entre eux.
Mythe 1. La sauvegarde n'a longtemps été qu'une petite fonction dans les systèmes de sécurité ou de stockage
Les systèmes de sauvegarde restent encore une classe de solutions à part, et très indépendantes. Ils ont trop de travail à faire. En fait, ils constituent la dernière ligne de défense en matière d'intégrité des données. Ainsi, la sauvegarde fonctionne à son propre rythme, selon son propre calendrier. Un rapport quotidien est généré pour les serveurs, il y a des événements qui agissent comme des déclencheurs pour le système de surveillance.
De plus, le modèle de rôle d'accès au système de sauvegarde vous permet de déléguer une partie de l'autorité aux administrateurs des systèmes cibles pour gérer les sauvegardes.
Mythe 2. Lorsqu'il y a un RAID, une sauvegarde n'est plus nécessaire.
Sans aucun doute, les matrices RAID et la réplication de données sont un bon moyen de protéger les systèmes d'information des pannes matérielles, et si vous disposez d'un serveur de secours, vous pouvez rapidement organiser le basculement vers celui-ci en cas de défaillance de la machine principale.
À partir des erreurs logiques commises par les utilisateurs du système, la redondance et la réplication ne sauvent pas. Voici un serveur de secours en écriture différée - oui, cela peut aider si une erreur est détectée avant qu'elle ne soit synchronisée. Et si le moment est manqué ? Seule une sauvegarde opportune aidera ici. Si vous savez que les données ont changé hier, vous pouvez restaurer le système avant-hier et en extraire les données nécessaires. Etant donné que les erreurs logiques sont les plus courantes, la bonne vieille sauvegarde reste un outil éprouvé et nécessaire.
Mythe 3. Une sauvegarde est quelque chose qui se fait une fois par mois.
La fréquence de sauvegarde est un paramètre configurable qui dépend principalement des exigences de votre système de sauvegarde. Il est tout à fait possible de trouver des données qui ne changent presque jamais et qui ne sont pas particulièrement importantes, leur perte ne sera pas critique pour l'entreprise.
Ils peuvent en effet être sauvegardés une fois par mois et encore moins souvent. Mais les données les plus critiques sont sauvegardées plus souvent, en fonction de l'indicateur RPO (Recovery point objective), qui définit la perte de données autorisée. Cela peut être une fois par semaine, une fois par jour ou même plusieurs fois par heure. Nous avons ces journaux de transactions du SGBD.
Lors de la mise en service commercial des systèmes, une documentation de sauvegarde doit être approuvée, qui reflète les points principaux, la procédure de mise à jour, la procédure de restauration du système, la procédure de stockage des sauvegardes, etc.
Mythe 4. Le volume de copies ne cesse de croître et occupe complètement l'espace alloué.
Les sauvegardes ont une durée de conservation limitée. Cela n'a aucun sens, par exemple, de stocker les 365 sauvegardes quotidiennes au cours de l'année. En règle générale, il est acceptable de conserver des copies quotidiennes pendant 2 semaines, après quoi elles sont remplacées par de nouvelles, et la version créée en premier dans le mois reste en stockage à long terme. Celui-ci, à son tour, est également stocké pendant un certain temps - chaque copie a une durée de vie.
Il existe une protection contre la perte de données. La règle s'applique : avant qu'une sauvegarde ne soit supprimée, la suivante doit être formée. Par conséquent, les données ne seront pas supprimées si la sauvegarde n'est pas terminée, par exemple en raison de l'indisponibilité du serveur. Non seulement les délais sont respectés, mais le nombre de copies dans le jeu est également contrôlé. Si le système est conçu pour avoir deux sauvegardes complètes, il y en aura toujours deux, et l'ancienne ne sera supprimée que lorsqu'une nouvelle troisième sera écrite avec succès. Ainsi, la croissance du volume occupé par l'archive de sauvegarde est associée uniquement à la croissance de la quantité de données protégées et ne dépend pas du temps.
Mythe 5. La sauvegarde a commencé - tout s'est bloqué
Il vaut mieux dire ceci: si tout est suspendu, les mains de l'administrateur ne poussent pas à partir de là. En général, les performances d'une sauvegarde dépendent de nombreux facteurs. Par exemple, sur la vitesse du système de sauvegarde lui-même : à quelle vitesse sont les stockages sur disque, les bibliothèques de bandes. De la rapidité des serveurs du système de sauvegarde : s'ils ont le temps de traiter les données, d'effectuer la compression et la déduplication. Et aussi sur la vitesse des lignes de communication entre le client et le serveur.
La sauvegarde peut aller vers un ou plusieurs flux, selon que le système sauvegardé prend en charge le multithreading. Par exemple, le SGBD Oracle vous permet de donner plusieurs threads, en fonction du nombre de processeurs disponibles, jusqu'à ce que le taux de transfert atteigne la limite de bande passante du réseau.
Si vous essayez de sauvegarder un grand nombre de threads, il y a une chance de surcharger un système en cours d'exécution, il commencera vraiment à ralentir. Par conséquent, le nombre optimal de threads est choisi pour garantir des performances suffisantes. Si même la moindre diminution des performances est critique, il existe une excellente option lorsque la sauvegarde est effectuée non pas à partir d'un serveur de combat, mais à partir de son clone - veille dans la terminologie de la base de données. Ce processus ne démarre pas le système de travail principal. Les données peuvent être récupérées via plusieurs flux, car le serveur n'est pas utilisé pour la maintenance.
Dans les grandes organisations, un réseau séparé est créé pour le système de sauvegarde afin que la sauvegarde n'affecte pas la production. De plus, le trafic peut ne pas être transmis via le réseau, mais via le SAN.
Nous essayons également de répartir la charge dans le temps. Les sauvegardes sont principalement effectuées en dehors des heures de travail : la nuit, le week-end. De plus, ils ne fonctionnent pas tous en même temps. Les sauvegardes de machines virtuelles sont un cas particulier. Le processus n'a pratiquement aucun effet sur les performances de la machine elle-même, de sorte que la sauvegarde peut être répartie sur la journée et ne pas tout reporter la nuit. Il existe de nombreuses subtilités, si vous prenez tout en compte, la sauvegarde n'affectera pas les performances des systèmes.
Mythe 6. Lancement d'un système de sauvegarde - c'est la tolérance aux pannes pour vous
N'oubliez jamais qu'un système de sauvegarde est la dernière ligne de défense, ce qui signifie qu'il devrait y avoir cinq autres systèmes devant lui qui assurent la continuité, la haute disponibilité et la tolérance aux catastrophes de l'infrastructure informatique et des systèmes d'information d'entreprise.
Espérer que la sauvegarde restaurera toutes les données et relèvera rapidement le service tombé n'en vaut pas la peine. La perte de données du moment de la sauvegarde au moment de la panne est garantie, et les données peuvent être téléchargées sur un nouveau serveur pendant plusieurs heures (ou jours, selon votre chance). Par conséquent, il est logique de créer des systèmes à part entière tolérants aux pannes sans tout déplacer vers une sauvegarde.
Mythe 7. J'ai configuré une sauvegarde une fois, j'ai vérifié qu'elle fonctionne. Il ne reste plus qu'à regarder les logs
C'est l'un des mythes les plus nocifs, dont vous ne réalisez la fausseté que lors de l'incident. Les journaux de sauvegarde réussis ne garantissent pas que tout s'est vraiment passé comme il se doit. Il est important de vérifier à l'avance la capacité de déploiement de la copie enregistrée. Autrement dit, démarrez le processus de récupération dans un environnement de test et examinez le résultat.
Et un peu sur le travail de l'administrateur système
En mode manuel, personne n'a copié de données depuis longtemps. Les SRK modernes peuvent sauvegarder presque tout, il vous suffit de le configurer correctement. Si un nouveau serveur a été ajouté, définissez des politiques : sélectionnez le contenu qui sera sauvegardé, spécifiez les options de stockage et appliquez la planification.
Dans le même temps, il reste encore beaucoup de travail en raison de la vaste flotte de serveurs, y compris les bases de données, les systèmes de messagerie, les clusters de machines virtuelles et les partages de fichiers à la fois sous Windows et Linux/Unix. Les employés qui maintiennent le système de sauvegarde en marche ne restent pas inactifs.
En l'honneur des vacances, je souhaite à tous les administrateurs des nerfs solides, une clarté des mouvements et un espace infini pour stocker les sauvegardes !
Source: habr.com