¿Cómo hacer una copia de seguridad de un servidor Linode en ejecución?


21

Queremos hacer una copia de seguridad de todo en nuestro servidor Debian, que se ejecuta de forma remota en el otro lado del mundo (alojado por Linode), sin apagarlo.

Este sistema ejecuta shell, correo electrónico, XMPP / prosody y web, con un par de configuraciones simples de nginx.
Queremos hacer una copia de seguridad de los archivos relacionados con esas cosas solo para estar seguros. Por ejemplo, los archivos que los usuarios han almacenado en sus directorios de inicio.

No necesitamos copiar exactamente la configuración existente wrt cada archivo / etc; en cambio, la razón por la que incluso estamos haciendo la copia de seguridad en primer lugar es para que podamos moverlo todo a una nueva configuración (la versión más nueva de Debian todavía está en Linode).

Veo que Linode ofrece un servicio de respaldo. Pero a largo plazo también necesitamos copias de seguridad propias, aquí, en caso de que desaparezcan o suceda algo extraño.

La razón por la que esta pregunta existe es que cuando intenté hacer copias de seguridad en el pasado, seguí cometiendo cualquiera de estos dos errores:

  • Dije "OK, solo copiaré /y todo lo que está debajo" y luego me quedé atrapado en un extraño bucle infinito, ya sea porque la unidad a la que estaba copiando estaba montada en / media / backup y se copiaba recursivamente [obv ese problema específico no se aplica aquí ya que vamos a hacer una copia de seguridad a través de rsync o similar] o se ha quedado atascado tratando de copiar algunas cosas "vivas" en / proc o / var o lo que sea, como tratar de mantenerse al día con los registros siempre cambiantes, o
  • Dije "OK, solo tomaré el mínimo de lo que necesitamos ... hmm, los directorios de inicio de todos, y los directorios de nuestro servidor web (todo debajo /var) y vamos a enganchar una copia /etcy todos los correos antiguos en / var / vmail "y luego invariablemente jodí los permisos de archivo o las marcas de tiempo (me aseguraré de no hacer una copia de seguridad de archivos Unix en una unidad FAT esta vez) u olvidé algo (" oh, dispara, tenía algunos scripts personalizados en / usr / local / bin que nunca almacené en ningún otro lugar, olvidé obtenerlos, supongo que ya no están ").

Por lo tanto, la copia obv de toda la unidad directamente hacia arriba ha llevado a dificultades y la copia selectiva de directorios ha llevado a dificultades. Quiero saber cómo hacerlo bien.

La pregunta de error del servidor ¿ Qué se necesita para un sistema de copia de seguridad completo? cubre filosofía y buenas prácticas, pero estoy buscando estos detalles más específicos de:

  • ¿Qué directorios necesito copiar y cuáles excluyo?
  • ¿Qué atributos de archivo, como marcas de tiempo, propietario y grupo, debo presentar y cómo lo hago? ← Creo que puedo responder esta mitad de la pregunta yo mismo con algo como ... um ... rsync -HXaz¿Creo que es una buena opción para nosotros? El -zobv realmente no está relacionado con la pregunta que es "¿qué debo preservar?"

Muchos de los consejos de respaldo que veo, como el uso dd, parecen presuponer que el disco está desmontado y no está en uso. Pero no estoy supone excluir "vivo" directorios como / proc y algunos de los subdirectorios bajo / var (Sin embargo, algunas de las cosas en / var Sé que definitivamente hacemos necesidad de mantener) y / montaje? ¿Qué más hay que pensar en esta situación? Entonces supongo que solo puedo gruñirlo con rsync y usar un montón de --excludebanderas.

¿O hay mejores ideas, especialmente las amigables con FOSS?


Entiendo que esta pregunta parece extremadamente básica, pero después de haber ejecutado este tipo de sistemas durante tanto tiempo, lo he estropeado una y otra vez y nunca he asimilado cómo hacerlo correctamente
Sandra


Por lo que vale, cp -r -aconservará tantos atributos de archivo como sea posible al copiar archivos (según lo que admita el sistema de archivos de destino). La -abandera indica cpque se preserven los atributos. Para copiar a través de una red o mediante un sistema de archivos que no admite los atributos requeridos, tar -csiempre me ha funcionado, aunque creo que hay algunos casos extremos que no cubre y, en particular, creo que tardepende de forma predeterminada de los nombres de usuario que coinciden en ambos sistemas Dicho esto, he copiado un sistema Linux completo (sin montar) usando tarsin ningún problema aparente.
Micheal Johnson

