PDF-003E Staging Backup Restore Runbook Candidate¶

Fecha local: 2026-06-19

Estado: RUNBOOK CANDIDATE / NOT EXECUTED / STAGING-VPS ONLY / NO SECRETS / REQUIRES EXPLICIT AUTHORIZATION

portal_visible = yes

Scope: tenant

tenant_id: alpuntodeventa

Owner: Gabi / Carlos Canu

Fuente de verdad: docs/tenants/alpuntodeventa/business-observer/production/PDF-003E-STAGING-BACKUP-RESTORE-RUNBOOK-CANDIDATE.md

1. Objetivo del runbook¶

Definir un runbook candidato para backup y restore del futuro staging-vps de Business Observer, de forma que exista una base documental segura, repetible y auditable antes de cualquier ejecucion real de backup, restore, DDL o carga de datos.

Este documento es solo candidato documental. No fue ejecutado. No toca PostgreSQL, no ejecuta SQL, no usa secretos, no invoca pg_dump, pg_restore, no toca VPS y no habilita PDF-004.

2. Safe point¶

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

3. Alcance¶

Incluye:

futuro staging-vps del Business Observer
politica sugerida de backup logico
politica sugerida de restore drill en destino separado
evidencia minima requerida
checklist operativos candidatos
comandos candidatos solo como pseudocodigo seguro
criterios GO/NO-GO para PDF-003F y PDF-004

No incluye:

prod-vps
openclaw-postgres-sandbox
sync diaria
ejecucion real de backup o restore
provision de secretos o cuentas LOGIN
cambios sobre VPS, PostgreSQL, Docker, Portainer, NPM, runtime O4, La Directa o SGC

4. Prerequisitos obligatorios¶

Todo sigue NO-GO si falta cualquiera de estos puntos:

target real de staging-vps definido
fingerprint real publicado
acceso seguro disponible fuera de Git
responsable operativo asignado
ventana de cambio aprobada
storage de backups fuera de Git

Reglas:

host real, endpoint real, credenciales, passwords, connection strings y roles LOGIN reales quedan fuera de Git;
el target debe seguir siendo staging-vps real separado del sandbox;
este runbook no autoriza por si solo ninguna ejecucion real.

5. Politica de backup candidata¶

Tipo sugerido:

backup logico con pg_dump en custom format

Motivos:

permite restore selectivo o completo con pg_restore;
conserva flexibilidad para validaciones posteriores;
evita publicar detalles de infraestructura fisica en Git.

Naming sugerido del artefacto:

text <tenant>__<environment>__<database>__backup__<YYYYMMDD-HHMMSS>__<change-window-or-batch>.dump

Ejemplo seguro:

text alpuntodeventa__staging-vps__openclaw_business_observer_staging__backup__20260619-230000__pre-pdf004.dump

Checksums:

generar SHA256 del artefacto de backup;
guardar el checksum junto al backup o en evidencia operativa separada;
nunca enmascarar un backup faltante con checksum de archivo distinto.

Retencion minima sugerida:

no menor a 7 dias;
sugerido conservar al menos 7 diarios y 2 semanales si la politica operativa lo permite;
si existe una politica superior del equipo operador, prevalece la mas estricta.

Evidencia requerida por backup:

timestamp de inicio y fin
identificador logico del target respaldado
nombre del artefacto
checksum SHA256
tamanio del archivo
ubicacion operativa fuera de Git
resultado final PASS/FAIL
responsable o job que lo genero

6. Politica de restore drill candidata¶

Regla base:

el restore drill debe ejecutarse en un ambiente destino separado del target primario;
no debe usar prod-vps;
no debe usarse el sandbox como reemplazo semantico del staging real.

Validaciones post-restore sugeridas:

apertura exitosa de la DB restaurada
presencia de la DB target esperada
presencia del schema business_observer
presencia de objetos esperados dentro del alcance restaurado
validacion de grants o alcance declarado
confirmacion de que el backup era legible y utilizable

Criterio PASS:

el restore completa sin errores criticos;
el destino restaurado abre correctamente;
las validaciones post-restore quedan consistentes con el alcance esperado;
existe evidencia verificable y repetible.

Criterio FAIL:

backup ilegible, incompleto o corrupto;
restore incompleto o no repetible;
no puede abrirse la DB restaurada;
faltan objetos o validaciones minimas dentro del alcance esperado;
la evidencia no permite auditar el resultado.

Evidencia requerida por restore drill:

timestamp del drill
backup utilizado
destino restaurado
duracion observada
validaciones ejecutadas
resultado final PASS/FAIL
responsable operativo

7. Comandos candidatos seguros¶

Todos los comandos de esta seccion son placeholders o pseudocodigo. No estan listos para ejecutar y no incluyen host real, user real LOGIN, password ni connection string real.

Backup logico candidato¶

powershell pg_dump ` --format=custom ` --file "<BACKUP_OUTPUT_PATH>\\<BACKUP_ARTIFACT_NAME>.dump" ` --host "<STAGING_HOST_ALIAS>" ` --port "<STAGING_PORT>" ` --username "<STAGING_LOGIN_ROLE>" ` --dbname "<STAGING_DATABASE>"

Checksum candidato¶

powershell Get-FileHash "<BACKUP_OUTPUT_PATH>\\<BACKUP_ARTIFACT_NAME>.dump" -Algorithm SHA256

Restore drill candidato¶

