Paquete de pérdida accidental de datos y restauración desde backup en retainer de soporte (con IA)

Cuando un cliente con retainer avisa de archivos que desaparecieron, una carpeta vacía o “borramos lo que no tocaba”, no estás ejecutando el playbook de brecha de seguridad: estás ejecutando un playbook de restauración desde backup. El objetivo es acotar qué se perdió, elegir el punto de recuperación correcto, restaurar el mínimo alcance seguro, demostrar integridad y mantener comunicación escrita mientras las horas facturables siguen siendo defendibles.

Este paquete encaja en retainers de soporte activos con reglas de canal, banco de horas y escalados ya definidos. Complementa las guías de P1 urgente y de compromiso de credenciales: aquí el servicio puede seguir en línea, pero los datos están mal o ausentes.

Cuándo usar este paquete

Úsalo cuando el cliente cree que hubo borrado accidental, sobrescritura o corrupción—no cuando sospeches credenciales robadas o acceso activo de un atacante. Si hay phishing o sesiones raras, activa primero el pack de incidente de seguridad y vuelve aquí solo con el acceso saneado.

Disparadores habituales:

• “Alguien vació la Papelera.”
• “Migramos carpetas y ya no está la ruta antigua.”
• “La hoja del martes está en blanco.”
• Piden “restaurar del backup” sin alcance escrito.

Qué necesitas antes de tocar producción

Reúne hechos antes de ejecutar restauraciones:

• Sistema de registro (Microsoft 365, Google Workspace, NAS, export SaaS, vendor de backups de BD).
• Última versión buena conocida (reunión, correo, captura del historial de versiones).
• Alcance (un usuario, una unidad compartida, una BD, todo el tenant—rechaza “restaurar todo” hasta acotar).
• Política de retención (hasta dónde llegan los backups; retención legal si aplica).
• Congelación de cambios acordada (sin migraciones mientras dure la restauración).

Si no hay backup, dilo por escrito pronto. Este pack no inventa copias: documenta opciones y siguientes pasos.

Flujo de extremo a extremo

Paso 1 — Snapshot HECHO/SUPOSICIÓN (ChatGPT)

Pega el hilo del ticket redactado en ChatGPT. Pide hechos vs suposiciones etiquetados y una nota de riesgo de restauración.

Prompt (listo para copiar):

Actúas como lead de soporte tipo MSP. Lee el ticket siguiente.

Entrega:
1) HECHOS (solo lo dicho explícitamente)
2) SUPOSICIONES (etiqueta cada una; qué falta verificar)
3) Tipo probable de pérdida: borrado / sobrescritura / corrupción / desconocido
4) Preguntas al cliente antes de restaurar (máx. 8)
5) Riesgo de restaurar un alcance demasiado amplio (1 párrafo corto)

No inventes nombres de producto de backup. No afirmes éxito de restauración.

Ticket:
[PEGAR HILO REDACTADO]

Guarda la salida en tus notas internas. Reutilizarás los HECHOS en el brief al cliente.

Paso 2 — Brief de restauración de una página (Google Docs)

Crea un Google Doc titulado Brief restauración datos — [Cliente] — [AAAA-MM-DD]. Compártelo en solo lectura cuando envíes el primer correo de estado.

Secciones (una página):

1. Resumen — qué reportó el cliente, en lenguaje claro.
2. Tabla de alcance — rutas, sitios, buzones, nombres de BD, usuarios afectados.
3. Punto de recuperación — fecha/hora con zona horaria + motivo (última versión buena).
4. Origen del backup — producto, job, retención, quién puede ejecutar.
5. Método — granular (archivo/versión) vs snapshot completo; banda de duración esperada.
6. Congelación de cambios — qué se pausa hasta verificar.
7. Política de horas — consumo de retainer vs solicitud de cambio si crece el alcance.
8. Checklist de verificación — ver Paso 6 (copiar al doc).
9. Aprobaciones — nombre + fecha para “proceder con restauración acotada”.

