Copias de seguridad SSH: guía paso a paso para crearlas y restaurarlas

copias de seguridad SSH

📅 Publicado el 9 de septiembre, 2026 · Por Equipo RedServicio

Copias de seguridad SSH: guía paso a paso para crearlas y restaurarlas - RedServicio

Por qué las copias de seguridad SSH son la mejor opción para tu web

Hablaré claro: si gestionas una web con tráfico o valor comercial, los copias de seguridad SSH son lo más rápido y fiable que vas a encontrar. Lo he comprobado más de una vez. Los paneles gráficos y los plugins de backup van bien hasta que fallan, y suelen fallar justo cuando los necesitas. Trabajar por SSH es distinto: comprimes el sitio entero, exportas la base de datos y mueves archivos entre servidores con comandos directos. Sin intermediarios.

Aquí vas a ver, paso a paso, cómo generar un backup completo de archivos y base de datos, cómo restaurarlo si llega el desastre (que llega) y cómo automatizar todo para no depender de tu memoria. Porque la memoria falla. Siempre.

Requisitos previos para hacer copias de seguridad SSH

Necesitas tres cosas antes de empezar:

  • Acceso SSH activo: un usuario y contraseña (o mejor, una clave SSH) con permisos sobre tu cuenta de hosting. Si usas RedServicio, puedes activar el acceso SSH desde tu panel de control en segundos.
  • Un cliente SSH: Terminal en Linux/Mac o PuTTY/Windows Terminal en Windows (los sistemas recientes incluyen OpenSSH nativo).
  • Datos de conexión: host, puerto (habitualmente 22) y usuario.

La conexión sería así:

ssh [email protected] -p 22

Crear una copia de seguridad de archivos con SSH

Paso 1: Navegar al directorio raíz

Localiza primero la carpeta donde vive tu web, normalmente public_html o www:

cd ~/public_html

Paso 2: Comprimir el sitio con tar y gzip

tar -czvf backup-web-$(date +%Y%m%d).tar.gz .

Esto crea un comprimido cuyo nombre incluye la fecha (algo como backup-web-20250115.tar.gz). Las opciones, por si te pierdes:

  • -c: crear un archivo nuevo.
  • -z: comprimir con gzip.
  • -v: mostrar el progreso en pantalla.
  • -f: indicar el nombre del archivo resultante.
Consejo: guarda los backups fuera del directorio público (por ejemplo, en ~/backups). Si los dejas dentro, cualquiera podría descargarlos desde el navegador. Detalle pequeño, consecuencias enormes.

Paso 3: Descargar el backup a tu equipo con SCP

scp [email protected]:~/backups/backup-web-20250115.tar.gz ~/Descargas/

También está rsync, que solo transfiere los cambios entre copias. Para backups incrementales, no hay nada mejor:

rsync -avz –progress [email protected]:~/backups/ ~/Descargas/backups/

Exportar la base de datos con mysqldump

Crear el volcado SQL

Casi toda web dinámica (WordPress, PrestaShop, Joomla) depende de una base de datos MySQL o MariaDB. Se exporta así:

mysqldump -u usuario_db -p nombre_base_datos > backup-db-$(date +%Y%m%d).sql

Ojo: te pedirá la contraseña de la base de datos, no la del SSH. Es un error clásico confundirlas. Y si quieres comprimirla al vuelo:

mysqldump -u usuario_db -p nombre_base_datos | gzip > backup-db-$(date +%Y%m%d).sql.gz

Un solo comando para backup completo

¿Quieres encapsular archivos y base de datos en una sola operación? Un script pequeño te lo resuelve:

#!/bin/bash
FECHA=$(date +%Y%m%d)
mysqldump -u usuario_db -pTuPassword basedatos | gzip > ~/backups/db-$FECHA.sql.gz
tar -czf ~/backups/web-$FECHA.tar.gz ~/public_html
find ~/backups -type f -mtime +7 -delete

