🗂️ Retención de versiones
La retención (retention_json de la tarea) decide cuántos snapshots se conservan antes de podar. Cada modo de copia la usa a su manera.
Cómo funciona
- Versionada/incremental: se conservan los últimos
keep_lastsnapshots (u otros criterios de la política configurada: por edad, por cantidad…). - Mirror: siempre
keep_last=1— no hay historia que retener.
Por qué podar es seguro (aunque parezca que no)
En destinos sin hard links (FTP/SFTP) un snapshot solo guarda lo que cambió respecto a los anteriores. Si se borrara su carpeta entera, la cadena de incrementales quedaría hueca. Por eso:
- La retención nunca borra el árbol de un snapshot: ahí puede vivir la copia base de ficheros que ya no cambian.
- Solo se eliminan versiones que ningún snapshot vivo referencia (
unreferenced_versionsdel índice). - Al restaurar, el motor reconstruye cada fichero desde el snapshot donde se vio por primera vez (
first_seen) — da igual en qué carpeta esté físicamente.
En destinos con hard links (local/red) borrar un snapshot sí libera espacio directamente: el enlace duro desaparece pero el contenido sobrevive mientras otro snapshot lo enlace.
Recomendaciones
- Disco local: 30-90 snapshots suelen ser gratis en espacio gracias a los hard links — genera historia tranquilo.
- FTP/SFTP: cada snapshot extra suma solo sus diferencias, pero cuenta el total de espacio del servidor. 14-30 versiones es un buen equilibrio.
- La poda corre sola tras cada ejecución — nunca borres carpetas de snapshot a mano en el destino: el índice dejaría de reconstruir versiones.
Los errores tipo CRC/mapa.bin que veías en Cobian venían de estado cacheado viejo en el destino. Aquí el índice se regenera si detecta estado inconsistente — si algún día aparece un aviso de estado sucio, deja que el motor reconstruya en la siguiente pasada.