From 35fed3aa65459d854ca0cb1422bc3130a01d03f1 Mon Sep 17 00:00:00 2001 From: Sergio Date: Thu, 17 Sep 2026 16:58:47 +0000 Subject: [PATCH] =?UTF-8?q?PUERTA=207=20EN=20VERDE:=20el=20respaldo=20corr?= =?UTF-8?q?e=20desde=20la=20caja=20=E2=80=94=20LAS=20OCHO=20PUERTAS=20EST?= =?UTF-8?q?=C3=81N=20EN=20VERDE?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit respaldados (manifiesto del Storage Box): 3686 en el store de la caja: 1320 de la caja, NO respaldados: 0 ← la cuenta que decide errores y reintentos: 0 y 0 Pero la primera corrida no terminó, y el motivo vale por sí solo: se cayó 40 veces con el MISMO fichero porque una transferencia interrumpida el 11-sep había dejado un parcial en el destino con el modo del origen (-r--r--r--, el store es de sólo lectura por diseño). Ningún intento posterior puede reescribirlo: esa ruta quedaba envenenada PARA SIEMPRE, y el bucle la golpeaba cada 60 s llamándola «corte de red». Arreglado con --chmod=Fu+w (un corte a mitad se retoma) y dando al rsync 23 tres intentos en vez de cuarenta, nombrando la causa probable al tercero. 🪤 Y dos veces el mismo error mío en la misma tarde: `pgrep -f ` SE ENCUENTRA A SÍ MISMO —el patrón está en la línea de comando del propio pgrep y del ssh que lo lanza—, así que «sigue corriendo» era verdad para siempre y el vigía que armé con esa condición nunca podía dispararse. La forma correcta es el truco del corchete: `grep "[r]espaldo-storagebox"`. Hermano del `pkill -f` que mata tu propia shell. Lo que separa esto del borrado de gioser ya no es técnico: es la decisión del usuario, a mano y nunca por automatización. Co-Authored-By: Claude Opus 5 (1M context) --- docs/28-servidor-de-produccion.md | 55 ++++++++++++++++++++++++++++--- 1 file changed, 51 insertions(+), 4 deletions(-) diff --git a/docs/28-servidor-de-produccion.md b/docs/28-servidor-de-produccion.md index 504c2b84..5331719f 100644 --- a/docs/28-servidor-de-produccion.md +++ b/docs/28-servidor-de-produccion.md @@ -2749,16 +2749,63 @@ identidad de la distro, y su fallo queda anotado para mirarlo aparte. | 4 | **la granja late en la caja** | ✅ **§6.43** — con el lab pineado; la caja gana por uno en los dos grafos | | 5 | **el repo se sirve y el host se instala de él** | ✅ **§6.46** — 171 paquetes publicados y `install --require-signed` en verde | | 6 | cada dominio vivo responde 200 | ✅ los 8 | -| 7 | el respaldo corre desde la caja | ⏳ **corriendo**: primera corrida completa en marcha (el Storage Box ya tiene 152 G de antes) | +| 7 | el respaldo corre desde la caja | ✅ **§6.48** — corrida completa, 0 errores, y **0 artefactos de la caja sin respaldar** | | 8 | lo fósil, anotado y decidido | ✅ | -⇒ **siete en verde y una en curso.** Lo que separa a esto del borrado de gioser ya no es técnico: es -la corrida de respaldo terminando y la decisión del usuario, que es como el §6 dice que tiene que -ser — a mano, con las ocho en verde, **nunca por automatización**. +⇒ **LAS OCHO EN VERDE** (§6.48 cerró la última). Lo que separa a esto del borrado de gioser ya no es +técnico: es la decisión del usuario, que es como el §6 dice que tiene que ser — a mano, con las ocho +en verde, **nunca por automatización**. Y lo que queda vivo en gioser es el trabajo de la mudanza, no servicios: los ~10 G de árboles personales de `/home` sin decidir (§6.35) y el montón de `[[datos]]` que el censo dejó sin decisión. +### 6.48 ✅ Puerta 7: el respaldo corre desde la caja — y el parcial que la envenenaba *(2026-09-17)* + +``` + respaldados (manifiesto del Storage Box) : 3686 + en el store de la caja : 1320 + de la caja, NO respaldados : 0 ← la cuenta que decide + errores y reintentos en la corrida : 0 y 0 +``` + +**Las ocho puertas quedan en verde.** + +#### ⚠ Pero la primera corrida NO terminó, y el motivo vale por sí solo + +Se cayó **40 veces seguidas con el MISMO fichero**: + +``` + open ".../fonts/dejavu/.rsync-partial/DejaVuSans-Oblique.ttf" failed: No such file… (2) + .. store: corte de red (rsync 23). Intento 39; reanudo en 60s. + !! store: 40 intentos y sigue cayéndose. Dejo lo subido y paro. +``` + +No era red. Una transferencia interrumpida **el 11 de septiembre** había dejado ese parcial en el +destino con el modo del origen —`-r--r--r--`, porque el store es de sólo lectura por diseño— y +**ningún intento posterior puede reescribirlo**. El fallo es ETERNO: esa ruta quedaba envenenada +para siempre, y el bucle la golpeaba cada 60 segundos llamándola «corte de red». Es exactamente la +pared que la cabecera de esa función dice que no hay que golpear cuarenta veces. + +Dos arreglos, y el segundo importa más que el primero: + +1. **`--chmod=Fu+w`** en el rsync: los ficheros del respaldo quedan escribibles por su dueño, así que + un corte a mitad se RETOMA en vez de trabarse. El precio —no conservar el bit de sólo-lectura en + la copia— es bajo: lo que se respalda es el contenido, y los permisos los reconstruye el store. +2. **Al `rsync 23` se le dan TRES intentos, no cuarenta**, y al tercero se NOMBRA la causa probable. + El 23 es «some files were not transferred», que tanto puede ser un cable como una pared; tratarlo + siempre como cable es lo que convirtió un fallo permanente en cuarenta minutos de ruido. + +#### 🪤 Y dos veces el mismo error mío: `pgrep -f ` se encuentra a SÍ MISMO + +Para saber si el respaldo seguía vivo usé `pgrep -f respaldo-storagebox`… y el patrón está en la +línea de comando del propio `pgrep` (y del `ssh` que lo lanza). Resultado: **decía «sigue corriendo» +para siempre**, incluso con el script muerto hacía rato — y el vigía que armé con esa condición +nunca podía dispararse. Pasó dos veces en la misma tarde, en las dos máquinas. + +La forma correcta es el truco del corchete —`ps ... | grep "[r]espaldo-storagebox"`—, que no coincide +consigo mismo porque el patrón literal `[r]espaldo` no aparece en la línea del grep. Es hermano del +`pkill -f` que mata tu propia shell, ya anotado en las memorias. + ## 7. Reusar los scripts que ya existen, y no escribir de nuevo Pedido explícito del usuario. El inventario de lo que ya hace el trabajo: