# Estrategia de copias de seguridad para servidores: la regla 3-2-1

> Estrategia de copias de seguridad para servidores con la regla 3-2-1: qué copiar, cómo sobreviven a un ataque y por qué probar la restauración.

Fuente: https://phpsos.de/es/ratgeber/backups-3-2-1/  
Actualizado: 25/10/2026  
Proveedor: PHP SOS, Ayuda de emergencia para PHP y seguridad de servidores. Ayuda inmediata por WhatsApp: https://wa.me/491736494914?text=Hola%20PHP%20SOS%2C%20necesitamos%20ayuda%20con%20nuestro%20servidor%20PHP.%20Empresa%3A%20%E2%80%A6%20Sitio%20web%3A%20%E2%80%A6

**En resumen:** una estrategia fiable de copias de seguridad para servidores sigue la regla 3-2-1: tres copias, dos tipos de almacenamiento, una copia fuera de la sede. Para que las copias sobrevivan también a un ataque, al menos una copia necesita protección frente al borrado por el propio servidor. Y solo una prueba de restauración exitosa demuestra que la copia funcionará en caso de emergencia.

## Qué significa la regla 3-2-1

La regla 3-2-1 es un principio sencillo, acreditado desde hace años, para la copia de seguridad de datos:

- **3 copias:** los datos originales y dos copias de seguridad.
- **2 tipos de almacenamiento:** por ejemplo disco local y almacenamiento de objetos, o almacenamiento del servidor y cinta.
- **1 copia fuera de la sede:** en otra ubicación, con otro proveedor o sin conexión.

Para los servidores web esto significa en concreto: una copia en el mismo disco que el sitio web no cuenta como copia independiente. Si el servidor falla o se ve comprometido, se pierden ambos. Para la dirección, la pregunta central no es, por tanto, «¿Tenemos copias de seguridad?», sino «¿Podemos restablecer la actividad a partir de una copia a la que el incidente no haya llegado?»

## Una estrategia de copias para servidores que sobreviva a un ataque

Los atacantes saben que las copias de seguridad echan por tierra su trabajo. Quien tiene acceso a un servidor suele buscar también copias para borrarlas o cifrarlas. Por eso, una estrategia moderna amplía con frecuencia la regla 3-2-1 a **3-2-1-1-0**: una copia adicional sin conexión o inmutable, y cero errores en la prueba de restauración.

Tres principios hacen resistentes las copias de seguridad:

- **Pull en lugar de push:** un sistema de copias independiente recoge los datos del servidor web. El propio servidor web no tiene credenciales con las que pudiera borrar copias.
- **Inmutabilidad:** almacenamiento de objetos con bloqueo de retención o instantáneas que no se pueden borrar durante un tiempo establecido.
- **Accesos separados:** la cuenta de copias no es la misma que la cuenta de cliente del hosting y tiene su propio segundo factor.

> **Importante:**
> Cifre las copias que se guarden fuera de la sede y custodie la clave por separado. Una clave perdida inutiliza la copia; una clave guardada junto a ella deja el cifrado sin valor.

## Qué hay que copiar

En los servidores web, a menudo solo se copia el webroot. Para una restauración completa faltan entonces partes importantes.

| Ámbito | Ejemplos | Observación |
|---|---|---|
| Archivos de la aplicación | Webroot, subidas, temas, extensiones | Las subidas cambian con frecuencia |
| Bases de datos | MySQL/MariaDB, PostgreSQL | copiar de forma consistente, no solo copiar archivos |
| Configuración | Servidor web, pools de PHP-FPM, php.ini, tareas cron | necesaria para una reconstrucción rápida |
| Certificados y claves | Certificados TLS, claves de la aplicación | guardar cifrados y por separado |
| Documentación | Accesos, dependencias, procedimiento de restauración | sin ella, cualquier reconstrucción tarda más |

## Ejemplo: copiar la base de datos y los archivos

El ejemplo siguiente muestra los componentes básicos de una copia diaria. En la práctica, una herramienta de copias con cifrado, deduplicación y reglas de retención se encarga de la transferencia fuera de la sede.

```bash
#!/bin/bash
set -euo pipefail
DATUM=$(date +%F)
ZIEL=/srv/backup/$DATUM
mkdir -p "$ZIEL"
chmod 700 "$ZIEL"

# Copiar la base de datos de forma consistente; credenciales de un archivo protegido, no en el comando
mysqldump --defaults-extra-file=/root/.backup-my.cnf \
  --single-transaction --routines --triggers shopdb | gzip > "$ZIEL/shopdb.sql.gz"

# Archivos de la aplicación y configuración
tar -czf "$ZIEL/webroot.tar.gz" -C /var/www shop
tar -czf "$ZIEL/config.tar.gz" /etc/nginx /etc/php /etc/cron.d

# Sumas de comprobación para un control posterior
sha256sum "$ZIEL"/* > "$ZIEL/SHA256SUMS"
```

