¿Hay una buena manera de hacer una copia de seguridad de un petabyte de datos y almacenarlo?

Estoy empezando a ver clientes con cientos de terabytes de datos (en instalaciones de SQL Server). A medida que el volumen total de datos en algunas empresas se acerca a fracciones significativas de un petabyte, me gustaría examinar la base de conocimiento colectivo para ver qué están haciendo las personas que manejan esa magnitud de datos para salvaguardarla.

El problema obvio es que almacenar múltiples copias de seguridad de esa cantidad de datos es prohibitivamente costoso, utilizando almacenamiento de clase empresarial, diablos, incluso solo RAID-5.

Las opciones que veo son las siguientes:

1. Cree una copia reflejada de los datos en otro centro de datos y envíele continuamente diferencias (utilizando cualquier mecanismo disponible para su fuente de datos, por ejemplo, envío de registros o reflejo de base de datos con SQL Server)
2. Realice copias de seguridad periódicas utilizando un algoritmo de compresión fuerte (probablemente solo sea adecuado si los datos se prestan bien a una gran compresión)
3. Realice copias de seguridad por partes de las partes críticas / cambiantes de los datos.
4. No respalde los datos y confíe en los dioses de la corrupción.

Veo que se adopta la opción n. ° 4 como predeterminada, y como experto en HA / DR es realmente aterradora, pero ¿qué aconsejo como alternativa? Creo que el n. ° 1 es el mejor enfoque, pero "No lo creo" es la respuesta habitual cuando se sugiere cualquier alternativa aparte del n. ° 4 y posiblemente el n. ° 3.

Ahora, por supuesto, depende de la tasa de cambio y la criticidad de los datos. No es necesario responder con eso, ya que solía ser responsable de todas las características de HA de SQL Server mientras trabajaba en Microsoft, así que estoy bien versado en los argumentos de 'depende', esa es mi frase clave :-)

Me interesaría mucho saber de cualquier alternativa que me haya perdido, o escuchar que todos los demás están en el mismo barco y que no hay una alternativa realista a gastar mucho dinero en más almacenamiento.

Gracias de antemano: se dará el debido crédito a todas las respuestas bien pensadas y expresadas.

Idea fuera de la pared: ¿toda la información almacenada es necesaria o incluso útil?

¿Cuánto vale realmente la información? Parece obviamente ridículo gastar más en mantenimiento y administración de lo que valen los datos.

¿Los datos en la base de datos son apropiados para el almacenamiento en una base de datos? Por ejemplo, ¿mantener archivos comprimidos de varios gigabytes en la base de datos de la organización de soporte realmente proporciona algún beneficio real?

¿Hay muchos datos duplicados en la base de datos? Por ejemplo, ¿hay miles de personas que guardan diez copias de cada boletín semanal de 10MB?

¿Algunos de los datos tienen una "fecha de vencimiento" después de la cual no proporciona ningún valor? Volviendo al ejemplo de la organización de soporte, por varias razones, prácticamente no hay beneficio en mantener los archivos principales de los clientes más de unos pocos meses después de que se haya entregado una solución.

Otra idea es mantener esa cantidad de datos abriendo a la empresa a responsabilidades. Algunos datos deben, por ley, mantenerse. Sin embargo, algunos datos deben ser "triturados" debido a los riesgos planteados si se divulgan accidental o malintencionadamente a partes inapropiadas.

Sí, otra opción es la virtualización del almacenamiento: un dispositivo que se encuentra entre sus servidores y la SAN, como IBM SVC. SVC gestiona copias de SAN a SAN y puede realizar la replicación remota (aunque eso es obviamente bastante doloroso a nivel de petabytes a menos que tenga tasas de cambio de datos realmente bajas y un ancho de banda realmente alto).

