Un plan de copias de seguridad para su servidor

Módulo 8: Copias de seguridad y monitorización · Tiempo de lectura: 11 minutos

Objetivo de aprendizaje: Después de esta lección, podrá crear un plan de copias de seguridad para su propio servidor: qué guarda, dónde, con qué frecuencia y durante cuánto tiempo, y cómo se asegura de que la restauración funciona.

Conceptos clave: regla 3-2-1, snapshot, copia de seguridad del proveedor, copia de seguridad propia fuera del proveedor, RPO, RTO, volcado de base de datos (mariadb-dump, pg_dump), configuración en /etc, volúmenes de Docker, cifrado, ransomware, append-only, prueba de restauración

¿Por qué un plan, y no simplemente "ya hay una copia de seguridad"?

Casi todas las personas que han perdido un servidor creían que tenían una copia de seguridad. Luego resulta que solo contenía el sistema operativo y no la base de datos, o que estaba en el mismo servidor que ya no existe, o que el mismo ransomware la ha cifrado, o que nadie conoce la contraseña. Una copia de seguridad solo tiene valor si puede restaurarla. Por eso se empieza con un plan y se termina con una prueba.

Un plan responde a cinco preguntas:

1. ¿Qué debe poder restaurarse?
2. ¿Cuántos datos puede permitirse perder? (RPO)
3. ¿Con qué rapidez debe volver a funcionar? (RTO)
4. ¿Dónde están las copias, y cuántas hay?
5. ¿Cómo sabe que funciona?

¿Qué debe poder restaurarse?

Un servidor se compone de capas. No todas tienen que estar en la copia de seguridad:

Preste especial atención a las bases de datos. Una base de datos en funcionamiento escribe continuamente. Si copia los archivos de un MariaDB o PostgreSQL en marcha, puede obtener una copia dañada. Por eso, haga primero un volcado (dump): una instantánea coherente en forma de archivo, que después incluye en la copia de seguridad.

root@web1:~# mariadb-dump --single-transaction --all-databases | gzip > /var/backups/db/alles-$(date +%F).sql.gz
root@web1:~# sudo -u postgres pg_dumpall | gzip > /var/backups/db/pg-$(date +%F).sql.gz

(mariadb-dump se llamaba antes mysqldump; ese comando normalmente sigue funcionando.) Si la base de datos se ejecuta en un contenedor, haga lo mismo con docker compose exec (lección 9.4).

RPO y RTO: ¿cuánto puede perder?

Dos conceptos de la práctica profesional le ayudan a tomar decisiones:

• RPO (recovery point objective): ¿cuánto tiempo de datos puede perder como máximo? Una copia de seguridad diaria a las 03:00 significa que, si el servidor falla a las 22:00, pierde casi un día. Para una tienda online con pedidos es demasiado; para un blog que cambia una vez por semana está bien.
• RTO (recovery time objective): ¿cuánto tiempo puede pasar hasta que todo vuelva a funcionar? Restaurar una copia de seguridad completa del proveedor puede hacerse en minutos; montar un servidor nuevo y restaurarlo todo a mano puede llevar horas.

Anótelos para su propio servidor. Determinan con qué frecuencia hace una copia de seguridad y cómo la conserva.

Snapshot, copia de seguridad del proveedor, copia de seguridad propia

En un VPS suele tener tres tipos de red de seguridad. Se parecen, pero protegen contra cosas distintas.

1. El snapshot. Una instantánea de todo el disco virtual, creada en el panel de su proveedor. Rápido de crear y rápido de restaurar. Ideal justo antes de una actualización de versión (lección 4.3). Pero en la mayoría de los proveedores un snapshot está en el mismo almacenamiento que su servidor. Si ese almacenamiento se estropea, o pierde su cuenta, el snapshot también desaparece. Y un snapshot no se conserva mucho tiempo: crece con todos los cambios posteriores. Un snapshot no es una copia de seguridad.

2. La copia de seguridad del proveedor. Muchos proveedores hacen (a veces como opción) una copia automática diaria de todo su servidor, en otro almacenamiento. En WebOké, por ejemplo, es una copia de seguridad diaria de todo el VPS que se conserva siete días; en otros proveedores funciona de forma parecida, con sus propios plazos. Es una buena segunda capa contra el hardware averiado y contra sus propios errores de ayer. Pero sigue siendo una sola empresa: su cuenta, su pago, sus incidencias. Y la restauración suele hacerse para todo el servidor a la vez.

3. Su propia copia de seguridad, fuera del proveedor. Una copia de sus datos en otra empresa o en otro lugar, que usted crea y gestiona (lección 8.2). Esta es la capa que queda cuando todo lo demás falla.

La regla 3-2-1

Una regla práctica habitual:

• 3 copias de sus datos (el original más dos copias de seguridad);
• en 2 tipos distintos de almacenamiento o sistemas;
• de las cuales 1 está en otra ubicación.