El archivo `.backup-my.cnf` contiene las credenciales de un usuario de base de datos que solo puede leer y tiene los permisos `0600`. `--single-transaction` garantiza, en las tablas InnoDB, un estado consistente sin detener la tienda.

Después, un sistema independiente transfiere la copia fuera de la sede. Es importante que este paso se supervise: una tarea de copia que lleva días fallando en silencio solo se descubre, si no, en la emergencia. Basta un aviso diario sobre éxito, tamaño y duración, siempre que alguien lo lea y atienda las desviaciones.

Si además utiliza copias de seguridad o instantáneas de su proveedor de hosting, aclare por escrito cuánto tiempo se conservan, si puede restaurar usted mismo y si las copias se mantienen en caso de una cuenta cancelada o bloqueada. Esas copias son un buen complemento, pero no sustituyen a una copia propia e independiente.

## Retención: por qué los estados antiguos importan tras PHP2Shell

Tras un ataque, la copia más valiosa no es la más reciente, sino la más reciente que esté limpia. En PHP2Shell, según informes de los medios, el 17/10/2026 se observó un primer intento de ataque, y los parches aparecieron el 21/10/2026. Quien solo conserva siete días quizá ya no tenga un estado que sea con seguridad anterior a la posible intrusión.

Un esquema acreditado combina varios periodos, por ejemplo copias diarias durante unas semanas, semanales durante unos meses y mensuales durante un año. Los periodos exactos dependen de su necesidad de protección y de las obligaciones de supresión de la protección de datos.

También es importante: una copia de la época posterior a una intrusión puede contener webshells o archivos modificados. Tras un incidente, no restaure nunca a ciegas, sino compare los archivos con un estado limpio y revíselos antes de que el sitio web vuelva a estar en línea. Encontrará indicaciones sobre qué vigilar en [Indicios de compromiso](https://phpsos.de/es/php2shell/bin-ich-gehackt-anzeichen/). Un parche no elimina el software malicioso introducido, y una copia de seguridad tampoco lo hace por sí sola.

## Probar y documentar la restauración

Una copia sin prueba es una suposición. Solo la restauración muestra si están todas las partes, si la clave funciona y cuánto tarda realmente el proceso.

- Restaure periódicamente una copia completa en un entorno de pruebas, con la base de datos y la configuración.
- Compruebe si el sitio web funciona después por completo: inicio de sesión, pedidos, formularios, correos.
- Mida la duración y anote qué pasos fueron manuales. Compare el resultado con el tiempo máximo que su actividad puede pasar sin sitio web.
- Guarde las instrucciones de restauración donde sean accesibles incluso con el servidor caído, por ejemplo en el [plan de emergencia informático](https://phpsos.de/es/compliance/notfallplan-erstellen/).

## ¿Cómo ayuda PHP SOS en concreto?

- Revisamos sus copias de seguridad existentes en cuanto a integridad, retención, separación del servidor y protección frente al borrado.
- Configuramos una copia 3-2-1 con una copia inmutable y probamos la restauración junto con usted.
- Tras un incidente, identificamos el último estado limpio y lo restauramos en un sistema parcheado en el marco de la [eliminación de malware](https://phpsos.de/es/leistungen/malware-entfernung/).
- En el [contrato de mantenimiento de seguridad](https://phpsos.de/es/leistungen/security-wartungsvertrag/) supervisamos las copias de forma continua y realizamos pruebas de restauración periódicas.


## Preguntas frecuentes

**¿Qué significa la regla 3-2-1 en las copias de seguridad?**  
Tres copias de sus datos, en dos tipos de almacenamiento distintos, una de ellas en otro lugar. La regla hace que ni un fallo de hardware, ni un ataque ni un incendio afecten a todas las copias a la vez.

**¿Basta con la copia de seguridad de mi proveedor de hosting?**  
Es un buen complemento, pero rara vez suficiente. Aclare cuánto tiempo conserva el proveedor los estados, si puede restaurar usted mismo y si un atacante con su cuenta de cliente podría borrar las copias. Se recomienda una copia propia e independiente.

**¿Puedo simplemente restaurar la última copia tras un hackeo?**  
Solo con cuidado. La última copia ya puede contener código malicioso, y la vulnerabilidad por la que entró el atacante sigue abierta después. Primero hay que aclarar y cerrar la causa, y después restaurar un estado verificado en un sistema parcheado.

**¿Con qué frecuencia debo probar la restauración?**  
De forma periódica y tras cambios importantes en el sistema. Ha dado buen resultado un ritmo fijo, por ejemplo una restauración completa por trimestre en un entorno de pruebas. Lo importante es que la prueba se documente y se corrijan las lagunas.

## Fuentes

- [BSI IT-Grundschutz (protección básica de TI del BSI)](https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/IT-Grundschutz/it-grundschutz_node.html)
- [BSI: copias de seguridad de datos](https://www.bsi.bund.de/)
- [php.net: avisos de seguridad sobre PHP2Shell](https://www.php.net/)