Además, ¿hay alguna razón particular por la que sea necesario copiar el sistema en vivo?
Micheal Johnson

¿Usar el servicio de instantáneas de linode?
ivanivan

Respuestas:


15

¿Desea hacer una copia de seguridad de toda su unidad sin todos esos errores desagradables y también filtrar todas las carpetas / proc y otras carpetas temporales?

Una opción es montar la carpeta raíz en otra carpeta dentro del sistema de archivos, así:

$ cd /mnt
$ mkdir drive
$ mount --bind / drive

Esto le dará todos los archivos que hay en su disco que no se consideran temporales (como las carpetas / proc o / sys).

Ahora que tiene una vista limpia de su carpeta raíz, puede copiarla a su unidad de copia de seguridad usando estándar cpo rsync. Algo en la línea de:

cp -R /mnt/drive /mnt/backupdrive

Esto resuelve ambos problemas mencionados:

  • No entra en recursión, porque el disco de respaldo no está montado dentro de la unidad (punto de vista)
  • no te pierdas ningún archivo importante, porque los estás tomando todos

Ver también: montaje de hombre (8)


66
Cuidado, con esta solución puede copiar archivos que se están escribiendo, como bases de datos. Recomiendo ejecutar un script para volcar la base de datos en un archivo separado antes de copiar los archivos. Por ejemplo, para MySQL puede usar mysqldump.
Marco Martinelli

10

En Linux todo es un archivo. Es posible a través de rsync, pero hay cosas a tener en cuenta, que son (en el mejor de los casos) difíciles de solucionar.

Debe pensar primero en la replicación, especialmente para las bases de datos. Además, esta es una buena idea para configurar el proxy / balanceador de carga frente a su servidor primario, para que pueda cambiar fácilmente entre sus servidores primario y espejo durante la transición.

A nivel de hardware, la mejor situación será tener un servidor tipo espejo en el otro lado, con la misma cantidad de puertos ethernet, el mismo diseño del disco duro, etc. Todo lo que difiere implica la necesidad de cambios en la configuración del sistema.

es decir, si tiene dos puertos eth, desea asegurarse de que la configuración de la red, el firewall, etc. coincida con el nombre de la interfaz en ambos servidores, y en caso de que sea diferente, debe cambiar la configuración después de rsync o cambiar el nombre del dispositivo en el segundo (destino) del servidor.

Lo mismo con el diseño de partición. Debería crear las mismas particiones que en su servidor primario, pero si las crea desde cero, terminará con diferentes UUID, por lo que deberá cambiar fstab, grub, mdadm (si está involucrado el raid suave), etc. .

Pero también hay muchas cosas que pueden salir mal, como las bases de datos, que pueden ser inconsistentes si no se detuvieron previamente (antes de hacer rsync).

La mejor estrategia será preparar primero el hardware y el sistema de archivos (particiones), para que coincida con la configuración del servidor primario. Luego monte parititons vacíos a través de un sistema intermedio (como un CD en vivo con ssh-server instalado temporalmente). Crea vacío / proc, / dev, / sys y luego rsync el resto, así:

rsync -avz -H --delete /etc /bin (...and so on) destserver:/mnt/yourrootfs/

Luego, debe instalar grub en el dispositivo y trabajar en la configuración, para que sea de arranque, cambiar la configuración de red, fstab y otras cosas mencionadas anteriormente.

También puede intentar instalar un sistema nuevo (con la misma versión que está usando en su servidor primario), luego apagarlo, montarlo a través de otro sistema temporal (como live cd), luego reemplazar cualquier cosa que no sea / proc, / sys, / dev y / boot con rsync.

Pero es solo una idea general. Las cosas pueden complicarse dependiendo de lo que realmente tenga en este servidor, cuál es su configuración, red y configuración de hardware. Y al final del día, esto podría ser realmente difícil o imposible hacerlo sin un tiempo de inactividad notable.


Re bases de datos: si tiene las abstracciones apropiadas del sistema de archivos en su lugar (por ejemplo, un LVM), es posible que pueda tomar una instantánea coherente de la unidad sin tener que replicar la base de datos completa. Sin embargo, esto requiere que su base de datos sea kill -9segura, o de lo contrario podría no recuperarse. Una buena base de datos debería manejar esa situación, pero un sorprendente número de productos no lo hacen (o peor, casi siempre se recuperan, pero fallan una vez en una luna azul cuando realmente los necesitas para funcionar). Entonces, en la práctica, la replicación es probablemente más confiable de todos modos.
Kevin