Para un VPS puede ser: los datos en el servidor, la copia de seguridad diaria del proveedor y una copia de seguridad propia cifrada con restic en un almacenamiento de otra empresa. Un complemento moderno es que al menos una copia no pueda borrarla quien tome el control del servidor (offline o append-only, lección 8.2). El ransomware en un servidor busca activamente copias de seguridad para cifrarlas o borrarlas también. Una copia de seguridad que el propio servidor puede borrar no ofrece protección contra eso.

El cifrado y la contraseña de su copia de seguridad

Una copia de seguridad en otra empresa debe estar cifrada: contiene datos de clientes, contraseñas y claves. restic (lección 8.2) cifra por defecto. Pero así surge un nuevo riesgo: la contraseña de su copia de seguridad. Si la pierde, la copia de seguridad es inutilizable. Y si solo está guardada en el servidor que ha perdido, también.

Por eso, guarde la contraseña también fuera del servidor: en su gestor de contraseñas y, si lo desea, en papel dentro de una caja fuerte. Lo mismo se aplica a los datos de acceso del almacenamiento donde está su copia de seguridad.

Probar la restauración

La parte más importante del plan. Una prueba de restauración significa que restaura de verdad una copia de seguridad, en un lugar donde no estropee nada, y comprueba si el resultado funciona.

• Pequeña y frecuente: restaurar un archivo o una carpeta en /tmp/terug y compararlos (diff). Por ejemplo, cada mes.
• Grande y ocasional: montar un servidor de pruebas completo a partir de la copia de seguridad, importar la base de datos e iniciar el sitio web. Por ejemplo, una vez al año, o con cada cambio importante. Así también practica para cuando algo falle de verdad (lección 10.3).

Anote cuánto tiempo ha tardado: ese es su RTO real.

Plazos de conservación

No conserve solo la última copia de seguridad. Si descubre después de dos semanas que un archivo está dañado o se ha borrado, necesita una copia de seguridad de hace tres semanas. Un esquema habitual: siete versiones diarias, cuatro semanales y seis mensuales. restic lo gestiona con forget (lección 8.2). Tenga en cuenta también el RGPD: los datos personales no se conservan más tiempo del necesario, tampoco en las copias de seguridad. Deje constancia de sus plazos de conservación.

En la práctica

Use el snapshot de su proveedor justo antes de cambios arriesgados y elimínelo después; mantenga activada la copia de seguridad diaria del proveedor si existe; y, además, haga su propia copia de seguridad cifrada de los datos y la configuración en otra empresa. En WebOké esto se encuentra en la pantalla del VPS como Snapshots y Backups; en otros proveedores los nombres y los plazos son distintos, pero el principio es el mismo. Un paquete de hosting o un servicio gestionado suele tener otros acuerdos: compruebe qué está previsto en su caso.

Resumen

• Una copia de seguridad solo tiene valor si la restauración funciona; empiece con un plan y termine con una prueba.
• Haga copia de seguridad sobre todo de los datos y la configuración: bases de datos como volcado, /etc, sitios web, volúmenes de Docker, archivos compose.
• Determine el RPO (cuánto puede perder) y el RTO (con qué rapidez debe funcionar).
• El snapshot (mismo almacenamiento, corto plazo), la copia de seguridad del proveedor (otro almacenamiento, misma empresa) y una copia propia fuera del proveedor son tres capas distintas; siga la regla 3-2-1 con al menos una copia que el propio servidor no pueda borrar.
• Cifre, guarde la contraseña de la copia de seguridad fuera del servidor y pruebe la restauración: a pequeña escala con frecuencia, a gran escala de vez en cuando.

Cuestionario

Ejercicio

Ejercicio O8.1: Su plan de copias de seguridad. Elabore para su propio servidor un plan de copias de seguridad en una sola página: qué debe poder restaurarse (por capa), su RPO y RTO, qué copias tiene (snapshot, proveedor, propia) y dónde, sus plazos de conservación, dónde está la contraseña de la copia de seguridad y cuándo hace una prueba de restauración. Rellene el formulario; después de enviarlo verá un plan de ejemplo para compararlo con el suyo.

Para saber más

• Snapshots y copias de seguridad de su VPS
• Estrategia de copias de seguridad: la regla 3-2-1 para su propia empresa
• ¿Cómo hago una copia de seguridad de mi base de datos MySQL?
• En el curso Seguridad en internet: las lecciones sobre la regla 3-2-1 y las copias de seguridad que sobreviven al ransomware.
• MariaDB, mariadb-dump: https://mariadb.com/docs/server/clients-and-utilities/backup-restore-and-import-clients/mariadb-dump
• PostgreSQL, Backup and Restore (SQL Dump): https://www.postgresql.org/docs/current/backup-dump.html