🧱 Ficheros grandes por bloques

Subir un .vhdx de 40 GB por FTP es frágil: cualquier corte obliga a repetir. Por eso los destinos sin hard links (FTP/SFTP) trocean los ficheros grandes.

Cómo funciona

  • Un fichero ≥ 64 MiB se divide en bloques de 4 MiB.
  • Cada bloque se comprime con zstd cuando compensa y se guarda en el destino en <tarea>/bloques/ab/<hash> — el nombre del bloque es su propio hash, así que bloques idénticos se suben una vez aunque aparezcan en versiones distintas.
  • La versión del fichero queda descrita por un manifiesto <ruta>.iobk-bloques: la lista ordenada de sus bloques.
  • En el índice, entries.storage = 'blocks' y las tablas manifests/chunks recuerdan qué subió ESTE motor.

Reanudación

Si la subida se corta al 80%, la siguiente pasada solo repite los bloques que faltan — los ya presentes se verifican por hash, no se reenvían.

Restaurar

Para leer una versión por bloques siempre se usa el manifiesto (blocks::open_version): el motor descarga los bloques que falten, los reconstruye y verifica. Transparente para ti — restauras el fichero como cualquier otro.

Limpieza (GC)

blocks::gc solo borra bloques que este motor subió y que ya no referencia ningún manifiesto vivo — nunca toca bloques de otros motores que compartan destino.

Cuándo no se usa

  • options.blocks = false en la tarea lo desactiva.
  • En destinos locales (con hard links) no hace falta: ahí manda el hard link / la copia entera, que es instantánea.

Consejos

  • Bases de datos y discos virtuales grandes cambian a cachos pequeños: los bloques convierten una subida imposible en incrementales viables.
  • Comprimir ayuda en documentos/dumps; en vídeo ya comprimido el motor detecta que no compensa y sube el bloque tal cual.