Copias de seguridad y restauración en un VPS Ubuntu
Una copia de seguridad resulta útil cuando puedes recuperar los datos previstos. Este ejercicio archiva dos archivos de una web estática, los copia a otro ordenador y verifica su restauración en un directorio nuevo, sin reemplazar el sitio activo.
En esta guía
Define lo que cubre esta prueba
Trabajaremos con una página HTML y un ejemplo de configuración Nginx. No es una copia de toda la máquina: no incluye bases de datos activas, claves TLS, usuarios, paquetes ni recursos del proveedor.
Necesitas Bash, GNU tar, sha256sum y OpenSSH. En los pasos de recuperación, usa otro ordenador con herramientas compatibles, por ejemplo Linux o WSL. No ejecutes órdenes de borrado ni apagues la web para probar que existe una copia.
Prepara archivos sin modificar la web
En el VPS crea un directorio nuevo y dos archivos de muestra. Conserva esta sesión: los siguientes bloques utilizan la variable backup_lab.
umask 077
backup_lab=$(mktemp -d "$HOME/ubuntu-vps-backup.XXXXXX")
mkdir -p "$backup_lab/payload/site" "$backup_lab/payload/nginx" "$backup_lab/export"
printf '%s\n' '<!doctype html><html lang="es"><title>Prueba de restauración</title><h1>Página estática recuperada</h1></html>' > "$backup_lab/payload/site/index.html"
printf '%s\n' 'server {' ' listen 8080;' ' server_name example.test;' ' root /var/www/first-site;' '}' > "$backup_lab/payload/nginx/first-site.conf"
printf 'Directorio de práctica: %s\n' "$backup_lab"Si deseas copiar los dos archivos reales del ejemplo de despliegue, utiliza esta alternativa solo después de comprobar que existen y puedes leerlos. Sustituye las muestras dentro del directorio de práctica, no los originales:
install -m 600 /var/www/first-site/index.html "$backup_lab/payload/site/index.html"
install -m 600 /etc/nginx/sites-available/first-site "$backup_lab/payload/nginx/first-site.conf"No cambies permisos de producción para hacer funcionar el ejercicio. Un directorio creado con permisos restrictivos ayuda a proteger la copia, pero tar no la cifra. Las copias con información sensible necesitan protección adicional y control de acceso.
Crea el archivo y dos comprobaciones de integridad
En la misma sesión del VPS:
(
cd "$backup_lab/payload" &&
sha256sum site/index.html nginx/first-site.conf > SHA256SUMS
)
tar -czf "$backup_lab/export/static-site.tar.gz" -C "$backup_lab/payload" site nginx SHA256SUMS
(
cd "$backup_lab/export" &&
sha256sum static-site.tar.gz > static-site.tar.gz.sha256
)
tar -tzf "$backup_lab/export/static-site.tar.gz"
printf 'Directorio de exportación del servidor: %s\n' "$backup_lab/export"El manifiesto SHA256SUMS comprueba los dos archivos interiores. La suma del .tar.gz comprueba el archivo transferido completo. Guarda la ruta de exportación que imprime el bloque para el paso siguiente.
Una suma detecta cambios respecto al valor esperado; no acredita autenticidad si un atacante puede sustituir a la vez el archivo y su manifiesto. Utiliza un canal y un almacenamiento de confianza.
Copia los archivos a otro ordenador
En el ordenador de recuperación, abre una terminal nueva. Sustituye REPLACE por el sufijo real de la ruta que imprimió el VPS y ajusta usuario, IP y clave SSH. No escribas la ruta de ejemplo sin sustituirla.
umask 077
recovery_dir=$(mktemp -d "$HOME/ubuntu-vps-restore.XXXXXX")
remote_backup=/home/deploy/ubuntu-vps-backup.REPLACE/export
scp -i ~/.ssh/ubuntu_vps "deploy@203.0.113.10:$remote_backup/static-site.tar.gz" "$recovery_dir/"
scp -i ~/.ssh/ubuntu_vps "deploy@203.0.113.10:$remote_backup/static-site.tar.gz.sha256" "$recovery_dir/"La conexión SCP utiliza la identidad de servidor que debes haber verificado. Conserva recovery_dir en esta terminal para los pasos siguientes. Una copia guardada solo en otro directorio del mismo VPS no protege frente a la pérdida de esa máquina.
Verifica y restaura en un directorio vacío
En el ordenador de recuperación comprueba primero la suma del archivo y su listado:
(
cd "$recovery_dir" &&
sha256sum -c static-site.tar.gz.sha256
)
tar -tzf "$recovery_dir/static-site.tar.gz"Continúa solo si la comprobación indica OK y aparecen las rutas relativas esperadas: site, nginx y SHA256SUMS. No extraigas archivos desconocidos con rutas absolutas o componentes .. . Después crea otro directorio nuevo:
restore_dir=$(mktemp -d "$recovery_dir/restored.XXXXXX")
tar -xzf "$recovery_dir/static-site.tar.gz" -C "$restore_dir" --keep-old-files --no-same-owner
(
cd "$restore_dir" &&
sha256sum -c SHA256SUMS
)
cat "$restore_dir/site/index.html"Las dos comprobaciones interiores deben indicar OK. Revisa también el HTML recuperado. La opción --keep-old-files evita sobrescribir archivos existentes y --no-same-owner evita restaurar propietarios del servidor. Este ejercicio usa un archivo propio de confianza.
Distingue recuperar archivos de recuperar el servicio
La coincidencia de bytes no demuestra que toda la aplicación se haya respaldado ni que Nginx pueda servirla. Para una recuperación operativa hacen falta paquetes, rutas, permisos, DNS y certificados adecuados.
El archivo de configuración de muestra escucha en el puerto 8080 y es material de práctica; no está activado en Nginx. Para una prueba del servicio, utiliza una instancia aislada, adapta la configuración, valida nginx -t y comprueba el contenido desde un cliente. No actives el ejemplo sobre el sitio en producción.
Las bases de datos requieren un método de copia consistente con su motor. Archivar archivos mientras cambian no garantiza una base de datos restaurable.
Registra el resultado y los objetivos de recuperación
Desplaza la tabla para ver todas las columnas →
| Dato | Qué anotar |
|---|---|
| Alcance | Archivos incluidos y datos excluidos |
| Origen | Servidor, rutas y fecha de la copia |
| Destino | Ubicación externa y quién puede acceder |
| Integridad | Resultado de la suma del archivo y de los archivos interiores |
| Restauración | Directorio usado, contenido comprobado y tiempo observado |
| Objetivos | Pérdida de datos tolerable y tiempo de recuperación necesario |
RPO describe cuánta antigüedad de datos puedes aceptar; RTO, cuánto tiempo de recuperación necesitas. Un objetivo escrito no equivale a un resultado medido. Registra lo observado en tu propia prueba.
Conserva el archivo y sus manifiestos según una política de retención. Elimina una práctica solo después de identificar sus directorios exactos y confirmar que no contiene la única copia necesaria. Para diagnosticar la transferencia, revisa la guía SSH.
Preguntas y respuestas
¿Debo borrar la web para comprobar la copia?
No. Restaura primero en un directorio o entorno separado. Así verificas contenido sin interrumpir la web activa.
¿SHA256 demuestra que la copia está completa?
Comprueba los archivos incluidos frente al manifiesto. No detecta datos que olvidaste respaldar ni prueba por sí solo que toda la aplicación funcionará.