Uno de nuestros equipos está desarrollando una base de datos que será algo grande (~500 GB) y crecerá a partir de ahí (sé que 500 Gigas puede parecer poco para muchos de ustedes, pero será una de las bases de datos más grandes de nuestra tienda). Uno de los problemas a los que se enfrentan es la realización de copias de seguridad y la restauración de la base de datos. Básicamente, la base de datos tendrá varias tablas de "datos" y una tabla utilizada para almacenar imágenes/documentos. Necesitamos lograr lo siguiente:
- Ser capaz de realizar copias de seguridad y restaurar rápidamente solo las tablas de datos (sin imágenes) en nuestro servidor de prueba para fines de depuración y prueba.
- En caso de una falla catastrófica en la base de datos, restaure las tablas de datos solo para que la mayor parte de la aplicación esté en funcionamiento lo antes posible. Luego, restaure la tabla de imágenes cuando sea posible.
- Haga una copia de seguridad de la base de datos dentro del período de tiempo nocturno asignado (unas pocas horas). Mis preguntas son:
¿Es posible lograr los dos primeros objetivos sin dejar de tener las imágenes almacenadas en la misma base de datos? Si es así, ¿utilizaríamos grupos de archivos, secuencias de archivos o algo más? ¿Cómo hacen otras tiendas copias de seguridad de sus bases de datos en un período de tiempo razonable manteniendo al mismo tiempo una alta disponibilidad? ¿Se replica en un segundo servidor y se realiza una copia de seguridad desde allí?
Respuesta1
Bastante simple: NO PLANEAR RESTAURAR.
En caso de una falla catastrófica en la base de datos, restaure las tablas de datos solo para que la mayor parte de la aplicación esté en funcionamiento lo antes posible.
¿En realidad? Tu definición de catástrofe no es la mía ni la del resto del mundo.
En caso de una atrofia de datos, desea realizar una copia de seguridad lo antes posible, pero es posible que sea necesario reconstruir el centro de datos lo antes posible debido a un incendio. ESTO es una catástrofe.
En caso de fallas del servidor, etc., no planee utilizar copias de seguridad. Utilice la replicación y registre el envío de archivos para mantener activo un segundo servidor (en una SAN separada) y lea para que asuma el control dentro de un período de tiempo breve definido. Conozco empresas que envían archivos de registro cada 10 minutos.
Prácticamente tu única oportunidad. Mueva la catástrofe a algo que sea un desastre REAL, no un fracaso de raid/san. Algo en lo que su pregunta no es "qué tan rápido puedo restaurar" sino "qué tan rápido obtengo hardware nuevo".
Las restauraciones para desarrolladores, etc. requieren menos tiempo.