Recomendación de seguridad: evita escribir contraseñas en texto plano dentro de scripts. Usa un archivo ~/.my.cnf con permisos 600 para que mysqldump las lea de forma segura, o como mínimo restringe los permisos del script con chmod 700.

Restaurar una copia de seguridad mediante SSH

Restaurar archivos

Sube el comprimido al servidor (con SCP o SFTP) y descomprímelo:

tar -xzvf backup-web-20250115.tar.gz -C ~/public_html

La opción -x indica extracción y -C define el directorio de destino. En segundos, todo vuelve a su sitio. Verlo funcionar la primera vez, después de un susto, no se olvida.

Restaurar la base de datos

Si el backup está sin comprimir:

mysql -u usuario_db -p nombre_base_datos < backup-db-20250115.sql

Si viene comprimido con gzip, añades una tubería y listo:

gunzip < backup-db-20250115.sql.gz | mysql -u usuario_db -p nombre_base_datos

¿Restaurando sobre una base existente? Conviene vaciarla antes para evitar tablas duplicadas o conflictos raros:

mysql -u usuario_db -p -e «DROP DATABASE nombre_base_datos; CREATE DATABASE nombre_base_datos;»

Automatizar los backups con cron

Una buena estrategia de backup tiene una clave: que ocurra sin que tú hagas nada. Programa el script con crontab -e:

0 3 * * * /home/usuario/scripts/backup-diario.sh

Con esto el backup se ejecuta cada día a las 3:00 de la madrugada, la franja de menor tráfico. Y no olvides la regla de borrado automático (la viste en el script anterior) para no llenar el disco sin darte cuenta.

La regla 3-2-1: estrategia recomendada

  • 3 copias de tus datos (la original + 2 backups).
  • 2 soportes distintos (servidor y tu equipo local, por ejemplo).
  • 1 copia externa (almacenamiento en la nube u otro servidor).

Desde el propio script puedes enviar el comprimido a otro servidor con rsync o a un bucket de almacenamiento externo. Automático, sin que te enteres.

Preguntas frecuentes

¿Con qué frecuencia debo hacer copias de seguridad? Si tu web cambia a diario, a diario. Para sitios estáticos o con pocos cambios, una copia semanal suele bastar.

¿Cuánto deben ocupar mis backups? Un WordPress típico comprimido rara vez supera los 500 MB. Si un backup crece de forma desproporcionada, revisa carpetas de caché, logs o la papelera de la multimedia. Ahí se esconde casi siempre.

¿Es seguro dejar los backups en el servidor? Solo si están fuera del directorio público y con permisos restrictivos. Pero lo ideal, siempre, es tener al menos una copia fuera del servidor.

Conclusión: protege tu web con backups SSH automatizados

Dominar las copias de seguridad SSH te da algo que ningún plugin te da: control. Compresión eficiente, restauración en minutos, automatización total mediante cron y scripts. No esperes a sufrir un fallo de disco, un hackeo o un error humano para descubrir que no tenías backup — es de las lecciones más caras que existen. Implementa esta rutina y, sobre todo, verifica de vez en cuando que tus restauraciones funcionan. Un backup que nunca se ha probado no es un backup; es una esperanza. Y si buscas un entorno donde el acceso SSH, las copias automáticas y un soporte técnico disponible 24/7 vengan de serie, en RedServicio tienes planes de hosting pensados justo para eso: que tu única preocupación sea hacer crecer tu proyecto.

📝

Equipo RedServicio

Artículos escritos y revisados por nuestro equipo técnico especializado en hosting e infraestructura web en España.

¿Listo para un hosting de verdad?

Servidores en España · Soporte 24/7 en español · Migración gratuita

Ver Planes desde 3,95€/mes →

Te puede interesar:

ClisecSeguridad informática

Página GratisCrea tu web gratis

Scroll al inicio