La parte ingeniosa es que todo el proceso es invisible para los servidores involucrados. Si está utilizando SQL Server, diseña sus grupos de archivos para mantener juntos las cosas con una tasa de cambio baja (como archivos de ventas de hace> 3 años) y cosas con una tasa de cambio alta (como las ventas actuales) en un grupo de archivos separado. Ni siquiera tienen que ser completamente de solo lectura, solo desea diseñarlo para que pueda usar diferentes métodos de replicación para cada grupo de archivos. El equipo SAN puede sincronizar a las luns a través de la red, la cinta o las SAN, lo que significa que puede enviar partes de la SAN de un lado a otro. Esto es más efectivo con equipos como LeftHand's, donde el SAN está formado por un grupo de unidades participantes.

Luego, puede sincronizar automáticamente el material de baja tasa de cambio a través del cable y sincronizar la alta tasa de cambio con sneakernet. (Parece que lo tengo al revés, pero es cierto: no puede sincronizar las cosas de alta tasa de cambio a través del cable debido al volumen). Incluso algunos de los equipos de gama baja se adaptan a esto ahora: LeftHand le permite replicar a otros Unidades LeftHand en su centro de datos y luego envíelas a su centro de datos externo. Conéctelos, únalos al lado remoto cambiando las IP y los grupos, y ahora son parte de su SAN de respaldo remoto. El argumento de venta de LeftHand en esto es simplemente brillante: configure sus dos SAN lado a lado en su centro de datos principal, sincronícelas, luego puede enviar partes de ellas al centro de datos remoto mientras algunos de ellos permanecen en su actual centro de datos para mantenerse sincronizado. Gradualmente muévete

Sin embargo, no he hecho esto a nivel de petabyte. Ya sabes lo que dicen: en teoría, en teoría y en la práctica son lo mismo. En la práctica...

La opción 1 es la duplicación, que es casi tan mala como la n. ° 4: cualquier error que dañe los datos y no se descubra de inmediato, dañará ambas copias.

Si los datos son críticos, considere soluciones dedicadas; lea sobre los productos Shark de IBM, por ejemplo, o productos de la competencia de EMS, etc. Tienen características como Flash-copy, que le permiten crear instantáneamente una copia lógica del archivo sin duplicar los requisitos del disco; y luego puede hacer una copia de seguridad de esta copia en (por ejemplo) cinta. Examine también la copia de seguridad en cinta robótica.

Señale a aquellos que desean almacenar un Petabyte de datos que el almacenamiento no es barato.

Estoy tan harto de que la gente se queje de no tener un Terabyte adicional de almacenamiento en línea porque el disco es barato; el disco puede serlo, pero el almacenamiento administrado es seguro.

Si es prohibitivamente costoso almacenar las copias de seguridad, entonces es prohibitivamente costoso almacenar los datos de manera segura, por lo que la solución propuesta no es viable.

Una de las razones más importantes para tener copias de seguridad es la protección contra errores del usuario (la mayoría de los problemas de fallas de hardware se pueden solucionar con soluciones de hardware), pero incluso la creación de reflejo de la base de datos no es protección contra una tabla descartada (OK, puede protegerse contra eso, pero aún así es posible obtener un guff inamovible en su base de datos, a menos que la razón por la cual la base de datos sea tan grande es que solo emite inserciones).

Como veo, la cinta ya no es una solución viable: ahora es más barato trabajar solo con matrices de discos (aunque el almacenamiento físico puede ser incómodo). Por lo tanto, creo que su única opción es algún método para dividir los datos en fragmentos lo suficientemente pequeños como para restaurarlos en un período de tiempo razonable y luego llevarlos al almacenamiento en disco de forma regular (y aquí las soluciones de tipo EMS pueden ayudar, si tiene el efectivo).

Video interesante que detalla la arquitectura de myspace.com (back-end SQL2005). No estoy seguro si tienen dbs de petabytes individuales, ya que se escalan con múltiples dbs. Usan copias de seguridad de SAN.

http://wtv.watchtechvideos.com/topic70.html

ZFS. Claro, todavía está comenzando, pero hay una serie de áreas donde ZFS está diseñado para manejar este tipo de cosas. En primer lugar, es la capacidad de manejar una gran cantidad de datos, así como una multitud de diferentes dispositivos de almacenamiento (local, SAN, fibra, etc.), todo mientras mantiene los datos seguros con sumas de verificación y conciencia de "violación de la capa" del estado del dispositivo y fallas ¿Cómo, sin embargo, esto ayuda a resolver el respaldo de esta cantidad de datos?

Un método es usar instantáneas. Tome una instantánea, envíela a cinta / disco / red para transferirla al sitio remoto. Las instantáneas posteriores solo envían datos que se han enviado, y puede mantener datos en vivo en ambos extremos si es necesario.

El otro es usar el software Solaris Cluster donde (siempre y cuando tenga suficiente ancho de banda de red) puede tener una duplicación en vivo entre dos servidores y si uno se cae, el segundo puede hacerse cargo. Es más útil cuando la alta disponibilidad (HA) es importante, pero supongo que la mayoría de los lugares con tantos datos quieren HA.

Y dice que ZFS no es compatible con Windows, el lugar habitual donde puede encontrar sqlserver, tal vez ejecute Sun / ZFS en el back-end y se conecte a través de iSCSI. Quizás esa también sea una idea horrible, pero al menos vale la pena pensarlo un poco para que sepa qué no hacer.

¿Has mirado en Amazon Glacier como una opción?

OMI, a menos que tenga algún tipo de hardware de nivel Godzilla, si tiene esa cantidad de datos, debería estar utilizando una tecnología de compresión de respaldo. Estoy más familiarizado con LiteSpeed, pero hay productos similares de otros proveedores y (por supuesto) una característica similar está integrada en SQL2008. Es posible que no obtenga una compresión de 10 a 1, pero reduce los requisitos de almacenamiento para la copia de seguridad y también puede reducir los requisitos de la ventana de copia de seguridad. Si su objetivo es mantener múltiples conjuntos de copia de seguridad (ayer más el día anterior, más uno de la semana pasada y uno del mes pasado, o una serie de diferenciales más completos, que pueden ser muy grandes si cambia muchos de los datos en la base de datos), es una simple cuestión de espacio de almacenamiento.

La copia de seguridad basada en grupos de archivos (IOW, coloca datos no volátiles en ciertos FG y la copia de seguridad con poca frecuencia) nunca parece volar porque los desarrolladores o usuarios no pueden o no pueden decidir qué datos son volátiles y cuáles no, y en brownfield escenarios que a menudo no puede correr el riesgo.

Si se requiere un sitio de conmutación por error, además de pensar en Database Mirror), es posible que desee hablar con el proveedor de almacenamiento de sus clientes para ver si ofrecen algo como SRDF, que es una tecnología de replicación de datos basada en hardware. Naturalmente, la replicación (de cualquier tipo, pero particularmente la replicación en tiempo real o casi en tiempo real) no es un sustituto de las copias de seguridad.

No creo que tenga muchas opciones aquí en el disco de cinta v. Es probable que la cinta no se corte en una ventana de respaldo normal a menos que la elimine, y no estoy seguro de que la confiabilidad esté ahí.

Por lo tanto, tiene que hacer copias de seguridad de disco. ¿Estás versionando? ¿Significa que le preocupa volver a la copia de seguridad 2 (base de datos actual menos 2 copias de seguridad)? O copia de seguridad 3? En ese caso, es posible que tenga problemas, pero probablemente lo que tiene que manejar son las copias de seguridad de registros, no tanto las copias de seguridad de datos.

Si puede dividir algunos de los datos como de solo lectura / sin cambios, entonces quizás tenga tamaños / ventanas de respaldo manejables. O al menos espera que la tecnología de respaldo y el ancho de banda se estén poniendo al día con el crecimiento de los datos.

