Copia de seguridad y recuperación ante desastres para servidores dedicados Actualizado el 3 de marzo de 2026. por Sam Page 5 minutos y 45 segundos de lectura La diferencia entre un desastre y un incidente es si tus copias de seguridad funcionan. La mayoría de los operadores de servidores descubren en qué categoría se encuentran en el peor momento posible: durante un ataque de ransomware activo, una migración fallida o un fallo del disco un viernes por la tarde. Una estrategia de copia de seguridad para servidores dedicados requiere más que un cron nocturno... Índice Define los objetivos de tiempo de recuperación (RTO) y de punto de recuperación (RPO) antes de elegir herramientas de copia de seguridad. La regla 3-2-1 aplicada a los servidores dedicados Herramientas de copia de seguridad para servidores dedicados Linux Restic Duplicati Rsync para copias incrementales Copia de seguridad específica de la base de datos cPanel Backup Manager Pruebas de restauración Automatización de la verificación de copias de seguridad Planificación de recuperación ante desastres más allá de las copias de seguridad Define los objetivos de tiempo de recuperación (RTO) y de punto de recuperación (RPO) antes de elegir herramientas de copia de seguridad. El objetivo de tiempo de recuperación (RTO) es el tiempo que tu aplicación puede permanecer fuera de línea antes de que el impacto en el negocio sea inaceptable. Una aplicación SaaS con clientes empresariales puede tener un RTO de 30 minutos. Un sitio web de marketing puede tolerar 4 horas. El objetivo de punto de recuperación (RPO) es la cantidad de pérdida de datos que se considera aceptable. Una tienda de comercio electrónico que recibe 500 pedidos por hora no puede permitirse perder 24 horas de datos, ya que cada pedido perdido supone una pérdida de ingresos y un problema de atención al cliente. Esa misma tienda podría realizar copias de seguridad cada 15 minutos. Un servidor de desarrollo podría realizar copias de seguridad semanales con un RPO de 7 días. Documenta ambos números antes de seleccionar la frecuencia de las copias de seguridad, la retención y las herramientas. Tu arquitectura de copias de seguridad debe diseñarse para cumplir los requisitos definidos, no heredarse de lo que se haya configurado en el aprovisionamiento. La regla 3-2-1 aplicada a los servidores dedicados La regla 3-2-1 es el marco fundamental para la estrategia de respaldo de la producción: 3 copias de los datos 2 tipos diferentes de soportes de almacenamiento 1 copia almacenada fuera de las instalaciones (separada geográficamente del servidor principal) Aplicado a un servidor dedicado, normalmente tiene el siguiente aspecto: Datos primarios: el propio servidor de producción en vivo. Copia de seguridad local: una copia de seguridad en el servidor en un disco o partición independiente (distinto del disco del sistema operativo o de las aplicaciones). Copia de seguridad externa: una copia enviada al almacenamiento de objetos (compatible con S3), un servidor secundario dedicado o el almacenamiento de copias de seguridad de InMotion. Una única copia de seguridad almacenada en el mismo servidor que los datos no es una estrategia de copia de seguridad. El ransomware cifra el almacenamiento conectado. Los fallos del disco eliminan todo lo que hay en el mismo controlador. Una copia de seguridad local sin una copia externa falla ambas pruebas. El paquete Premier Care de InMotion incluye 500 GB de almacenamiento de copia de seguridad para clientes de servidores dedicados, lo que proporciona el componente de copia externa sin necesidad de cuentas de almacenamiento en la nube independientes. Herramientas de copia de seguridad para servidores dedicados Linux Restic Restic es una herramienta de copia de seguridad moderna, rápida y cifrada que admite S3, Backblaze B2, SFTP y almacenamiento local como destinos de copia de seguridad. Su deduplicación y cifrado están integrados, y el formato del repositorio es compatible con futuras versiones de restic. Configuración básica de copia de seguridad para un servidor web: # Initialize a repository on S3-compatible storage restic -r s3:https://s3.amazonaws.com/your-bucket/server-backups init # Set credentials via environment variables export AWS_ACCESS_KEY_ID="your_key" export AWS_SECRET_ACCESS_KEY="your_secret" # Backup web root and database dumps restic -r s3:https://s3.amazonaws.com/your-bucket/server-backups \ backup /var/www /etc /home \ --exclude /var/www/html/cache \ --exclude /var/www/html/tmp # Apply retention policy (keep 7 daily, 4 weekly, 6 monthly) restic -r s3:https://s3.amazonaws.com/your-bucket/server-backups \ forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune Ejecuta mediante cron cada hora o cada noche, dependiendo de tu RPO. Duplicati Duplicati proporciona una interfaz de gestión basada en web, lo que lo hace accesible para los operadores de servidores que prefieren no gestionar las tareas de copia de seguridad íntegramente a través de la línea de comandos. Admite cifrado, compresión y múltiples destinos de almacenamiento backend. Para los servidores cPanel, Duplicati puede ejecutarse como un servicio del sistema que realiza copias de seguridad de directorios específicos. Rsync para copias incrementales rsync con –link-dest crea copias de seguridad incrementales eficientes en las que los archivos que no han cambiado se vinculan de forma rígida a la instantánea de la copia de seguridad anterior en lugar de duplicarse. Esto proporciona múltiples instantáneas puntuales con un coste de almacenamiento proporcional a los datos que han cambiado: #!/bin/bash BACKUP_DIR="/backup/web" DATE=$(date +%Y-%m-%d_%H-%M) LATEST="$BACKUP_DIR/latest" rsync -avz --link-dest="$LATEST" /var/www/ "$BACKUP_DIR/$DATE/" # Update the symlink to latest backup rm -f "$LATEST" ln -s "$BACKUP_DIR/$DATE" "$LATEST" Copia de seguridad específica de la base de datos Las copias de seguridad del sistema de archivos de las bases de datos MySQL en ejecución capturan estados inconsistentes: los archivos de la base de datos en el disco pueden estar en medio de una transacción cuando se ejecuta la copia de seguridad. Las copias de seguridad de la base de datos deben utilizar herramientas nativas de la base de datos: MySQL/MariaDB: # Full logical backup mysqldump --all-databases --single-transaction --routines --triggers \ -u root -p > /backup/mysql_$(date +%Y%m%d).sql # Compress to reduce storage gzip /backup/mysql_$(date +%Y%m%d).sql Para bases de datos más grandes en las que mysqldump tarda demasiado, Percona XtraBackup proporciona copias de seguridad físicas en caliente que capturan un estado coherente sin bloquear las tablas y se restauran mucho más rápido que los archivos de volcado lógico. La documentación de Percona XtraBackup cubre la instalación y el uso. PostgreSQL: pg_dumpall -U postgres | gzip > /backup/postgres_$(date +%Y%m%d).sql.gz cPanel Backup Manager Si tu servidor dedicado ejecuta cPanel, el Backup Manager integrado Backup Manager las copias de seguridad a nivel de cuenta, incluidos archivos, bases de datos, correo electrónico y configuración, en una sola operación. Configúralo en WHM en Copia de seguridad > Configuración de copia de seguridad. Ajustes clave que debes revisar: Tipo de copia de seguridad: Completa e incremental (no solo completa: las copias incrementales entre copias completas reducen el RPO sin un coste de almacenamiento proporcional). Destino remoto: configura un destino remoto compatible con SFTP o S3 para la copia externa. Retención: Adáptate a tu RPO documentado y a tu presupuesto de almacenamiento. Backup Manager de InMotion proporciona 500 GB adicionales de almacenamiento de copias de seguridad accesibles directamente desde cPanel, sin necesidad de configuración adicional del servidor. Pruebas de restauración Una copia de seguridad que nunca se ha probado es una hipótesis, no una protección. Las pruebas deben abarcar tres escenarios: Restauración a nivel de archivo: restaura un directorio específico desde la copia de seguridad y comprueba que el contenido coincide con lo que se copió. Hazlo mensualmente. Restauración de la base de datos: restaura la copia de seguridad más reciente de la base de datos en un servidor provisional y comprueba el funcionamiento de la aplicación. De este modo, se detectan los daños en el archivo de copia de seguridad antes de que sea necesario utilizarlo en producción. Realiza esta operación mensualmente. Simulación de restauración completa del servidor: aprovisiona un nuevo servidor, restaura todo desde la copia de seguridad y comprueba que la aplicación funciona correctamente. Esta prueba revela si tu documentación, la configuración de la copia de seguridad y los procedimientos de restauración funcionan realmente de principio a fin. Realízala trimestralmente. Documenta el procedimiento de restauración de forma explícita, incluyendo los comandos, los tiempos y los pasos de verificación. Es posible que la persona que realice la restauración durante un incidente no sea la misma que haya escrito la configuración de la copia de seguridad. Automatización de la verificación de copias de seguridad Restic proporciona una comprobación de integridad integrada que verifica la coherencia del repositorio de copias de seguridad sin necesidad de realizar una restauración completa: restic -r s3:https://s3.amazonaws.com/your-bucket/server-backups check Run this weekly via cron and alert on non-zero exit codes. A corrupted backup that's never checked is indistinguishable from a good backup until you need it. For file-level verification, add a checksum comparison step to your backup process: # Store a checksum of the source directory find /var/www -type f -exec md5sum {} \; | sort > /backup/checksums_$(date +%Y%m%d).txt # Compare after restore md5sum -c /backup/checksums_20260227.txt Planificación de recuperación ante desastres más allá de las copias de seguridad Las copias de seguridad restauran los datos. Un plan de recuperación ante desastres se ocupa de todo lo demás: Conmutación por error de DNS: si tu servidor está inactivo, ¿puedes redirigir el tráfico a un sustituto temporal? El DNS proxy Cloudflarehace que la conmutación por error a nivel de IP sea tan sencillo como cambiar un registro A. Configuración del servidor documentada: tu copia de seguridad contiene tus datos, pero no tu Nginx , las reglas del cortafuegos, la configuración del grupo PHP-FPM ni las dependencias de la aplicación. Documenta o automatiza la configuración del servidor para que se pueda aprovisionar un nuevo servidor que coincida con el anterior. Plan de comunicación: ¿A quién se notifica cuando el servidor deja de funcionar? ¿En qué orden? ¿Quién tiene autoridad para desconectar el servidor para realizar tareas de mantenimiento durante una recuperación? InMotion HostingPremier Care InMotion Hostingincluye acceso a InMotion Solutions, el equipo de consultoría que ayuda en situaciones complejas de recuperación de servidores. La hora mensual de tiempo de Solutions se aprovecha al máximo para probar los procedimientos de recuperación ante desastres y documentar los manuales de recuperación antes de que sean necesarios. Comparte este artículo Artículos relacionados Los servidores ecológicos InMotion Hosting: ¿qué ofrece realmente el hardware empresarial reacondicionado? RAM DDR4 vs DDR5: Una comparación en profundidad AMD EPYC frente a Intel Xeon: lo que los compradores de alojamiento web realmente necesitan saber Alojamiento en servidor dedicado para Moodle: por qué los recursos compartidos merman el rendimiento del LMS Guía de decisión para agencias que evalúan la infraestructura de alojamiento Servidores dedicados bare metal: qué son y cómo evaluar a los proveedores Cómo elegir un plan de servidor dedicado: un marco basado en la carga de trabajo ¿Qué es IPMI y por qué es importante para la gestión de servidores dedicados? Procesamiento de datos de alta frecuencia en servidores dedicados Análisis del coste total de propiedad: propiedad de un servidor dedicado durante 3 años frente a 5 años