Hola a todos!
Hace algún tiempo, me sumergí en el mundo de la "empresa dura", es decir, en esa área que es responsable del almacenamiento y la copia de seguridad de los datos. Más precisamente, en lo más. Y durante este período, he acumulado varias reglas que trato de cumplir al diseñar o dar servicio a soluciones en esta área. Algunos ya han sobrevivido a los suyos, con el desarrollo de la tecnología, y algunos están trabajando bastante. Y decidí compartirlos contigo.
No habrá una regla 3-2-1, que a menudo se menciona sin mí, así como algunas técnicas directas para situaciones específicas y otras cosas en la misma línea. Quizás para la mayoría de los que leen esto será lo básico y los tópicos. Esta es solo mi modesta experiencia y espero que sea útil para alguien. Pido gato.
Características del "dimensionamiento" local
Tarde o temprano, es necesario obtener más terabytes y / o IOPS. Y luego comienza el dimensionamiento. A menudo sin sentido y despiadado. Porque es extremadamente raro que alguien establezca los requisitos de RTO para el dimensionamiento, que generalmente se presentan para la copia de seguridad. Aunque parece un requisito obvio para cualquier complejo de hardware. Es decir Al dimensionar y formar requisitos para equipos nuevos, por alguna razón, no se tienen en cuenta los requisitos del sistema de respaldo, que restaurará urgentemente algo a su hardware. A veces algo es bastante grande. En general, se está estableciendo algún tipo de margen de productividad y espacio, pero la primera recuperación de datos muestra que no será suficiente para el ciclo de vida definido para este equipo.
Durante el año pasado, ya he visto una situación dos veces cuando el cuello de botella durante la recuperación de datos fue la matriz de discos en la que se realizó la recuperación. Encajaban en RTO, pero la campana era alarmante.
Tenemos una solución en el clúster, ¿por qué necesita una copia de seguridad?
Es esta frase muy "enérgicamente pronunciada" la que escuché al comunicarme
con un desarrollador de un software muy útil para una empresa. El desarrollador argumentó que la copia de seguridad es innecesaria para la recuperación por el hecho de que la solución se implementa en un clúster y, por lo tanto, si un nodo (o matriz de discos) cae en el sitio, el clúster se guardará. En estos casos, sin duda salvará. Esto es generalmente excelente cuando hay algunos tipos que piensan en la tolerancia a fallas incluso en la etapa de desarrollo.
Sin embargo, la pérdida de datos se logra no solo por la falla del equipo en un sitio, y por alguna razón el desarrollador no quiso entender esto por algún tiempo. Como resultado, la primera versión del software se lanzó en el DBMS de la comunidad, cuya mecánica de respaldo no permitió cumplir con los requisitos RTO / RPO o el SLA del contratista.
En general, escucho esta frase sobre un clúster con bastante frecuencia.
Primero, entonces esto!
Uno de mis mayores errores fue considerar los objetos de respaldo como independientes. Aquí está el DBMS, aquí está el software. Esto es una copia de seguridad como esta, y esto es así. Primero uno, luego otro. Y un día no pudimos recuperarnos. Más precisamente, podrían hacerlo, pero durante los pocos días que se dedicaron a corregir errores en la base de datos. Y no fui yo quien los eliminó, por lo cual estoy especialmente avergonzado. Aunque utilizamos un mecanismo de copia de seguridad regular para este DBMS. Ya probado en otros sistemas.
A partir de ese momento, empujo mi nariz y sacudo al desarrollador / propietario del sistema sobre el tema de cómo hacer una copia de seguridad y restaurar correctamente. Por ejemplo, en un caso, la única forma de crear una copia de seguridad funcional era detener completamente los servicios en 5 servidores, hacer una copia de seguridad e iniciar los servicios.
Volcar nuestro todo?
A menudo encuentro soluciones en DBMS como MySQL y PostgreSQL. Y aún más a menudo me encuentro con una situación en la que el volcado banal de la base de datos en / tmp se usa como método de respaldo, y luego a otro medio. Al mismo tiempo, los sistemas donde se usan estos DBMS son bastante críticos para el tiempo de inactividad en caso de pérdida de datos, y están muy cargados. Ya estoy en silencio sobre los volúmenes.
Por alguna razón, pocas personas leen la documentación de estos productos y no saben que existen métodos y soluciones alternativas para crear copias de seguridad de estos DBMS.
MySQL Enterprise Backup para MySQL y
pg_basebackup (
pg_start_backup, pg_stop_backup ) respectivamente en PostgreSQL, respectivamente. O lo sabe, pero voló fuera de su cabeza. Aunque estas soluciones no son mucho más complicadas y rápidas. Copia de seguridad más rápida, restauración más rápida, prueba más rápida.
Por favor no disparen al pianista.
Él está haciendo lo mejor que puede.
Oscar Fingal O'Flahertie Wills Wilde