Copias de Seguridad y Restauración¶
Una copia de seguridad no es el archivo que existe en el almacenamiento; es la restauración que usted puede ejecutar dentro del tiempo que el negocio acepta. Todo cliente que ya perdió datos tenía copias — lo que faltó fue que la restauración funcionara, cupiera en el plazo, o cubriera el instante correcto.
La política estándar de InteSys combina tres capas: copia completa periódica, incrementos entre ellas y un archivo continuo del log de transacciones. Juntas permiten volver no solo a la última copia, sino a un segundo específico antes del error.
El comando destructivo a las 14:07 no es un problema cuando existe log continuo: se restaura a las 14:06:59.
Las capas¶
| Capa | Qué es | Para qué sirve |
|---|---|---|
| Copia completa | Copia integral, periódica | Base de cualquier restauración |
| Copia incremental | Solo lo que cambió desde la anterior | Reduce ventana, costo y tiempo de copia |
| Archivo de log continuo | binlog (MySQL) / WAL (PostgreSQL) enviado continuamente | Permite point-in-time recovery |
| Snapshot de volumen | Copia del volumen entero vía CSI, en segundos | Restauración muy rápida de un clúster completo |
| Copia lógica | Dump legible por otra versión | Migración, extracción parcial, cambio de versión mayor |
Todas las capas salen de los servidores de la base. Una copia en el mismo disco de la base no es copia de seguridad: es una segunda copia del mismo punto de fallo.
Point-in-time recovery¶
El caso que justifica toda la arquitectura no es el incendio en el centro de datos — es el DELETE sin WHERE, el DROP TABLE en la terminal equivocada, el deploy que corrompió datos durante tres horas hasta que alguien lo notó.
Con log continuo, la restauración es:
- restaurar la última copia completa anterior al incidente;
- aplicar los incrementos hasta el punto disponible;
- reproducir el log de transacciones hasta el segundo inmediatamente anterior al comando destructivo;
- validar y liberar.
Lo que define cuánto se pierde es la frecuencia del envío del log, no la de la copia completa.
Snapshot de volumen cifrado¶
En los clústeres en Kubernetes, además de la copia lógica y física, usamos snapshots de volumen (VolumeSnapshot vía CSI): una copia del volumen entero, tomada en segundos, sin recorrer la base.
- Snapshot consistente — el operador coordina el flush y el congelamiento de la escritura antes de disparar el snapshot, para que el volumen copiado sea restaurable.
- Siempre en volumen cifrado — la clave es gestionada por InteSys o provista por el cliente.
- Copia cifrada en tránsito — la replicación del snapshot hacia otro destino viaja cifrada.
- Restauración de clúster completo — el snapshot devuelve el estado del volumen; para volver a un instante intermedio, el log continuo sigue siendo necesario.
| Destino del snapshot | Cuándo elegirlo |
|---|---|
| br-sp-1 y br-sp-2 (Brasil) | Estándar. Mantiene la residencia de los datos y el tratamiento enteramente bajo la LGPD. |
| Otro país | Aislamiento geográfico de la copia, exigencia corporativa o plan de continuidad que pide una copia fuera del territorio nacional. Pasa a existir transferencia internacional, documentada en el diseño de la solución. |
El destino es elección del cliente, no un valor por defecto de la plataforma
Ningún snapshot sale de Brasil por iniciativa nuestra. La copia en otro país se configura solo a pedido, con la base legal de la transferencia registrada junto al diseño del clúster.
Retención¶
La política se acuerda por cliente, pero el formato estándar es escalonado:
| Rango | Retención típica | Uso |
|---|---|---|
| Últimas 24–72 h | Log continuo completo | Recuperación puntual de error humano |
| Últimos 30 días | Diarias | Incidente descubierto con retraso |
| Últimos 12 meses | Mensuales | Exigencia contractual y auditoría |
| Más allá | Bajo demanda | Obligación legal o sectorial específica |
La retención también es obligación de descarte. Un dato personal mantenido más allá de lo necesario es un pasivo bajo la LGPD; la política define tanto cuánto guardar como cuándo borrar.
Cifrado y acceso¶
- En reposo — toda copia queda en volumen o almacenamiento de objetos cifrado.
- En tránsito — la transferencia siempre va por canal cifrado.
- Acceso separado — quien administra la base no es necesariamente quien puede borrar copias. Las credenciales de retención son distintas de las operativas.
- Inmutabilidad cuando se exige — retención con bloqueo de borrado, para escenarios de ransomware o exigencia regulatoria.
Prueba de restauración¶
La parte que casi todo el mundo omite, y la única que prueba que el resto funciona.
| Prueba | Frecuencia | Qué valida |
|---|---|---|
| Restauración automatizada en entorno aislado | Mensual | La copia abre, la base levanta, los datos están |
| Verificación de checksum | En cada copia | El archivo no se corrompió en el camino |
| Restauración puntual (PITR) de muestra | Trimestral | El log continuo cubre el período prometido |
| Restauración completa cronometrada | Semestral | El RTO acordado es real, no estimado |
Una copia nunca restaurada es una suposición, no una protección
Una copia con archivo corrupto, con versión incompatible o que tarda 14 horas en restaurarse se ve sana en cualquier panel. Solo la prueba lo muestra.
Páginas Relacionadas¶
- Recuperación ante Desastres — Dónde entran las copias en el plan mayor
- Replicación — Una réplica no es una copia: también replica el
DROP TABLE - Administración — Verificación diaria y revisión de retención
- Instalación — La política definida el día uno
- Alta Disponibilidad MySQL · PostgreSQL · ClickHouse