Introducción
Las copias de seguridad son muy importantes para los servidores en la nube. Ya sea que esté ejecutando un solo proyecto con todos sus datos almacenados en un solo servidor, o implementando directamente desde Git a máquinas virtuales que se crean y destruyen conservando un conjunto mínimo de registros, siempre debe planificar un escenario de falla. Esto puede significar muchas cosas diferentes dependiendo de las aplicaciones que esté utilizando, de qué tan importante sea tener una conmutación por error inmediata y qué tipo de problemas esté anticipando.
En esta guía, explorará los diferentes enfoques para proporcionar copias de seguridad y redundancia de datos. Debido a que diferentes casos de uso demandan soluciones diferentes, este artículo no podrá darle una respuesta única, pero aprenderá qué es importante en diferentes escenarios y qué implementaciones son las más adecuadas para su operación.
En la primera parte de esta guía, examinará varias soluciones de copia de seguridad y revisará los méritos relativos de cada una para que pueda elegir el enfoque que se adapte a su entorno. En la segunda parte, explorará opciones de redundancia.
Parte 1 — ¿Cuál es la diferencia entre redundancia y copia de seguridad?
Las definiciones de los términos redundante y respaldo a menudo se superponen y, en muchos casos, se confunden. Estos son dos conceptos distintos que están relacionados, pero son diferentes. Algunas soluciones proporcionan ambos.
Redundancia
La redundancia en los datos significa que hay un conmutador automático inmediato en caso de un problema del sistema. Un conmutador automático significa que si un conjunto de datos (o un host) se vuelve no disponible, otra copia perfecta se intercambia inmediatamente en producción para ocupar su lugar. Esto resulta en casi ningún tiempo de inactividad perceptible, y la aplicación o el sitio web pueden continuar sirviendo solicitudes como si nada hubiera ocurrido. Mientras tanto, el administrador del sistema (en este caso, tú) tiene la oportunidad de solucionar el problema y devolver el sistema a un estado completamente operativo.
Sin embargo, una solución de redundancia generalmente no es también una solución de respaldo. El almacenamiento redundante no necesariamente proporciona protección contra un fallo que afecta a toda la máquina o sistema. Por ejemplo, si tiene configurado un RAID espejado (como RAID 1), sus datos son redundantes en el sentido de que si un disco falla, el otro seguirá estando disponible. Sin embargo, si la máquina misma falla, todos sus datos podrían perderse.
Con soluciones de redundancia como MySQL Group Replication, cada operación se realiza típicamente en cada copia de los datos. Esto incluye operaciones maliciosas o accidentales. Por definición, una solución de respaldo también debería permitirle restaurar desde un punto anterior donde se sabe que los datos están en buen estado.
Respaldo
En general, es necesario mantener respaldos funcionales de sus datos importantes. Dependiendo de su situación, esto podría significar respaldar datos de aplicaciones o usuarios, o un sitio web completo o una máquina entera. La idea detrás de los respaldos es que en caso de pérdida de sistema, máquina o datos, pueda restaurar, volver a implementar o acceder de otra manera a sus datos. Restaurar desde un respaldo puede requerir tiempo de inactividad, pero puede significar la diferencia entre comenzar desde hace un día y comenzar desde cero. Todo lo que no pueda permitirse perder debería, por definición, respaldarse.
En términos de métodos, hay bastantes niveles diferentes de respaldos. Estos pueden estar estratificados según sea necesario para dar cuenta de diferentes tipos de problemas. Por ejemplo, puede respaldar un archivo de configuración antes de modificarlo para poder revertir a su configuración anterior si surge algún problema. Esto es ideal para cambios pequeños que está monitoreando activamente. Sin embargo, esta configuración fallaría en caso de falla de disco o cualquier cosa más compleja. También debería tener respaldos regulares y automáticos en una ubicación remota.
Las copias de seguridad por sí solas no proporcionan conmutación por error automática. Esto significa que sus fallos pueden no costarle ningún dato (asumiendo que sus copias de seguridad están actualizadas al 100%), pero pueden costarle tiempo de actividad. Esta es una de las razones por las cuales la redundancia y las copias de seguridad a menudo se utilizan en combinación entre sí.
Parte 2 — Copia de seguridad a nivel de archivo
Una de las formas más familiares de hacer copias de seguridad es la copia de seguridad a nivel de archivo. Este tipo de copia de seguridad utiliza herramientas normales de copia a nivel de sistema de archivos para transferir archivos a otra ubicación o dispositivo.
Cómo usar el comando cp
En teoría, podrías hacer una copia de seguridad de una máquina Linux, como tu servidor en la nube, con el comando cp. Esto copia archivos de una ubicación local a otra. En una computadora local, podrías montar una unidad extraíble y luego copiar archivos en ella:
Este ejemplo monta un disco extraíble, sdc, como /mnt/my-backup y luego copia el directorio /etc en el disco. Luego desmonta la unidad, que se puede almacenar en otro lugar.
Cómo usar Rsync
A better alternative to cp is the rsync command. Rsync is a powerful tool that provides a wide array of options for replicating files and directories across many different environments, with built-in checksum validation and other features. Rsync can perform the equivalent of the cp operation above like so:
-azvP es un conjunto típico de opciones de Rsync. Desglosando lo que hace cada una de ellas:
aenables “Archive Mode” for this copy operation, which preserves file modification times, owners, and so on. It is also the equivalent of providing each of the-rlptgoDoptions individually (yes, really). Notably, the-roption tells Rsync to recurse into subdirectories to copy nested files and folders as well. This option is common to many other copy operations, such ascpandscp.zcompresses data during the transfer itself, if possible. This is useful for any transfers over slow connections, especially when transferring data that compresses very effectively, like logs and other text.venables verbose mode, so you can read more details of your transfer while it is in progress.Ptells Rsync to retain partial copies of any files that do not transfer completely, so that transfers can be resumed later.
Puedes revisar otras opciones de rsync en su página de manual.
Por supuesto, en un entorno de nube, normalmente no montarías y copiarías archivos en un disco montado cada vez. Rsync también puede realizar copias de seguridad remotas a través de una red proporcionando una sintaxis estilo SSH. Esto funcionará en cualquier host al que puedas conectarte por SSH, siempre que Rsync esté instalado en ambos extremos. Dado que Rsync se considera una herramienta principal de Linux, esta es casi siempre una suposición segura, incluso si estás trabajando localmente en una máquina Mac o Windows.
Esto respaldará el directorio /etc de la máquina local en un directorio en remote_host ubicado en /backup. Esto tendrá éxito si tienes permiso para escribir en este directorio y hay espacio disponible.
También puedes revisar más información sobre cómo usar Rsync para sincronizar directorios locales y remotos.
Cómo usar otras herramientas de respaldo
Aunque cp y rsync son útiles y ubicuos, no son una solución completa por sí solos. Para automatizar copias de seguridad usando Rsync, necesitarías crear tus propios procedimientos automatizados, programación de respaldo, rotación de registros, y así sucesivamente. Si bien esto puede ser apropiado para algunos despliegues muy pequeños que no desean hacer uso de servicios externos, o despliegues muy grandes que tienen recursos dedicados para mantener scripts muy granulares para varios propósitos, muchos usuarios pueden querer invertir en una oferta de respaldo dedicada.
Bacula
Bacula es una solución compleja y flexible que funciona en un modelo cliente-servidor. Bacula está diseñado con conceptos separados de clientes, ubicaciones de respaldo y directores (el componente que orquesta el respaldo real). También configura cada tarea de respaldo en una unidad llamada “trabajo”.
Esto permite una configuración extremadamente granular y flexible. Puedes respaldar múltiples clientes en un dispositivo de almacenamiento, un cliente en múltiples dispositivos de almacenamiento, y modificar el esquema de respaldo agregando nodos o ajustando sus detalles. Funciona bien en un entorno de red y es ampliable y modular, lo que lo hace ideal para respaldar un sitio o aplicación distribuida en varios servidores.
Duplicity
Duplicity es otra herramienta de respaldo de código abierto. Utiliza encriptación GPG por defecto para las transferencias.
El beneficio obvio de utilizar el cifrado GPG para las copias de seguridad de archivos es que los datos no se almacenan en texto plano. Solo el propietario de la clave GPG puede descifrar los datos. Esto proporciona un nivel de seguridad para compensar las medidas de seguridad adicionales requeridas cuando sus datos se almacenan en múltiples ubicaciones.
Otro beneficio que puede que no sea evidente para aquellos que no utilizan GPG regularmente es que cada transacción debe ser verificada para ser completamente precisa. GPG, al igual que Rsync, aplica verificación de hash para asegurar que no hubo pérdida de datos durante la transferencia. Esto significa que al restaurar datos desde una copia de seguridad, es significativamente menos probable que encuentres corrupción de archivos.
Parte 3 — Copias de seguridad a nivel de bloque
A slightly less common, but important alternative to file-level backups are block-level backups. This style of backup is also known as “imaging” because it can be used to duplicate and restore entire devices. Block-level backups allow you to copy on a deeper level than a file. While a file-based backup might copy file1, file2, and file3 to a backup location, a block-based backup system would copy the entire “block” that those files reside on. Another way of explaining the same concept is to say that block-level backups copy information bit after bit. They do not know about the files that may span those bits.
Una ventaja de las copias de seguridad a nivel de bloque es que suelen ser más rápidas. Mientras que las copias de seguridad basadas en archivos suelen iniciar una nueva transferencia para cada archivo separado, una copia de seguridad basada en bloques transferirá bloques, lo que significa que se necesitarán menos transferencias no secuenciales para completar la copia.
Usar dd para realizar copias de seguridad a nivel de bloque
El método más común para realizar copias de seguridad a nivel de bloque es mediante la utilidad dd. dd se puede utilizar para crear imágenes de disco completas, y también se utiliza con frecuencia al archivar medios extraíbles como CDs o DVDs. Esto significa que puedes hacer una copia de seguridad de una partición o disco en un solo archivo o dispositivo bruto sin ningún paso preliminar.
Para usar dd, necesitas especificar una ubicación de entrada y una ubicación de salida, de la siguiente manera:
En este escenario, el argumento if= especifica el dispositivo o ubicación de entrada. El argumento of= especifica el archivo o ubicación de salida. Ten cuidado de no confundirlos, o podrías borrar todo un disco por error.
Por ejemplo, para hacer una copia de seguridad de una partición que contiene tus documentos, que está ubicada en /dev/sda3, puedes crear una imagen de ese directorio proporcionando una ruta de salida a un archivo .img:
Parte 4 — Versionado de Copias de Seguridad
Una de las principales motivaciones para hacer copias de seguridad de datos es poder restaurar una versión anterior de un archivo en caso de un cambio o eliminación no deseada. Aunque todos los mecanismos de copia de seguridad mencionados hasta ahora pueden ofrecer esto, también puedes implementar una solución más granular.
Por ejemplo, una forma manual de lograr esto sería hacer una copia de seguridad de un archivo antes de editarlo en nano:
Podrías incluso automatizar este proceso creando archivos ocultos con marcas de tiempo cada vez que modifiques un archivo con tu editor. Por ejemplo, podrías colocar esto en tu archivo ~/.bashrc, de modo que cada vez que ejecutes nano desde tu shell bash (es decir, $), automáticamente se cree una copia de seguridad marcada con el año (%y), mes (%m), día (%d), y así sucesivamente:
Esto funcionaría hasta cierto punto si editas archivos manualmente con nano, pero está limitado en alcance y podría llenar rápidamente un disco. Puedes ver cómo podría ser peor que copiar manualmente archivos que vas a editar.
Una alternativa que soluciona muchos de los problemas inherentes en este diseño es usar Git como sistema de control de versiones. Aunque fue desarrollado principalmente para enfocarse en versionar texto plano, generalmente código fuente, línea por línea, puedes usar Git para rastrear casi cualquier tipo de archivo. Para obtener más información, puedes revisar Cómo utilizar Git eficazmente.
Parte 5 — Copias de seguridad a nivel de servidor
La mayoría de los proveedores de alojamiento también ofrecerán su propia funcionalidad de copia de seguridad opcional. La función de copia de seguridad de DigitalOcean realiza regularmente copias de seguridad automatizadas para los droplets que han habilitado este servicio. Puedes activarlo durante la creación del droplet marcando la casilla de verificación “Copias de seguridad”:
Esto respaldará la imagen completa de tu servidor en la nube de manera regular. Esto significa que puedes volver a implementar desde la copia de seguridad o usarla como base para nuevos droplets.
Para la creación puntual de imágenes de tu sistema, también puedes crear instantáneas. Estas funcionan de manera similar a los respaldos, pero no son automáticas. Aunque es posible tomar una instantánea de un sistema en ejecución en algunos contextos, no siempre se recomienda, dependiendo de cómo estés escribiendo en tu sistema de archivos:
Puedes obtener más información sobre los respaldos y las instantáneas de DigitalOcean en la documentación de Contenedores e Imágenes.
GitOps
Finalmente, vale la pena señalar que hay algunas circunstancias en las que no necesariamente estarás buscando implementar copias de seguridad a nivel de servidor. Por ejemplo, si tu implementación sigue los principios de GitOps, es posible que trates muchos de tus servidores individuales en la nube como desechables, y en su lugar consideres las fuentes de datos remotas como los repositorios Git como la fuente efectiva de verdad para tus datos. Implementaciones complejas y modernas como esta pueden ser más escalables y menos propensas a fallas en muchos casos. Sin embargo, aún querrás implementar una estrategia de respaldo para tus almacenes de datos mismos, o para un servidor de registro centralizado al que cada uno de estos servidores desechables pueda estar enviando información. Considera qué aspectos de tu implementación pueden no necesitar ser respaldados y cuáles sí.
Conclusión
En este artículo, exploraste varios conceptos y soluciones de respaldo. A continuación, es posible que desees revisar soluciones para habilitar la redundancia.