🧱 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 tablasmanifests/chunksrecuerdan 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 = falseen 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.