¿Rentable, archivo a largo plazo de datos de video e imagen? ~ 50 TB

Mi laboratorio está en proceso de configurar un pequeño servidor que contiene datos (principalmente datos de video e imagen, más algunos documentos) para el proyecto en el que nuestro grupo está trabajando en un momento dado. Históricamente, después de que termina un proyecto de investigación, los datos terminan siendo archivados al azar en un disco duro, o en una gran pila de DVD (o CD en los viejos tiempos), y / o parte del video terminó en casetes DV de Sony o incluso Cintas VHS (este laboratorio ha estado activo desde principios de los 90), O una mezcla de todo lo anterior ...

Pregunta: ¿Cuál es la mejor manera de (1) consolidar TODOS en el mismo formato Y medio de almacenamiento, y (2) ¿cuál es el mejor medio para el archivo a largo plazo de dichos datos para un acceso muy ocasional (por ejemplo, más de 30 años?)? Desafortunadamente, no tenemos un presupuesto de nivel empresarial (solo somos un laboratorio de ~ 10 personas), por lo que no podemos hacer cosas que cuestan cientos de miles de dólares.

¡Gracias!

PD: Teniendo en cuenta que nuestro video e imágenes anteriores son de menor resolución, pero los recientes son enormes, creo que estamos hablando de 30 ~ 40 TB para los datos realmente antiguos, otros 10 ~ 20 TB para datos recientes, luego adiciones anuales de aproximadamente 5 TB .

Desafortunadamente, no hay mejor manera para ti. El archivo de 30 años de los medios digitales es un problema muy difícil y requiere una inversión de rutina. Los únicos formatos garantizados para ser legibles en 30 años son ASCII y UTF8, que no son formatos de video. Los formatos de almacenamiento cambian, las cintas de 8 pistas de carrete a carrete que estábamos usando hace 30 años son casi imposibles de leer en estos días a pesar de que los datos todavía están en la cinta (hay una historia interesante sobre la NASA que está reconstruyendo una unidad de cinta de 40 años) para obtener algunas cintas de datos Apollo recientemente recuperadas / descubiertas). Su mejor opción es comprometerse a evaluaciones periódicas, diría que cada 5 años, de su entorno de archivo con un presupuesto suficiente para llevar los formatos antiguos a formatos más nuevos.

Probablemente lo sepas mejor que yo, pero el panorama del video está cambiando rápidamente. La edición en línea en tiempo real ahora es posible, donde solo era factible en un kit realmente bueno incluso hace 10 años. Quién sabe cómo se verán las cosas dentro de 30 años.

