¿Cómo hacen una copia de seguridad de sus datos las grandes empresas?

¿Cómo las empresas que manejan grandes cantidades de datos, por ejemplo Google o Facebook, respaldan todo?

Según este artículo de la plataforma de Google en Wikipedia, Google tiene aproximadamente 450,000 servidores cada uno con un disco duro de más de 80 GB. Esa es una gran cantidad de datos. ¿Realmente conservan 1 GB de copia de seguridad por cada 1 GB de datos?

Depende de cuál sea tu propósito.

Si está buscando copias de seguridad para la recuperación ante desastres (servidor explotado, centro de datos quemado, etc.), la respuesta breve es que es posible que no realicen copias de seguridad. Tenemos un cliente que maneja datos confidenciales del gobierno, y parte de su mandato es que no se nos permite hacer copias de seguridad o copias de seguridad en medios extraíbles . Se nos permite la replicación en vivo en un sitio de recuperación ante desastres y eso es todo. Ambos sitios están cubiertos en el mismo nivel de seguridad física y lógica. El problema aquí es que si arruino algo en el sitio A, entonces se replica al sitio B casi al instante.

Si está hablando de copias de seguridad desde el punto de vista de la integridad de los datos (p. Ej., Eliminó accidentalmente la tabla Clientes y ya está replicada en el sitio de recuperación ante desastres), las cintas LTO-5 en una gran biblioteca de cintas son a menudo el camino. Con hasta 3 TB por cinta y múltiples cintas en una biblioteca de cintas, puede hacer una copia de seguridad de grandes cantidades de datos rápidamente (aquí se refiere rápidamente a Mbps, aún puede llevar muchas, muchas horas hacer una copia de seguridad de 25 TB de datos).

Cualquier suite de respaldo decente realizará una alta compresión y eliminación de duplicados, lo que reduce enormemente la cantidad de espacio de almacenamiento requerido. Una vez vi una estimación de una herramienta de copia de seguridad de Exchange comprimida y duplicada que afirmaba una relación de 15: 1 (15 gb de datos almacenados en 1 gb de copias de respaldo).

Dudo mucho que Google se moleste con las copias de seguridad de gran parte de los datos de su motor de búsqueda, porque la mayor parte es reemplazable, y se distribuye tanto que si pierden incluso una porción significativa, o tal vez incluso un centro de datos completo, el sistema permanece en línea gracias a las rutas de conmutación por error BGP.

En realidad, parece que Google hace una copia de seguridad de una tonelada métrica de datos en cinta , que no es exactamente lo que esperaba:

La mayoría de sus datos se almacenan en su propio sistema de archivos GFS, y GFS requiere que haya al menos tres copias de cada bloque de 64 MB que forma un archivo (GFS usa bloques de 64 MB). Dicho esto, no creo que se molesten con las copias de seguridad, ya que tienen al menos tres copias de cada archivo, y los bloques en el nodo que falla pueden reemplazarse rápidamente simplemente replicando los datos de cualquiera de las dos copias válidas restantes en un nuevo nodo.

Para obtener más información, visite http://labs.google.com/papers/gfs.html

La respuesta de farseeker es buena, pero creo que podría aclararse al pensarlo desde esta perspectiva: ¿Qué estás tratando de restaurar? ¿Es para DR? ¿Cuál es el tiempo de recuperación requerido? Como ejemplo, suponga que su empresa depende de una base de datos de servidor sql de 25 TB. En caso de falla o error de datos (tabla eliminada, base de datos corrupta, etc.), el CTO desea poder recuperar la base de datos en menos de una hora. En caso de falla del sitio se requieren 2 horas.

A primera vista, esto suena difícil, pero no es imposible. Como sabe que su estrategia de copia de seguridad debe recuperarse en una hora, sabe que no va a restaurar copias de seguridad completas, tendrá que trabajar con los equipos de dba para asegurarse de que la base de datos esté dividida en fragmentos manejables. También va a realizar copias de seguridad frecuentes de trans-log. Para DR debería estar buscando una estrategia de replicación (tal vez una versión con retraso de tiempo con datos de registro replicados en tiempo real pero no aplicados). Como farseeker dijo, depende del propósito, y ese propósito debería ser hacer alguna forma de recuperación.