Las copias de seguridad y la recuperación ante desastres de una aplicación se diseñan a partir de dos cifras que decide el negocio: cuántos datos puedes perder (RPO) y cuánto tiempo puedes estar parado (RTO). Con ellas se fija cada cuánto se copia y cómo se restaura. En Codezone lo incluimos en los servicios de mantenimiento y soporte de aplicaciones.
Imagina una distribuidora que factura desde su aplicación a medida y pierde el servidor un martes a mediodía. Si la última copia es de la noche anterior, se pierde media mañana de pedidos; si nadie ha restaurado nunca esa copia, ni siquiera sabe si sirve. Las copias son la última defensa cuando falla todo lo que cubre la seguridad en aplicaciones web según OWASP.
Al terminar podrás fijar tu RPO y tu RTO y pedir una prueba de restauración documentada como parte de la arquitectura del mantenimiento web.
Qué son el RPO y el RTO en copias de seguridad y recuperación ante desastres
El RPO (Recovery Point Objective) es el punto en el tiempo hasta el que deben recuperarse los datos tras una interrupción. El RTO (Recovery Time Objective) es el tiempo total que un sistema puede pasar en recuperación antes de dañar los procesos de negocio. Ambas definiciones proceden del glosario del NIST basado en la SP 800-34 Rev. 1.
Un RPO de 24 horas se cubre con una copia diaria. Un RPO de minutos exige archivar de forma continua el registro de transacciones de la base de datos, lo que en PostgreSQL permite recuperar hasta un instante concreto.
La regla 3-2-1 y las copias inmutables frente a ransomware
La regla 3-2-1 consiste en disponer de tres copias de la misma información en dos dispositivos distintos y guardar una de ellas en un lugar diferente, según la define el INCIBE en su guía sobre copias de seguridad.
El ransomware añade una condición: si el servidor comprometido puede borrar sus copias, el atacante también. La copia externa debe ser inmutable durante su periodo de retención, con funciones como Object Lock de Amazon S3, o estar desconectada. El proveedor elegido condiciona estas opciones; lo detallamos al comparar almacenamiento en Google Cloud y Cloudflare.
Qué copiar de una aplicación a medida
Copiar solo la base de datos deja fuera piezas sin las que la aplicación no arranca:
- Base de datos: volcado lógico diario y, si el RPO es corto, archivado continuo de transacciones.
- Ficheros subidos: facturas en PDF y adjuntos, con versionado en el almacenamiento de objetos.
- Configuración e infraestructura: con contenedores Docker definidos en el repositorio, reconstruir el servidor es repetible.
- Secretos: credenciales y la parte privada del par GPG, guardadas aparte del volcado. Sin ellas, la copia cifrada no se abre.
- Código fuente: en un repositorio de tu propiedad. Quien ha tenido que rescatar un proyecto abandonado por el proveedor sabe lo que cuesta no tenerlo.
Comprueba también dónde guarda las copias tu tipo de hosting y su infraestructura: una copia en el mismo centro de datos no cubre la pérdida de ese centro.
Pruebas de restauración y plan de recuperación documentado
Una copia que nunca se ha restaurado es una suposición. En Codezone trabajamos con estos niveles de comprobación:
- Restauración automática: cada copia se vuelca en una base temporal y se valida antes de darla por buena.
- Simulacro completo: periódicamente, se reconstruye la aplicación desde cero y se mide el tiempo real frente al RTO pactado.
- Plan escrito: responsables y orden de arranque de cada servicio, revisado tras cada simulacro.
Esta capacidad de restaurar la disponibilidad rápidamente es una medida del artículo 32 del RGPD, como explicamos en privacidad desde el diseño y RGPD en el software. Su coste entra en el presupuesto de mantenimiento web en Madrid y conviene pactarlo desde el inicio.
CodeZone Pro Tip: este script de bash genera una copia de PostgreSQL, comprueba que se restaura antes de cifrarla y rota las antiguas.
#!/usr/bin/env bash
# Copia de PostgreSQL con prueba de restauración, cifrado y rotación
set -euo pipefail
DB="${DB:-gestion}"
DESTINO="${DESTINO:-/var/backups/postgres}"
RECEPTOR_GPG="${RECEPTOR_GPG:?Indica el destinatario GPG de las copias}"
RETENCION_DIAS="${RETENCION_DIAS:-14}"
ARCHIVO="${DESTINO}/${DB}-$(date +%Y%m%d-%H%M).dump.gpg"
TMP="$(mktemp)"
BD_PRUEBA="restore_check_$$"
# Limpieza pase lo que pase: ni volcados en claro ni bases de prueba huérfanas
trap 'rm -f "$TMP"; dropdb --if-exists "$BD_PRUEBA"' EXIT
# Formato custom (-Fc): comprimido y restaurable tabla a tabla con pg_restore
pg_dump -Fc --file="$TMP" "$DB"
# Una copia solo vale si restaura: se vuelca en una base temporal y se comparan tablas
createdb "$BD_PRUEBA"
pg_restore --no-owner --exit-on-error -d "$BD_PRUEBA" "$TMP"
SQL="SELECT count(*) FROM information_schema.tables WHERE table_schema = 'public'"
if [[ "$(psql -tAc "$SQL" "$DB")" != "$(psql -tAc "$SQL" "$BD_PRUEBA")" ]]; then
echo "Restauración incompleta de $DB" >&2
exit 1
fi
# Cifrado asimétrico: si atacan el servidor, no puede descifrar las copias que guarda
mkdir -p "$DESTINO"
gpg --batch --yes --trust-model always --encrypt --recipient "$RECEPTOR_GPG" \
--output "$ARCHIVO" "$TMP"
# Rotación local; la copia externa inmutable tiene su propia retención
find "$DESTINO" -name "${DB}-*.dump.gpg" -mtime +"$RETENCION_DIAS" -delete
echo "Copia verificada y cifrada: $ARCHIVO"Con este script, cada copia que llega al almacenamiento ya ha demostrado que se restaura, y una alerta por código de salida distinto de cero avisa el mismo día en lugar del día del desastre. El servidor tampoco puede leer copias antiguas aunque lo comprometan, porque solo guarda la parte pública del par GPG.
Lo Que Cuesta Descubrir que la Copia No Servía
Una empresa sin copia verificada no conoce su RPO real hasta el día que lo necesita. El coste de una prueba de restauración es una base temporal durante unos minutos; el de no hacerla se mide en días de pedidos que hay que reconstruir a mano.
Si no sabes cuándo se restauró por última vez la copia de tu aplicación, pídenos una revisión de tu plan de recuperación.
