Bonjour Ă tous!
Il y a quelque temps, je me suis plongé dans le monde de la «dure entreprise», notamment dans ce domaine qui est responsable du stockage et de la sauvegarde des données. Plus précisément, c'est le plus. Et pendant cette période, j'ai accumulé plusieurs règles que j'essaie d'adhérer lors de la conception ou de l'entretien de solutions dans ce domaine. Certains ont déjà survécu aux leurs, avec le développement de la technologie, et certains fonctionnent assez bien. Et j'ai décidé de les partager avec vous.
Il n'y aura pas de règle 3-2-1, qui est souvent mentionnée sans moi, ainsi que certaines techniques directes pour des situations spécifiques et d'autres choses dans la même veine. Peut-être pour la plupart de ceux qui liront ce seront les bases et les platitudes. C'est juste ma modeste expérience et j'espère que cela sera utile à quelqu'un. Je demande un chat.
Caractéristiques du "dimensionnement" local
Tôt ou tard, il est nécessaire d'obtenir quelques téraoctets et / ou IOPS supplémentaires. Et puis le dimensionnement commence. Souvent dénué de sens et impitoyable. Parce qu'il est extrêmement rare que quelqu'un fixe les exigences RTO pour le dimensionnement, qui sont généralement présentées pour la sauvegarde. Bien que cela semble être une exigence évidente pour tout complexe matériel. C'est-à -dire Lors du dimensionnement et de la formation des exigences pour un nouvel équipement, pour une raison quelconque, les exigences du système de sauvegarde, qui restaurera d'urgence quelque chose sur votre matériel, ne sont pas prises en compte. Parfois, quelque chose est assez gros. En général, une sorte de marge de productivité et d'espace est en cours d'élaboration, mais la toute première récupération de données montre qu'elle ne sera pas suffisante pour le cycle de vie défini pour cet équipement.
Au cours de la dernière année, j'ai déjà vu deux fois une situation où le goulot d'étranglement pendant la récupération de données était la baie de disques sur laquelle la récupération a été effectuée. Ils s'inscrivent dans RTO, mais la cloche était alarmante.
Nous avons une solution sur le cluster, pourquoi avez-vous besoin d'une sauvegarde?!
C’est cette phrase prononcée très «énergiquement» que j’ai entendue en communiquant
avec un développeur d'un logiciel très utile pour une entreprise. Le développeur a fait valoir que la sauvegarde n'est pas nécessaire pour la récupération du fait que la solution est déployée sur un cluster et, par conséquent, si un nœud (ou une baie de disques) tombe sur le site, le cluster sera enregistré. Dans ces cas, il sauvera sans aucun doute. C'est généralement excellent quand il y a des gars qui pensent à la tolérance aux pannes même au stade du développement.
Cependant, la perte de données est obtenue non seulement par la défaillance de l'équipement sur un site, et pour une raison quelconque, le développeur n'a pas voulu comprendre cela pendant un certain temps. En conséquence, la première version du logiciel a été publiée sur le SGBD communautaire, dont la mécanique de sauvegarde ne permettait de remplir ni les exigences RTO / RPO ni le SLA de l'entrepreneur.
En général, j'entends assez souvent cette phrase sur un cluster.
D'abord, puis ça!
L'une de mes plus grosses erreurs a été de considérer les objets de sauvegarde comme des objets indépendants. Voici le SGBD, voici le logiciel. C'est une sauvegarde comme ça, et c'est comme ça. D'abord un, puis un autre. Et un jour, nous n'avons pas pu récupérer. Plus précisément, ils le pouvaient, mais pendant les quelques jours consacrés à la correction des erreurs dans la base de données. Et ce n'est pas moi qui les ai éliminés, pour lesquels j'ai particulièrement honte. Bien que nous ayons utilisé un mécanisme de sauvegarde régulier pour ce SGBD. Déjà testé sur d'autres systèmes.
À partir de ce moment, je me bouscule et secoue le développeur / propriétaire du système sur la façon de sauvegarder et de restaurer correctement. Par exemple, dans un cas, la seule façon de créer une sauvegarde fonctionnelle était d'arrêter complètement les services sur 5 serveurs, d'effectuer une sauvegarde et de démarrer les services.
Vider notre tout?
Je rencontre souvent des solutions sur des SGBD tels que MySQL et PostgreSQL. Et encore plus souvent, je rencontre une situation où le vidage banal de la base de données dans / tmp est utilisé comme méthode de sauvegarde, puis vers un autre support. Dans le même temps, les systèmes sur lesquels ces SGBD sont utilisés sont assez critiques pour les temps d'arrêt en cas de perte de données et sont très chargés. Je suis déjà silencieux sur les volumes.
Pour une raison quelconque, peu de personnes lisent la documentation de ces produits et ne savent pas qu'il existe d'autres méthodes et solutions pour créer des sauvegardes de ces SGBD.
MySQL Enterprise Backup pour MySQL et
pg_basebackup (
pg_start_backup, pg_stop_backup ) respectivement dans PostgreSQL. Ou il le sait, mais a volé hors de sa tête. Bien que ces solutions ne soient pas beaucoup plus compliquées et rapides. Sauvegarde plus rapide, restauration plus rapide, test plus rapide.
Veuillez ne pas tirer sur le pianiste.
Il fait de son mieux.
Oscar Fingal O'Flahertie Wills Wilde