Paso 3 — Verificar backup antes de prometer recuperación

Checklist interno antes de dar ETA al cliente:

• Job de backup OK en la ventana objetivo.
• Retención cubre la fecha objetivo.
• Opción granular identificada (historial de versiones, papelera, point-in-time SaaS).
• Radio de impacto si hace falta snapshot completo.
• Captura o export del estado en consola de backup (solo interno).

Si falla la verificación, actualiza el brief con Opciones A/B/C (reconstrucción parcial, ticket a vendor, CR de pago). Evita “estamos en ello” sin rama escrita.

Paso 4 — Ejecución de restauración acotada

Reglas que protegen a cliente y proveedor:

• Restaura la unidad mínima que corrige la pérdida reportada.
• Prefiere vías no destructivas: carpeta _RESTORE_[fecha] o sitio staging cuando la plataforma lo permita.
• Documenta comandos o clics exactos en anexo interno del brief.
• Si hay sobrescritura inevitable, pide aprobación escrita citando la sección 9.

Al terminar la restauración, no cierres el ticket: pasa a verificación.

Paso 5 — Secuencia Gmail (tres correos)

Misma raíz de asunto: [Cliente] Restauración datos — [fecha].

Correo 1 — Acuse + bloqueo de alcance

• Repite HECHOS del resumen del brief.
• Lista qué verificas (backups, alcance).
• Pide lo que falte: última versión buena, rutas exactas, nombre del aprobador.
• Enlaza o adjunta el Google Doc (solo lectura).

Correo 2 — Plan o bloqueo

• Si verificado: punto de recuperación, método, freeze, banda de ETA.
• Si bloqueado: opción A/B/C recomendada e impacto en horas.
• Pide explícito: responder “Aprobado” en la sección 9 para continuar.

Correo 3 — Resultado

• Qué se restauró, dónde vive (rutas), qué no se restauró.
• Resultados de verificación (muestras, conteos, checksum puntual).
• Riesgos residuales (sync, datos parciales).
• Siguiente paso: conformidad del cliente o CR para huecos.

Tono factual. Es la cadencia del P1 sin lenguaje de caída total si los sistemas siguen online.

Paso 6 — Checklist post-restauración

Visible para el cliente en el brief; tú marcas cada ítem:

• Archivos muestra abren y fechas coinciden con lo esperado.
• Conteos de filas/registros dentro de tolerancia acordada (si hay BD).
• Permisos correctos (sin compartidos públicos accidentales).
• Clientes de sync reindexados (OneDrive/Drive/agentes desktop).
• Sin colisiones de nombres que rompan automatizaciones.
• Contacto confirma elementos críticos de negocio.

Adjunta evidencia con moderación (capturas redactadas). Lo interno va al PSA, no al cuerpo del correo.

Paso 7 — Fila en la revisión mensual del retainer

Añade una línea al export de revisión:

Mes	Tema	¿Restauración?	Clase causa raíz	Acción preventiva
AAAA-MM	Borrado accidental	S	error usuario / migración / vendor	formación, prueba backup, versionado

Conecta el trabajo de restore con la cadencia mensual para no repetir el mismo hueco cada trimestre.

Guías relacionadas en DoAIWork

Más playbooks en la categoría Guías. Si el incidente fue por credenciales o phishing, usa el pack de incidente de seguridad del retainer, no este de restauración. Para caídas en vivo, activa primero el pack P1 urgente y luego la retrospectiva cuando estabilice.

En resumen

La pérdida accidental de datos en un retainer es un problema de alcance, backup y prueba—no de heroísmo. ChatGPT separa hechos de suposiciones, Google Docs concentra alcance y aprobaciones, y Gmail lleva la cadencia de estado que el cliente puede reenviar internamente. Verifica backups antes de prometer, restaura el trozo mínimo seguro, demuestra integridad y registra la lección en la revisión mensual.