5

Lo que realmente quieres es restauraciones. Hagas lo que hagas, debes restaurar probarlo regularmente.


Linode tiene un servicio de respaldo. Las instantáneas se pueden tomar en un horario predefinido limitado o con una API.

Una ventaja de las copias de seguridad basadas en instantáneas es que ofrecen un punto preciso en el tiempo, ya que los datos no cambian mientras se realiza una copia. Las instantáneas también se pueden restaurar fácilmente a un host diferente, un nuevo Linode en este caso.


No veo nada sobre garantizar que esas copias de seguridad sigan funcionando si, por ejemplo. Linode se declara en quiebra.
Mark

Me enteré del servicio de copia de seguridad de Linode mientras escribía una de las ediciones de mi pregunta y lo hablé con mi colega y lo hicimos. Resolvió nuestra crisis inmediata, pero también trataremos de encontrar una manera de almacenar los datos en nuestros propios hogares. Entonces, por mencionar que tienen ese servicio, no estaba al tanto cuando publiqué por primera vez. Pero las restauraciones tienen el siguiente problema: si nuestro servidor está mal configurado, una bola de chicle y colgadores de alambre, no necesariamente queremos restaurarlo exactamente al mismo estado mal configurado. Sin embargo, queremos nuestros datos favoritos.
Sandra

Había escrito un poco más sobre también exportar esta copia de seguridad a otro almacenamiento si se adaptaba a su objetivo de punto de recuperación y dominios de falla. Pero dejé eso para ser breve. Un buen plan de continuidad del negocio, del que las copias de seguridad son meramente parte, identifica y aborda dichos riesgos.
John Mahowald

1

Estoy usando BackupPC para mi pequeño servidor privado virtual, esto funciona razonablemente bien. BackupPC puede usar rsync debajo del capó y admite copias de seguridad completas e incrementales. Eche un vistazo y vea si cubriría sus requisitos.


1

Ejecute su sistema en ZFS. Luego puede tomar una instantánea instantánea, atómica, usando algo similar a:

# zfs snap -r tank@name-of-backup

donde tankestá el nombre de su grupo ZFS. Esta instantánea está garantizada como una instantánea instantánea en el tiempo del sistema de archivos y todos sus sistemas de archivos secundarios.

Una vez que haya creado la instantánea, puede transferirla a otro host usando zfs sendy ssh.


0

En mi opinión, depende de qué y dónde ejecuta el servidor con el comando interno de Linux no es posible, debe imitar / canalizar datos completos y bibliotecas. Si se ejecuta en vmware y está bien configurado, proporciona migración en vivo. O bien, tiene que usar herramientas de terceros. Espero que esto te ayudará. Algunas referencias más ¿Cómo hago una copia de seguridad de un servidor en vivo?

Rsync es un buen comando para sincronizar los datos entre servidores.


0

Hay 2 soluciones disponibles, en las que no es necesario depender (más) de los bits faltantes, así como de perder un elemento de su lista debido a una lista de verificación incompleta o tal vez porque simplemente se pasa por alto algo importante.

En primer lugar, si mueve esto a una plataforma con un poco más de control sobre la plataforma de hardware subyacente, puede tomar instantáneas de disco de todos los archivos mientras se ejecuta el servidor. Por ejemplo, en AWS puede tomar una instantánea de un disco EBS e incluso solo pagar las diferencias cuando realiza otra instantánea más tarde.

En segundo lugar, recomiendo hacer un script para la configuración de su servidor completo con un sistema de gestión de configuración, como Ansible. Esta voluntad

  • documentar todo lo que ha configurado en el control de origen

  • le permite probar recrear el servidor desde una copia de seguridad o un metal desnudo para asegurarse de que sus scripts estén actualizados

  • le permite volver a ejecutar el script en un sistema operativo más nuevo, generalmente con cambios bastante menores.


1
Resulta que también puedes hacer instantáneas en Linode. Voy a revisar Ansible! Ese es un tema secundario de lo que originalmente quería saber, pero algo así, y nunca había oído hablar de él [quiero decir, había oído hablar del dispositivo ficticio de los maravillosos libros de Hainish], ¡suena maravilloso!
Sandra
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.