No hay productos en el carrito.
Un respaldo vale lo que tarda en restaurarse
Tener copias no es lo mismo que poder recuperarse. La pregunta que importa es otra: si hoy se pierde la base de datos, ¿cuánto tarda tu plataforma en volver a operar y cuántos datos se pierden?
Esas dos respuestas tienen nombre: el tiempo objetivo de recuperación y el punto objetivo de recuperación. Se definen con tu equipo según lo que cuesta cada hora de operación detenida.
Con esos objetivos acordados, se diseña la política de respaldo: frecuencia, retención y ubicación de las copias, siempre fuera del servidor principal.
Qué respaldar y con qué frecuencia
La base de datos, los archivos que suben los usuarios, la configuración y los secretos cifrados. Un respaldo diario de la base de datos se programa así:
# Respaldo diario a las 02:00, comprimido y con fecha 0 2 * * * pg_dump -Fc -f /respaldos/db-$(date +\%F).dump tu_base
Y cada copia se verifica apenas termina, antes de darla por buena:
pg_restore --list /respaldos/db-2026-09-16.dump > /dev/null && echo 'Copia legible'
Una copia que no se puede leer no cuenta como respaldo.
La prueba de restauración
De forma periódica se restaura un respaldo completo en un entorno aparte, se levanta la plataforma y se mide cuánto tardó. Ese número va al reporte.
Una prueba de restauración completa comprueba:
- Que la copia más reciente se restaura sin errores
- Que la plataforma arranca con esos datos
- Cuánto tiempo tomó de punta a punta
- Qué datos se habrían perdido desde la última copia
Lo que queda por escrito
Cada prueba deja un registro con fecha, responsable, duración y resultado. Así tu empresa puede demostrar ante un cliente, un socio o una auditoría que la recuperación funciona.
Un plan de recuperación se prueba antes de necesitarlo. El día del incidente solo se ejecuta lo que ya se ensayó.
| Control | Frecuencia | Evidencia |
| Respaldo de base de datos | Diaria | Copia verificada con fecha |
| Respaldo de archivos | Diaria | Registro de sincronización |
| Restauración completa de prueba | Periódica | Tiempo medido y resultado |
| Revisión del plan | Trimestral | Acta aprobada por tu equipo |
Cuando llega el incidente
Las alertas avisan primero. El responsable técnico asignado sigue el procedimiento ensayado, restaura desde la última copia verificada y te informa en cada paso.
Al cerrar el incidente se documenta qué pasó, cuánto tardó la recuperación y qué se ajusta para la próxima. Una verificación final del servicio restaurado:
curl -s -o /dev/null -w '%{http_code}\n' https://www.tuempresa.com/estado Si la continuidad de tu operación depende de tu plataforma, hablemos de tu proyecto y dejamos tu plan de recuperación probado. Conocé el servicio de nube, velocidad y seguridad.
