← Lumbre

Desarrollo de Software con IA Backups y plan de desastre: la diferencia entre un incidente y una catástrofe

Portada de Backups y plan de desastre: la diferencia entre un incidente y una catástrofe

Backups y plan de desastre: la diferencia entre un incidente y una catástrofe

✦ Puedes hacerlo todo bien y aun así perder los datos: un borrado, un disco muerto, un secuestro de la información · Desarrollo de Software con IA · y te lleva 7 minutos

Roadwise Consulting

Contenido modificado tras su publicación

Objetivo: Definir una política de respaldos (qué, cada cuánto, dónde, cómo se prueba la restauración).

7 min Desarrollo de Software con IA 15–99 años
Modo PPTX
Más
Backups y plan de desastre: la diferencia entre un incidente y una catástrofe

Herramientas de la lección

Sorpréndeme

Sobre este contenido

Ir a

Volver a Módulo 11 · Seguridad Cursos Explorar Mi cuenta Salir del modo estudio

No se trata de no fallar: se trata de poder volver

Todo sistema falla alguna vez: hardware, humano, atacante. La pregunta no es «¿puede pasar?» sino «¿cuánto tiempo y cuánto dato pierdo si pasa?». Eso lo define tu política de backups. Y hay una verdad incómoda: un backup que nunca probaste restaurar no es un backup, es una suposición.

Las cuatro preguntas de todo respaldo

Si una de las cuatro está en blanco, tienes un agujero, no una política.
PreguntaQué decidesEjemplo sano
¿Qué?Qué datos respaldas (base de datos, archivos subidos, configuración)la base de datos completa y los archivos
¿Cada cuánto?Frecuencia; define cuánto puedes perder (RPO)cada hora, como automático
¿Dónde?Copias en otro lugar que no comparte tu desastreun servidor distinto + un almacén externo
¿Cómo se restaura?El procedimiento y su prueba periódicarestaurar de mentira cada mes y medir el tiempo

La regla del 3-2-1

  1. 3 copias

    Nunca una sola: si la única falla, se acabó.

  2. 2 medios distintos

    Disco local y nube: no mueren por la misma causa.

  3. 1 fuera del sitio

    Al menos una copia inaccesible desde tu red (a prueba de secuestro/borrado masivo).

Prompt para montar la política

El respaldo solo vale si se puede restaurar

texto
Define e implementa la politica de backups de mi app:\n- respaldo automatico de la base de datos cada hora y retention de 30 dias\n- guarda las copias en un bucket externo, cifradas, NO en el mismo disco que el servidor\n- crea un script `restaurar` que tome la ultima copia y la levante en una base nueva\n- documenta el paso a paso de restauracion y un plan de prueba mensual\n\nNo asumas que el hosting hace backups por mi: confirma y separa ubicaciones.
Pedir el script de restauración junto al de respaldo te obliga a poder volver, no solo a copiar.

Prueba

Haces un backup automático cada noche en el mismo servidor. Un atacante borra la app y los backups. ¿Qué principio se violó?

Un backup que nunca se ha probado restaurando es garantía suficiente de recuperación.

Detecta el plan frágil

Revisas la política de backups de un alumno. Señala el punto que NO lo protege de verdad:

Marca la línea o las líneas con error y pulsa Comprobar.

Responde las cuatro preguntas (qué, cada cuánto, dónde, cómo se restaura) para tu proyecto y pide a la IA un script que respalde y otro que restaure. Haz una restauración de prueba.

No sabes si tienes backup hasta que restauras uno en frío.

Tu texto se guarda sólo en este dispositivo.

Las respuestas y tu progreso se guardan sólo en este dispositivo. Contenido firmado por su autoría mediante Lumbre.
Más sobre esta lección

Comentarios

Inicia sesión para comentar.

Todavía no hay comentarios. Sé la primera persona en opinar.