Snapshot o backup en un VPS: qué protege cada uno y cómo combinarlos

La diferencia en una línea

Un snapshot responde a "¿cómo vuelvo a como estaba hace una hora?". Un backup responde a "¿cómo recupero mis datos si este servidor ya no existe?". Son preguntas distintas, y ninguno de los dos contesta la del otro.

Quién hace cada cosa en tu VPS

Un Cloud VPS de InHosting corre sobre Proxmox con redundancia. Eso cuida la infraestructura, no tus datos frente a lo que pasa adentro del servidor: no te salva de un rm equivocado, de una actualización que rompe la base ni de un intruso que cifra tus archivos.

El sistema operativo del VPS lo administrás vos, y los respaldos también. Es la lógica de cualquier servidor no administrado, y la razón para armarlos el primer día y no después del primer susto. Hay una comparación más amplia en backup incluido o backup propio.

Snapshots: antes de cada cambio que da miedo

Un snapshot vale por lo rápido que te devuelve al punto anterior. Por eso se toma justo antes de un cambio riesgoso y se borra cuando confirmás que salió bien. Guardarlo semanas no tiene sentido: ocupa espacio, y mientras existe suele agregarle trabajo a cada escritura en el disco.

• Antes de pasar de versión el sistema operativo, por ejemplo de Debian 12 a 13 o de Ubuntu 24.04 a 26.04.
• Antes de una versión mayor de la base de datos o del lenguaje: MySQL, PostgreSQL, PHP.
• Antes de tocar el firewall, la red o SSH, donde un error te deja afuera.
• Recién terminado de configurar el servidor, como punto de partida conocido.

Un snapshot dentro del propio VPS, con LVM

Si tu VPS usa LVM y el grupo de volúmenes tiene espacio libre, podés sacar un snapshot vos mismo. Guarda solo los bloques que cambian desde ese momento, así que alcanza con reservarle un tamaño modesto. Sirve para volver atrás una actualización; no sirve como respaldo, porque está en el mismo disco.

lvcreate --snapshot --size 5G --name antes-de-actualizar /dev/ubuntu-vg/ubuntu-lv
lvs
lvconvert --merge /dev/ubuntu-vg/antes-de-actualizar
lvremove /dev/ubuntu-vg/antes-de-actualizar

• lvs muestra cuánto se fue llenando el snapshot. Si llega al 100 %, queda inválido.
• Si la actualización salió mal, lvconvert --merge devuelve el volumen a ese estado; con la raíz en uso, la fusión se completa en el próximo reinicio. Si salió bien, borralo con lvremove.
• En AlmaLinux la raíz suele ser /dev/almalinux/root. Si vgs no muestra espacio en VFree, este camino no está disponible.

Backups: qué copiar

Un backup útil te deja reconstruir el servidor en otro lado, no solo recuperar la carpeta del sitio. Pensá qué te haría falta si tuvieras que empezar de cero en un VPS nuevo.

1. Un volcado de cada base de datos, hecho con la herramienta de la base. Copiar los archivos de MySQL o PostgreSQL con el servicio andando da una copia que puede no abrir.
2. Los archivos de las aplicaciones y lo que suben los usuarios (/var/www, /home, /srv, según dónde los tengas).
3. La configuración: /etc entero pesa poco y tiene casi todo, del servidor web a las tareas programadas del sistema.
4. Las claves y certificados que no se puedan volver a emitir con facilidad.
5. Las tareas programadas de cada usuario (crontab -l) y la lista de paquetes que instalaste, para reconstruir rápido: apt-mark showmanual en Debian y Ubuntu, dnf repoquery --userinstalled en AlmaLinux.

Un esquema que funciona: volcado local y copia afuera

Un ejemplo con herramientas libres de los repositorios de Debian, Ubuntu y AlmaLinux (en AlmaLinux, restic viene de EPEL). Primero se vuelca la base a una carpeta local; después restic sube esa carpeta y la configuración a un servidor de respaldo por SFTP, cifrado y con historial:

mysqldump --single-transaction --routines --triggers --all-databases | gzip > /var/backups/db/todas.sql.gz
restic -r sftp:respaldo@198.51.100.30:/srv/restic/vps1 backup /etc /var/www /var/backups/db
restic -r sftp:respaldo@198.51.100.30:/srv/restic/vps1 forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

• --single-transaction saca una copia consistente de las tablas InnoDB sin bloquear el sitio. En MariaDB el comando también se llama mariadb-dump; en PostgreSQL, usá pg_dump -Fc por base.
• restic cifra todo y guarda solo lo que cambió desde la copia anterior, así que correrlo cada noche no multiplica el espacio. La clave del repositorio va en RESTIC_PASSWORD_FILE: guardá una copia fuera del VPS, porque sin ella los respaldos no se abren.
• La tercera línea define la retención: 7 copias diarias, 4 semanales y 6 mensuales. Programalo con cron o con un temporizador de systemd, como en tareas programadas con cron y systemd.

El respaldo que un intruso no puede borrar

El ransomware que ataca servidores busca los respaldos a los que llega desde la máquina que tomó, y los borra antes de cifrar. Si tu VPS puede escribir y borrar en el servidor de respaldo, un atacante con root en el VPS también puede.

• Invertí la dirección: que el servidor de respaldo entre al VPS y se lleve la copia (modo pull), en lugar de que el VPS la empuje. Así el VPS nunca tiene credenciales para borrar respaldos.
• Si la copia la empuja el VPS, usá un destino que no permita borrar: el modo de solo agregar de borg o de rest-server para restic, o un almacenamiento de objetos con bloqueo de versiones.
• Seguí la regla 3-2-1: tres copias, en dos soportes distintos, una fuera del lugar. Para un VPS en Buenos Aires, un respaldo en otra ciudad o en otro proveedor cubre la última parte.