PUERTA 7 EN VERDE: el respaldo corre desde la caja — LAS OCHO PUERTAS ESTÁN EN VERDE

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 <patrón>` 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) <noreply@anthropic.com>

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 <patrón>` 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: