PDF-003C Staging Prerequisites Backup Restore Access¶

Fecha local: 2026-06-19

Estado: PREREQUISITES DEFINED / TARGET REAL TODAVIA NO PROVISIONADO / PDF-004 SIGUE NO-GO

portal_visible = yes

Scope: tenant

tenant_id: alpuntodeventa

Owner: Gabi / Carlos Canu

Fuente de verdad: docs/tenants/alpuntodeventa/business-observer/production/PDF-003C-STAGING-PREREQUISITES-BACKUP-RESTORE-ACCESS.md

1. Objetivo de PDF-003C¶

Definir los prerequisitos operativos obligatorios para poder crear o usar una DB staging real del Business Observer antes de cualquier nuevo preflight read-only sobre ese target y antes de cualquier posible DDL.

Esta etapa es solo documental. No se toco PostgreSQL, no se ejecuto SQL, no se crearon DB, roles, schemas ni tablas y no se tocaron secretos, runtime, Docker, Portainer, NPM, La Directa, SGC ni O4.

2. Safe point¶

Control	Valor
workspace	`C:\APV\openclawai`
rama esperada	`main`
`HEAD/origin` declarado al iniciar	`c8120e31915dd1af0ec048d4e6c12684e3a875ae`
ultimo commit declarado al iniciar	`docs: define business observer staging target`
decision	`SAFE POINT PASS / DOCUMENTACION ONLY`

3. Por que PDF-004 sigue NO-GO¶

PDF-004 sigue NO-GO porque todavia faltan condiciones basicas que PDF-003, PDF-003B y ahora PDF-003C consideran obligatorias:

no existe target staging real ya provisionado y gobernado;
el target no puede ser openclaw-postgres-sandbox;
faltan host/servicio real, conectividad, DB final y responsables operativos;
falta fingerprint exacto del target real;
falta politica de acceso cerrada con roles LOGIN reales si aplican;
falta backup previo obligatorio con evidencia;
falta restore drill obligatorio con criterio PASS/FAIL;
falta observabilidad minima para disponibilidad, tamanio, conexiones, locks/errores y antiguedad de backup/restore;
por lo tanto todavia no existe base suficiente para reabrir PDF-003 contra un target real ni para ejecutar PDF-004.

4. Target staging requerido¶

Target requerido:

text staging-vps real para Business Observer, separado del sandbox

Estado actual:

NO PROVISIONADO;
NO VALIDADO;
NO FINGERPRINT CERRADO;
NO APTO PARA PDF-004.

Target esperado cuando exista:

environment: staging-vps
database target: openclaw_business_observer_staging
schema target: business_observer
aislamiento respecto de sandbox y de futuro prod
backup/restore y acceso propios

5. Informacion que debe definirse fuera de Git¶

Debe quedar cerrada fuera de Git, en el sistema operativo o vault operativo correspondiente, como minimo esta informacion:

host o servicio real del target staging
puerto o mecanismo de conectividad aprobado
nombre final de la DB real
roles LOGIN reales si aplican
secretos y passwords fuera de Git
responsable operativo del target

Reglas:

la documentacion en Git puede nombrar el identificador logico del secreto o del sistema de custodia, nunca su valor;
staging y prod no comparten credenciales;
si existen LOGIN, deben mapearse a roles de grupo y no recibir permisos directos innecesarios.

6. Fingerprint requerido antes de DDL¶

Antes de cualquier reapertura de PDF-003 y antes de cualquier PDF-004 debe existir un fingerprint exacto y validable, como minimo con:

text environment=<staging-vps> host=<hostname o alias aprobado> runtime_identity=<service/container/instance name> endpoint=<host:port o ruta interna aprobada> current_database=openclaw_business_observer_staging schema_target=business_observer server_version=<postgres version> roles_expected=openclaw_bo_staging_owner|openclaw_bo_staging_writer|openclaw_bo_staging_reader|openclaw_bo_staging_reporting_ro public_privileges=none on target db/schema backup_evidence_id=<ubicacion o referencia operativa> restore_drill_evidence_id=<ubicacion o referencia operativa>

Regla:

si falta un solo componente del fingerprint, el target sigue NO APTO;
no se admite ejecutar DDL sobre un target cuyo fingerprint no coincida con la documentacion vigente.

7. Politica minima de acceso¶

Roles de grupo minimos esperados:

Rol	Objetivo minimo
`owner/admin`	ownership y `DDL` gobernado
`writer`	futuras cargas controladas
`reader`	validacion read-only y consumo base
`reporting_ro`	reporting read-only separado si hiciera falta

Reglas minimas obligatorias:

sin SUPERUSER para aplicacion;
owner/admin no se usa como cuenta rutinaria;
writer puede tener SELECT, INSERT, UPDATE;
writer no recibe DELETE salvo decision explicita futura;
reader y reporting_ro solo lectura;
PUBLIC sin privilegios sobre DB ni schema target;
menor privilegio y separacion de funciones;
membresias y principals LOGIN documentados fuera de Git.

8. Backup previo obligatorio¶

Antes de cualquier DDL o carga debe existir un backup previo obligatorio con:

tipo de backup definido para la DB target real;
ubicacion fuera de Git;
retencion minima definida;
evidencia verificable del backup creado.

Baseline minima recomendada:

backup consistente a nivel DB objetivo antes de DDL;
retencion minima no menor a 7 dias o a la politica operativa superior que aplique;
evidencia minima:
timestamp del backup
nombre logico del target respaldado
ubicacion operativa
checksum o evidencia equivalente
responsable o job que lo genero

9. Restore drill obligatorio¶

Antes de reabrir PDF-003 contra target real debe existir un restore drill obligatorio.

Debe definir:

ambiente destino del restore
evidencia requerida
criterio PASS/FAIL

Baseline minima:

destino de restore separado del target primario, controlado y no productivo;
evidencia requerida:
timestamp del drill
backup usado
target restaurado
validacion de apertura de DB
validacion de objetos/roles esperados o alcance declarado
duracion observada
criterio PASS: el restore abre, deja la DB utilizable para verificaciones y demuestra que el backup sirve para volver al estado esperado;
criterio FAIL: cualquier restore incompleto, no verificable o no repetible.

10. Observabilidad minima¶

Antes de cualquier DDL debe existir observabilidad minima del target real para:

disponibilidad DB
tamanio DB
conexiones
locks/errores
backup age
restore drill age

La evidencia puede vivir fuera de Git, pero el criterio minimo debe quedar documentado.

11. Rollback/restore esperado¶

Antes de cualquier PDF-004 debe quedar claro:

rollback esperado de DDL a nivel operativo;
criterio de abort si el target contiene objetos no contemplados;
restore desde backup previo si el rollback no basta;
separacion entre rollback de objetos y recuperacion desde backup;
retorno al estado anterior sin tocar sandbox ni futuro prod.

12. Checklist GO para reabrir PDF-003 contra target real¶

Todo debe estar PASS:

target staging-vps real definido y provisionado fuera de esta tarea
target confirmado como distinto de openclaw-postgres-sandbox
host/servicio, conectividad, DB y responsable operativo cerrados fuera de Git
roles de acceso minimos definidos y politica de secretos cerrada
fingerprint exacto publicado y validable
PUBLIC = none on target db/schema definido como politica
backup previo obligatorio definido con evidencia y retencion minima
restore drill obligatorio ejecutable o ya evidenciado con criterio PASS
observabilidad minima definida para disponibilidad, tamanio, conexiones, locks/errores, backup age y restore drill age
rollback/restore esperado documentado
nuevo PDF-003 read-only planificado contra el target real

13. Checklist NO-GO¶

Debe seguir NO-GO si ocurre cualquiera de estos puntos:

el target sigue siendo sandbox o no puede distinguirse claramente de el
falta host, DB, conectividad o responsable operativo
faltan roles de acceso o existe riesgo de usar SUPERUSER
el writer requiere DELETE sin decision explicita aprobada
faltan secretos fuera de Git o la custodia no esta cerrada
no existe backup previo verificable
no existe restore drill o su resultado es FAIL
no existe fingerprint exacto
no existe observabilidad minima
no puede demostrarse rollback o restore al estado previo

14. Proximos safe points¶

Safe points recomendados desde PDF-003C:

PDF-003D target provisioning decision record
PDF-003E backup/restore runbook candidate
PDF-003F new read-only preflight against real target
PDF-004 DDL execution only after GO

15. Conclusion¶

text PDF-003C PASS AS DOCUMENTAL PREREQUISITES DEFINITION REAL STAGING TARGET = REQUIRED AND STILL NOT PROVISIONED BACKUP + RESTORE DRILL + ACCESS + FINGERPRINT = MANDATORY WRITER WITHOUT DELETE = DEFAULT POLICY APPLICATION SUPERUSER = NOT ALLOWED PDF-003 CAN REOPEN ONLY AGAINST A REAL TARGET PDF-004 = STILL NO-GO ZERO RUNTIME CHANGES CONFIRMED