19 votos

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

Estoy empezando a ver a los clientes con cientos de terabytes de datos (en las instalaciones de SQL Server). Como el volumen total de datos en algunas empresas enfoques significativos fracciones de un petabyte, me gustaría lienzo de la base de conocimiento colectivo que hay para ver lo que las personas que se ocupan de que la magnitud de datos que se están haciendo para protegerla.

La cuestión obvia es que el almacenamiento de varias copias de seguridad de que la cantidad de datos es prohibitivamente caro, el uso de almacenamiento de clase empresarial, diablos, incluso RAID-5.

Las opciones que veo son como sigue:

  1. Crear una copia espejo de los datos en otro centro de datos, y continuamente barco de diferencias (el uso de cualquier mecanismo disponible para su origen de datos - por ejemplo, envío de registros o de reflejo de base de datos con SQL Server)
  2. La toma regular de copias de seguridad mediante un fuerte algoritmo de compresión (probablemente sólo es adecuado si los datos se presta bien a ser fuertemente comprimido)
  3. Tomar por etapas de las copias de seguridad de la crítica/cambio de partes de los datos.
  4. No copia de seguridad de los datos y la confianza de la corrupción-dioses.

Estoy viendo la opción #4 ser adoptado como el predeterminado, y como HA/DR experto es realmente aterrador, pero, ¿qué puedo aconsejar como una alternativa? Creo que #1 es el mejor método, pero "no lo creo" es la respuesta habitual cuando las alternativas aparte de #4 y, posiblemente, #3 se sugieren.

Ahora, por supuesto, depende del cambio de la tarifa y de la criticidad de los datos. No hay necesidad de responder con los que, como yo solía ser responsable de todas las funciones de HA de SQL Server mientras yo trabajaba en Microsoft, así que estoy muy versado en el 'depende' argumentos - esa es mi frase de moda :-)

Yo estaría muy interesado en escuchar las alternativas que se me haya olvidado, o escuchar que todos los demás están en el mismo barco y no hay ninguna alternativa realista a gastar un montón de dinero en más de almacenamiento.

Gracias de antemano - el debido crédito será dada a todos bien pensado y expresado respuestas.

7voto

pcapademic Puntos 1347

Fuera de la pared de la idea - es a la totalidad de la información almacenada sea necesario ni útil?

¿Cuánto es la información que realmente vale la pena? Parece obviamente ridículo gastar más en el mantenimiento y la gestión de los datos de la pena.

Los datos en la base de datos apropiada para su almacenamiento en una base de datos? Por ejemplo, no mantener comprimido varios gigabytes de archivos de base de apoyo en la organización de la base de datos de proporcionar realmente ningún beneficio real?

Hay un montón de la duplicación de los datos en la base de datos? Por ejemplo, son de un millar de personas mantenimiento de diez ejemplares de cada uno de un programa semanal de 10MB boletín de noticias?

¿Algunos de los datos tienen una "fecha de caducidad" después de que no proporciona ningún valor? Volviendo a la organización de apoyo ejemplo, por diversas razones, no hay prácticamente ningún beneficio en el mantenimiento de alrededor de cliente core archivos de más de un par de meses después de que la revisión ha sido entregado.

Otro pensamiento es mantener esa cantidad de datos de la apertura de la empresa a las obligaciones. Algunos datos de uno debe, por ley, a mantener. Algunos datos, sin embargo, debe estar "destrozado" por los riesgos que plantea si es accidental o maliciosamente, publicado a las partes inadecuadas.

6voto

Sí, otra opción es la de virtualización de almacenamiento: un dispositivo que se encuentra entre los servidores y el SAN, como IBM SVC. SVC gestiona SAN-SAN copias, y puede hacer la replicación remota (a pesar de que, obviamente, es bastante doloroso en el petabyte de nivel a menos que usted realmente baja los datos de las tasas de cambio y de muy alto ancho de banda).

La mancha que se parte es que todo el proceso es invisible a los servidores involucrados. Si está utilizando SQL Server, diseño de los grupos de archivos para mantener las cosas con una baja tasa de cambio de juntas (al igual que las ventas de los archivos de >3 años), y las cosas con una alta tasa de cambio (como la actual, ventas) en un grupo de archivos independiente. Ellos ni siquiera tienen que estar completamente solo-lectura - sólo quieres diseñarlo de modo que usted puede utilizar diferentes métodos de replicación para cada grupo de archivos. El SAN engranaje de sincronización de lun a través de la red, cinta, o a través de SANs - lo que usted puede enviar partes de la SAN de ida y vuelta. Esto es más eficaz con el equipo como a la Izquierda, donde el SAN se compone de un grupo de unidades participantes.

A continuación, puede sincronizar la baja de la tasa de cambio de las cosas a través de la red de forma automática, sincronización y de la alta tasa de cambio con la sneakernet. (Suena como tengo que hacia atrás, pero es cierto que no se puede sincronizar la alta tasa de cambio de cosas sobre el alambre debido al volumen). Incluso algunos de la gama baja de engranajes se ajusta a esta ahora: a la Izquierda le permite replicar a otras unidades a la Izquierda de su centro de datos, y luego enviarlos a su fuera de las instalaciones de centros de datos. Plug 'em, unirse a ellos en el lado remoto mediante el cambio de IPs y de los grupos, y ahora son parte de su copia de seguridad remota de SAN. El de la Izquierda, echada de ventas en esto, es simplemente brillante: configurar los dos SANs lado-por-lado en su centro de datos principal, obtener de ellos en la sincronización, entonces usted puede enviar partes de ellos sobre el centro de datos remoto, mientras que algunos de ellos se quedan en su actual centro de datos para sincronizar. Poco a poco mover 'em sin camino fuera de sincronización.

Yo no he hecho esto en el petabyte, aunque. Sabes lo que dicen - en teoría, en la teoría y en la práctica son la misma. En la práctica...

3voto

SuperCoolMoss Puntos 982

Interesante video que detalla el myspace.com (arquitectura de SQL2005 backend). No estoy seguro si ellos han individuales petabyte dbs como se escala con varios dbs. Ellos usan SAN complemento de copias de seguridad.

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

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by: