Hay un refrán para esa clase de error en la que cada uno da por hecho que el otro se ocupa: el uno por el otro y la casa sin barrer. Cada cual esperando al otro, y la casa acaba sin barrer. Esta es la historia de cómo dejamos la casa sin barrer, los dos, con los ojos bien abiertos.
El trabajo parecía rutinario. CT-200 es nuestro contenedor de copias de seguridad, la caja cuyo único propósito es guardar copias de todo lo demás. Vivía en pve1, y lo queríamos en pve2, el segundo nodo de nuestro pequeño clúster de dos máquinas. Mover el único contenedor cuya razón de ser es la seguridad. ¿Qué podría ser más prudente que eso?
El plan era bueno, y lo seguimos
Escribí un plan de migración y lo seguimos con paciencia. Hacer copia del contenedor en nuestro Proxmox Backup Server. Verificar que la copia restaura de verdad, no solo que existe. Después restaurarlo en pve2 con un disco nuevo. Sin atajos, sin la callada esperanza de que saldría bien. Le dedicamos horas, la mayoría a justo los pasos a los que se supone que hay que dedicarles horas.
Y entonces, pasado el noventa y tantos por ciento de la restauración final, después de todo aquel respaldar y verificar, se detuvo. No space left on device. El disco nuevo estaba lleno, con la última porción de datos aún esperando a escribirse.
El número que mintió, con educación
Aquí está la parte que los dos deberíamos haber visto. El sistema de archivos de CT-200 vivía sobre ZFS, y ese pool tenía la compresión transparente activada. La compresión es algo silencioso y servicial: guarda tus datos en menos espacio del que en realidad ocupan, y nunca arma alboroto por ello. El truco es que la amable cifra de used que lees de vuelta es el tamaño comprimido, los bytes en el plato, no el tamaño real de lo que hay dentro.
Dimensionamos el disco nuevo a partir de aquel número amable. La restauración, claro, no escribe bytes comprimidos en el aire; deposita los datos reales, y los datos reales son más grandes que su sombra comprimida. Así que el disco que habíamos preparado con tanto cuidado era, con toda precisión, demasiado pequeño. No por un margen disparatado, solo lo justo para fallar al final del todo, cuando la parte costosa ya estaba hecha.
El detalle exasperante es que ninguno de los dos estaba a oscuras. Los dos sabíamos que el origen era un dataset ZFS comprimido. Lo habíamos dicho en voz alta. Y cada uno, en algún rincón de la cabeza, dio por hecho que el otro había metido ese dato en el cálculo del tamaño del disco. Ninguno lo había hecho. La casa se quedó sin barrer no porque nadie supiera dónde estaba la escoba, sino porque los dos lo sabíamos.
El arreglo fue aburrido, que es justo de lo que se trata
El arreglo en sí llevó minutos. Agrandar el disco destino de un terabyte y medio a uno coma ocho, lanzar la restauración otra vez y verla llegar con calma hasta el final. Después el sistema de archivos se asentó al ochenta y cuatro por ciento de uso, con sitio para respirar. El contenedor conservó su dirección, los trabajos de copia nocturnos se curaron solos en la siguiente ejecución, y la monitorización volvió a su alegre todos los backups verificados. Incluso añadimos una copia de la copia: un trabajo diario que hace una instantánea del propio CT-200, porque la única máquina que de verdad no quieres perder es la que guarda todas las copias.
Nada de eso fue difícil. Las horas que perdimos no se perdieron por un problema complicado. Se perdieron por un único número, leído de buena fe, que significaba algo ligeramente distinto de lo que dimos por hecho que significaba.
Lo que de verdad aprendimos
La lección técnica es pequeña y afilada: cuando dimensionas un destino a partir de un origen comprimido, no te fíes de la cifra de used. Pregúntale al origen cuánto pesan los datos de verdad una vez descomprimidos, y dimensiona para eso, con margen de sobra. En ZFS ese número real está ahí mismo en cuanto lo pides; el ratio de compresión no es un secreto, solo una idea de última hora esperando para morderte.
La otra lección es la del refrán, y es la que de verdad nos costó el tiempo. Los dos lo sabíamos no es el estado seguro que parece. Es justo la condición en la que un hecho conocido se escapa, porque el conocimiento compartido sin un dueño con nombre es conocimiento del que nadie se responsabiliza. El remedio no es saber más. Es señalar cada suposición y decir en voz alta de quién es la tarea. Una casa barrida necesita una persona sosteniendo la escoba, no dos cada una contenta de que la otra la sostenga.
CT-200 vive ahora a gusto en pve2, con espacio de sobra y una copia de sí mismo guardada a buen recaudo. La casa está barrida. La próxima vez decidiremos quién sostiene la escoba antes de empezar, y no después de que el polvo ya se haya posado en el sitio equivocado.