• Establezca su ventana de archivo por 5 años.
  • En el término inmediato, una gran variedad de almacenamiento debería ser suficiente (
    • Se puede obtener un disco grande y lento de 50TB por menos de $ 70K, posiblemente muy por debajo.
    • Se puede obtener una unidad de cinta LTO5 y 50 cintas (más de 50 TB) por menos de $ 15K.
• El formato en el que almacene su video depende de usted.
• Comience a buscar y convertir todas sus cosas antiguas en este nuevo almacenamiento.
• Al cabo de 5 años, realice otra evaluación completa de su entorno de archivo.
  • ¿Qué formatos estás usando?
  • ¿Cuáles son los formatos más nuevos?
  • ¿Qué códecs parecen ser callejones sin salida, y qué medios ha almacenado codificado de esa manera?
  • Decida cómo va a migrar a métodos de almacenamiento más nuevos (formatos de datos, disco / cinta / algo más), y gaste adecuadamente.
• Repite 6 veces.

Eso debería llevarte a 30 años.

Estoy totalmente de acuerdo con la publicación de sysadmin1138 en todos los aspectos, salvo una advertencia: no creo que vaya a tener el presupuesto para lograr realmente lo que quiere.

Hay 5 funciones principales que necesita crear;

• una política de contenido y catálogo estandarizada: sé que desea almacenar todo en un formato, pero realmente debería considerar dos: PDF para imágenes y H.264 para video; ambos son formatos de soporte a largo plazo con código multiplataforma que casi sin duda contará con el respaldo de una parte u otra durante 25-50 años en su forma actual simplemente debido al uso existente en todo el mundo.
• un catálogo o CMS para indexar y publicar el contenido.
• un sistema de 'ingesta de contenido': esto tomará todos sus medios, paquetes, codificar, almacenar y actualizar el catálogo para cada nueva pieza de contenido. También necesitará un control de calidad de contenido manual o automatizado.
• un almacén de contenido primario: tendrá dos bloques de almacenamiento principales; uno pequeño para contener el contenido de origen mientras se transcodifica / verifica y un bloque mucho más grande para mantener el contenido 'cerca'. Este es uno de los únicos usos válidos para RAID 6 que he encontrado, pero trate de usar discos de calidad empresarial que tengan un 'ciclo de trabajo' 24x365 aquí.
• sistema de respaldo a largo plazo: aquí es donde se gastará el dinero real, deberá seleccionar un proveedor que ofrezca una capacidad de respaldo genuinamente a largo plazo. Si estuviera haciendo esto ahora, seguiría con la cinta sobre el disco simplemente por razones de longevidad de datos, tal vez por IBM, ya que tienen mucha experiencia en esta área. También debe tener en cuenta que también debe realizar restauraciones de cinta y verificaciones de datos regulares, lo que significa que necesitará un tercer bloque de almacenamiento al menos tan grande como la cinta más grande que tenga, y los sistemas para verificar también, por supuesto. Además de eso, deberá asegurarse de que el software de copia de seguridad que utiliza también estará disponible durante mucho tiempo, algo como TAR en * nix probablemente estará disponible por un tiempo, pero es posible que no le brinde funcionalmente lo que desea. asegúrese de que su proveedor de cintas no pase por alto esto.

Entonces, lo que quieres hacer se puede hacer, lo he hecho varias veces durante las últimas dos décadas, pero me temo que ninguno fue barato.

Buena suerte.

Los otros han dado buenos consejos sobre cómo respaldar sus medios. Te sugiero que pases un tiempo de calidad mirando las guías de la biblioteca del congreso:

http://www.digitalpreservation.gov/formats/index.shtml

También podría considerar construir una matriz ZFS de whitebox barata. Probablemente podría hacer algo para satisfacer sus necesidades por menos de $ 10k. A medida que las unidades mueren, reemplácelas por otras más grandes, de modo que su capacidad de almacenamiento aumente a medida que genera datos. Eso probablemente lo mantendrá en funcionamiento durante bastante tiempo, y puede reemplazarlo con un dispositivo de mayor capacidad cuando envejezca. La ventaja es que sus datos están en línea (y, por lo tanto, se puede acceder a ellos según sea necesario), y están relativamente bien protegidos contra Bitrot, un problema grave cuando tiene esta cantidad de datos.

Aquí se creó una opción de compilación decente:

http://www.zfsbuild.com/

Tan difícil como es para los tecnólogos, recomendaría detener inmediatamente los pensamientos sobre discos y tecnología. Divide tu problema de negocios en cosas sobre las que tienes que tomar decisiones.

Ejemplo:

• ¿Cómo va a lidiar con la conversión de formatos de cintas digitales analógicas / misceláneas en medios digitales que pueden almacenarse en algún tipo de almacenamiento digital?
• ¿Cómo va a administrar el contenido y los metadatos asociados? El almacenamiento es fácil: podría poner todo en cinta LTO y almacenarlo en una antigua mina de sal, pero no tendría acceso a los datos.
• ¿Estás reinventando la rueda? Si está en una universidad, ¿existen soluciones para la gestión de contenido disponibles de forma centralizada? O si necesita comprar / construir su propia gestión de contenido, ¿existe una infraestructura centralizada de la que pueda comprar una pieza? (Cinta, almacenamiento de objetos, SAN)
• ¿Cuáles son los requisitos comerciales reales? ¿Qué es lo que realmente quieres conservar y por qué? A menudo, cuando realmente profundiza en el meollo del asunto, los requisitos reales de retención a largo plazo en realidad se aplican solo a un pequeño subconjunto de datos.

Tenga en cuenta que si almacena datos en un formato con pérdida, y luego convierte a otro formato con pérdida, y luego a otro, la calidad de su video se degradará con cada transición.

Lo siguiente está hablando de audio, pero lo mismo se aplica generalmente:

Puede convertir cualquier formato de audio a Ogg Vorbis. Sin embargo, la conversión de un formato con pérdida, como MP3, a otro formato con pérdida, como Vorbis, generalmente es una mala idea. Los codificadores MP3 y Vorbis logran altas relaciones de compresión al desechar partes de la forma de onda de audio que probablemente no escuche. Sin embargo, los códecs MP3 y Vorbis son muy diferentes, por lo que cada uno de ellos desechará diferentes partes del audio, aunque ciertamente hay cierta superposición. Convertir un MP3 a Vorbis implica decodificar el archivo MP3 de nuevo a un formato sin comprimir, como WAV, y volver a comprimirlo usando el codificador Ogg Vorbis. Al MP3 descodificado le faltarán las partes del audio original que el codificador de MP3 eligió descartar. El codificador Ogg Vorbis descartará otros componentes de audio cuando comprima los datos. A lo mejor, el resultado será un archivo Ogg que suena igual que su MP3 original, pero lo más probable es que el archivo resultante suene peor que su MP3 original. En ningún caso obtendrá un archivo que suene mejor que el MP3 original.

Dado que muchos reproductores de música pueden reproducir archivos MP3 y Ogg, no hay razón para que deba cambiar todos sus archivos a un formato u otro. Si le gusta Ogg Vorbis, le recomendamos que lo use cuando codifique desde fuentes de audio originales y sin pérdidas (como CD). Al codificar desde originales, encontrará que puede crear archivos Ogg que son más pequeños o de mejor calidad (o ambos) que sus MP3.

(Si debe convertir absolutamente de MP3 a Ogg, hay varios scripts de conversión disponibles en Freshmeat).

http://www.vorbis.com/faq/#transcode

Por lo tanto, probablemente sea mejor elegir un formato sin pérdida, porque una vez que elige un formato con pérdida, está atascado con él.

Tal vez hay algo que me falta, ¿no podría codificar todo usando un formato abierto donde el código fuente de los códecs está disponible, y luego simplemente pegarlo todo en Amazon S3?

De esa manera, Amazon debe preocuparse por el almacenamiento real de los datos y, a menos que no haya computadoras que puedan compilar C / C ++ en 30 años, podrá obtener la información ...