powershell pg_restore ` --clean ` --if-exists ` --no-owner ` --host "<RESTORE_DRILL_HOST_ALIAS>" ` --port "<RESTORE_DRILL_PORT>" ` --username "<RESTORE_DRILL_LOGIN_ROLE>" ` --dbname "<RESTORE_DRILL_DATABASE>" ` "<BACKUP_OUTPUT_PATH>\\<BACKUP_ARTIFACT_NAME>.dump"

Post-restore validation candidate¶

text 1. connect to <RESTORE_DRILL_DATABASE> 2. verify expected database opens 3. verify schema business_observer exists 4. verify expected objects/grants within declared scope 5. record PASS/FAIL evidence

8. Checklist pre-backup¶

safe point Git y alcance documental confirmados
target real staging-vps confirmado como distinto del sandbox
fingerprint real vigente disponible
ventana de cambio aprobada
responsable operativo confirmado
storage operativo fuera de Git disponible
naming del artefacto definido sin secretos
evidencia requerida preparada
autorizacion explicita obtenida

9. Checklist post-backup¶

artefacto generado con nombre esperado
checksum SHA256 calculado
tamanio del backup registrado
evidencia PASS/FAIL registrada
ubicacion operativa registrada fuera de Git
backup age inicial registrada
incidentes o warnings documentados

10. Checklist pre-restore¶

backup candidato identificado por nombre y checksum
destino de restore drill separado del target primario
ventana de cambio aprobada
responsable operativo confirmado
alcance del restore declarado
evidencia requerida preparada
autorizacion explicita obtenida

11. Checklist post-restore¶

DB restaurada abre correctamente
schema business_observer validado
objetos/grants esperados verificados segun alcance
resultado PASS/FAIL registrado
duracion del restore drill registrada
restore drill age actualizada
hallazgos y mitigaciones documentados

12. Rollback o recuperacion esperada ante falla¶

Si un backup falla:

abortar el cambio dependiente;
no avanzar a PDF-003F ni PDF-004;
corregir causa raiz antes de reintentar.

Si un restore drill falla:

declarar FAIL;
no considerar valida la politica de recuperacion;
mantener PDF-003F y PDF-004 en NO-GO;
repetir el proceso solo con nueva evidencia y autorizacion.

Si una operacion real futura necesitara revertirse:

el camino esperado es restore desde backup previo validado;
el rollback conceptual de DDL no reemplaza la necesidad del backup;
recovery y rollback deben tratarse como capas complementarias, no intercambiables.

13. Observabilidad minima requerida¶

Minimo a monitorear o publicar como evidencia operativa:

backup age
restore drill age
backup size
last backup status
last restore drill status

Interpretacion minima:

si falta cualquiera de estas cinco senales, el ambiente no debe considerarse listo para cambios DDL controlados;
si backup age o restore drill age superan la politica acordada, el estado operativo pasa a revision obligatoria.

14. GO/NO-GO para PDF-003F y PDF-004¶

PDF-003F puede pasar a GO solo si:

existe target real separado del sandbox
fingerprint real publicado
acceso seguro read-only disponible fuera de Git
politica de backup cerrada con evidencia
restore drill candidate cerrado y listo para validacion operativa
responsable operativo y ventana de cambio definidos

PDF-004 sigue NO-GO hasta que ademas:

exista backup previo real verificable del target correcto
exista restore drill real con resultado PASS
exista observabilidad minima operativa
no haya dependencia del sandbox como staging real

Dictamen actual:

text PDF-003F = NO-GO HASTA TARGET REAL + FINGERPRINT + ACCESO + BASELINE OPERATIVA PDF-004 = NO-GO HASTA BACKUP REAL + RESTORE DRILL PASS + OBSERVABILIDAD MINIMA

15. Riesgos y mitigaciones¶

Riesgo	Impacto	Mitigacion
confundir sandbox con staging real	backup o restore sobre target equivocado	exigir fingerprint real y confirmacion documental `sandbox != staging`
considerar suficiente un runbook no ejecutado	falsa sensacion de recuperacion	marcar el documento como `RUNBOOK CANDIDATE / NOT EXECUTED`
publicar secretos en docs o diff	exposicion sensible	usar solo placeholders, nombres logicos y referencias fuera de Git
backup sin checksum o evidencia	imposibilidad de auditar integridad	exigir `SHA256`, tamanio y resultado `PASS/FAIL`
restore drill sin destino separado	evidencia poco confiable	exigir restore drill en ambiente separado y no productivo
avanzar a `PDF-004` sin restore real	riesgo operativo alto ante error	mantener `PDF-004 = NO-GO` hasta evidencia real `PASS`

16. Proximos safe points recomendados¶

PDF-003F real target read-only preflight
PDF-003G backup execution evidence solo con autorizacion separada
PDF-003H restore drill evidence solo con autorizacion separada
PDF-004 DDL execution solo despues de GO

17. Conclusion¶

text PDF-003E PASS AS DOCUMENTAL RUNBOOK CANDIDATE STATE = RUNBOOK CANDIDATE / NOT EXECUTED SCOPE = STAGING-VPS ONLY SECRETS = OUT OF GIT REAL EXECUTION = NOT AUTHORIZED BY THIS DOCUMENT PDF-003F = STILL NO-GO PDF-004 = STILL NO-GO BACKUP REAL + RESTORE DRILL PASS + OBSERVABILITY = STILL REQUIRED