No creo que esté retrocediendo tanto como guarda una segunda copia para recuperarse de los problemas con su primario. Eso significa hardware, corrupción, etc., y reza diariamente para que no se envíen errores a la segunda copia. Lo más probable es que las copias se realicen SAN-SAN, con alguna tecnología instantánea. aunque la copia original podría ser a través de Fed-Ex en lugar de a través del cable. El ancho de banda para mover 100 TB no es fácil de encontrar para nadie.

Creo que necesita una combinación de 1, 2 y 3 (no 4), con una excelente gestión de copia de seguridad de registros.

En realidad, creo que en cualquier momento estás mirando 3 copias de tus datos. Ejecutar CHECKDB en 1 de las copias mientras se usa la segunda copia para recibir los cambios. Luego toma una instantánea de la segunda copia de la primera y continúa. Con esta cantidad de datos, me imagino que necesitaría un poco de diligencia aquí. Paul, ¿cómo funciona checkdb en una base de datos de 100 TB multiusuario que está en línea?

Como se mencionó, ¿no son críticas las copias de seguridad de registros, y probablemente un lector de registros? ¿No necesita recuperar tablas de caída / error de usuario de los registros en lugar de una copia de seguridad? Potencialmente, puede atajar esto enviando copias SAN a través de algún retraso, pero no he visto esa tecnología. Una SAN de envío de registros que puede retrasar los cambios en 4 horas (o algún intervalo) para permitirle recuperarse de problemas antes de sobrescribir los datos. ¿O alguna herramienta de cambios de bloque de registro de SAN? Sin eso, debe administrar esos registros de transacciones, que podrían ser un nivel completamente diferente de rastrear esas copias de seguridad en varios sistemas de archivos durante unas xxx horas para permitirle potencialmente recuperarse de errores no fatales.

Técnicamente, el almacenamiento es barato, pero a nivel de petabytes, no tanto. Realmente depende de la aplicación, pero diría que una combinación de la estrategia n. ° 2 y n. ° 3 será la respuesta, con el n. ° 2 dado y el n. ° 3 dependiendo de la cantidad de inversión que pueda hacer en almacenamiento y el tipo de almacenamiento y E / S / potencia computacional que le permitirá salirse con la suya con el menor incrementalismo y la mayor cantidad de respaldo discreto y completo posible.

Alternativamente, algo como Amazon S3 también puede entrar en juego dependiendo de su ancho de banda y de cuánto cambio haya en los datos, en este volumen, colocando al menos parte en los servidores de otra persona y dejando que se preocupen por la redundancia cada vez más económico.

Hable con su proveedor de almacenamiento, ellos tendrán un producto de deduplicación que han usado antes, combinado con una compresión regular, a menudo puede reducir su huella de datos en un 70%. Por supuesto, cualquiera que tenga el dinero para gastar en un petabyte de almacenamiento también tendrá el presupuesto para comprar una solución de respaldo decente también; si no lo tienen, solo tiene que preguntarles cuánto costará su negocio perder ese petabyte.

En un gran almacén de datos empresariales, gran parte de los datos proviene de fuentes que ya están respaldadas. Trabajé en instalaciones de Teradata y ODW donde tomaron la opción # 4, pero sabía que podrían restaurar uno o dos días de datos transaccionales y transformarlos desde los sistemas de origen.

En un cliente minorista (en el momento en que tenían uno de los 5 DW más grandes del mundo, a unos 200 TB ... le da una idea de cuánto tiempo hace que esto era), optaron por la opción n. ° 1 después de comprar un nuevo Petabyte -clase servidor Teradata. Los nodos antiguos se usarían para una instantánea del sistema del día anterior, mientras que el nuevo mantenía el existente. Esto también fue bueno desde la perspectiva de la conmutación por error: de vez en cuando lo quitaban todo por mantenimiento y simplemente cambiábamos a usar el viejo servidor lento con datos de un día.

Honestamente, sin embargo, parecía un gran desperdicio de procesamiento / almacenamiento / etc. para mantener el funcionamiento ... particularmente cuando la mayor ventaja era que sus administradores y técnicos de NCR tenían que trabajar menos tardes para realizar un mantenimiento irregular.