Parchive (un acrónimo de parity archive , y formalmente conocido como Parity Volume Set Specification [1] [2] ) es un sistema de código de borrado que produce archivos par para la verificación de la suma de comprobación de la integridad de los datos , con la capacidad de realizar operaciones de recuperación de datos que pueden reparar o regenerar datos dañados o faltantes.
Parchive fue escrito originalmente para resolver el problema de compartir archivos de manera confiable en Usenet , [3] pero puede usarse para proteger cualquier tipo de datos contra corrupción de datos , deterioro de disco , deterioro de bits y daños accidentales o maliciosos. A pesar del nombre, Parchive utiliza técnicas más avanzadas (específicamente códigos de corrección de errores ) que los métodos de paridad simplistas de detección de errores .
A partir de 2014, PAR1 está obsoleto, PAR2 está maduro para un uso generalizado y PAR3 es una versión experimental discontinuada desarrollada por el autor de MultiPar, Yutaka Sawada. [4] [5] [6] [7] El proyecto original de SourceForge Parchive ha estado inactivo desde el 30 de abril de 2015. [8] El autor de la especificación PAR2, Michael Nahas, ha estado trabajando en una nueva especificación PAR3 desde el 28 de abril de 2019. Se publicó una versión alfa de la especificación PAR3 el 29 de enero de 2022 [9] mientras se desarrolla el programa en sí.
Parchive fue diseñado para aumentar la fiabilidad de la transferencia de archivos a través de los grupos de noticias de Usenet . Usenet fue diseñado originalmente para conversaciones informales, y el protocolo subyacente, NNTP , no fue diseñado para transmitir datos binarios arbitrarios. Otra limitación, que era aceptable para las conversaciones pero no para los archivos, era que los mensajes normalmente eran bastante cortos y se limitaban a texto ASCII de 7 bits . [10]
Se idearon varias técnicas para enviar archivos a través de Usenet, como uuencoding y Base64 . Más tarde, el software de Usenet permitió el uso de ASCII extendido de 8 bits , lo que permitió nuevas técnicas como yEnc . Los archivos grandes se fragmentaron para reducir el efecto de una descarga corrupta, pero la naturaleza poco confiable de Usenet permaneció.
Con la introducción de Parchive, se podían crear archivos de paridad que luego se cargaban junto con los archivos de datos originales. Si alguno de los archivos de datos se dañaba o se perdía mientras se propagaba entre servidores de Usenet, los usuarios podían descargar archivos de paridad y usarlos para reconstruir los archivos dañados o faltantes. Parchive incluyó la construcción de pequeños archivos de índice (*.par en la versión 1 y *.par2 en la versión 2) que no contienen ningún dato de recuperación. Estos índices contienen hashes de archivos que se pueden usar para identificar rápidamente los archivos de destino y verificar su integridad.
Como los archivos de índice eran tan pequeños, se reducía la cantidad de datos adicionales que había que descargar de Usenet para verificar que todos los archivos de datos estuvieran presentes y sin daños, o para determinar cuántos volúmenes de paridad se necesitaban para reparar cualquier daño o reconstruir cualquier archivo faltante. Eran más útiles en la versión 1, donde los volúmenes de paridad eran mucho más grandes que los archivos de índice cortos. Estos volúmenes de paridad más grandes contienen los datos de recuperación reales junto con una copia duplicada de la información en los archivos de índice (lo que permite utilizarlos por sí solos para verificar la integridad de los archivos de datos si no hay un archivo de índice pequeño disponible).
En julio de 2001, Tobias Rieper y Stefan Wehlus propusieron la especificación Parity Volume Set y, con la ayuda de otros miembros del proyecto, la versión 1.0 de la especificación se publicó en octubre de 2001. [11] Par1 utilizó la corrección de errores de Reed-Solomon para crear nuevos archivos de recuperación. Cualquiera de los archivos de recuperación se puede utilizar para reconstruir un archivo faltante a partir de una descarga incompleta .
La versión 1 se utilizó ampliamente en Usenet, pero tenía algunas limitaciones:
En enero de 2002, Howard Fukada propuso que se diseñara una nueva especificación de Par2 con cambios significativos: que la verificación y reparación de datos debería funcionar en bloques de datos en lugar de archivos completos, y que el algoritmo debería pasar a utilizar números de 16 bits en lugar de los números de 8 bits que utilizaba PAR1. Michael Nahas y Peter Clements retomaron estas ideas en julio de 2002, con el aporte adicional de Paul Nettle y Ryan Gallagher (ambos autores de los clientes de Par1). La versión 2.0 de la especificación de Parchive fue publicada por Michael Nahas en septiembre de 2002. [14]
Peter Clements escribió las dos primeras implementaciones de Par2, QuickPar y par2cmdline. Abandonado desde 2004, Paul Houle creó phpar2 para reemplazar a par2cmdline. Yutaka Sawada creó MultiPar para reemplazar a QuickPar. MultiPar utiliza par2j.exe (que se basa parcialmente en las técnicas de optimización de par2cmdline) para usarlo como motor de backend de MultiPar.
Las versiones 1 y 2 del formato de archivo son incompatibles. (Sin embargo, muchos clientes admiten ambas).
Para Par1, los archivos f1 , f2 , ..., fn , el Parchive consta de un archivo de índice ( f.par ), que es un archivo de tipo CRC sin bloques de recuperación, y una serie de "volúmenes de paridad" ( f.p01 , f.p02 , etc.). Dados todos los archivos originales excepto uno (por ejemplo, f2 ), es posible crear el f2 faltante dados todos los demás archivos originales y cualquiera de los volúmenes de paridad. Alternativamente, es posible recrear dos archivos faltantes a partir de dos volúmenes de paridad, y así sucesivamente. [15]
Par1 admite hasta un total de 256 archivos de origen y recuperación.
Los archivos Par2 generalmente usan este sistema de nombres/extensión: filename.vol000+01.PAR2 , filename.vol001+02.PAR2 , filename.vol003+04.PAR2 , filename.vol007+06.PAR2 , etc. El número después del "+" en el nombre del archivo indica cuántos bloques contiene, y el número después de "vol" indica el número del primer bloque de recuperación dentro del archivo PAR2. Si un archivo de índice de una descarga indica que faltan 4 bloques, la forma más fácil de reparar los archivos sería descargando filename.vol003+04.PAR2 . Sin embargo, debido a la redundancia, filename.vol007+06.PAR2 también es aceptable. También hay un archivo de índice filename.PAR2 , es idéntico en función al pequeño archivo de índice utilizado en PAR1.
La especificación Par2 admite hasta 32 768 bloques de origen y hasta 65 535 bloques de recuperación. Los archivos de entrada se dividen en varios bloques del mismo tamaño, de modo que los archivos de recuperación no necesitan tener el mismo tamaño que el archivo de entrada más grande.
Aunque Unicode se menciona en la especificación PAR2 como una opción, la mayoría de las implementaciones de PAR2 no admiten Unicode.
El soporte de directorio está incluido en la especificación PAR2, pero la mayoría o todas las implementaciones no lo admiten.
La especificación Par3 se planeó originalmente para ser publicada como una mejora de la especificación Par2. Sin embargo, hasta la fecha, [¿ cuándo? ] ha permanecido cerrada por el propietario de la especificación, Yutaka Sawada.
El 29 de enero de 2019, se inició una discusión sobre un nuevo formato en la sección de problemas de GitHub de la bifurcación mantenida par2cmdline. La discusión condujo a un nuevo formato que también se llama Par3. La especificación del nuevo formato Par3 está publicada en GitHub, pero sigue siendo un borrador alfa a fecha del 28 de enero de 2022. La especificación está escrita por Michael Nahas, el autor de la especificación Par2, con la ayuda de Yutaka Sawada, animetosho y malaire.
El nuevo formato afirma tener múltiples ventajas sobre el formato Par2, entre ellas:
Software para sistemas operativos compatibles con POSIX :
La idea original de este proyecto era proporcionar una herramienta para aplicar los conceptos de capacidad de recuperación de datos de los sistemas tipo RAID a la publicación y recuperación de archivos de varias partes en Usenet.