47 votos

Linux - ¿Qué directorios debo excluir al hacer una copia de seguridad de un servidor?

Estoy haciendo una copia de seguridad de un servidor Linux y la almaceno en otro servidor.

Empecé con un simple

rsync -aPh --del server.example.com:/ /mnt/backup

Entonces alguien señaló que no debería retroceder /proc ya que no quiere restaurar el /proc de un servidor en otro.

¿Hay algo más que deba/no deba incluir?

Por ejemplo, ¿qué pasa con /sys ?

43voto

CesarB Puntos 908

Ambos /proc y /sys son sistemas de archivos virtuales que reflejan el estado del sistema y permiten cambiar varios parámetros de ejecución (y a veces hacer cosas más peligrosas, como escribir directamente en la memoria o en un dispositivo). Nunca debes hacer una copia de seguridad o restaurarlas.

En la mayoría de las distribuciones modernas, /dev se crea dinámicamente en el arranque (es un sistema de archivos de memoria llenado por udev y amigos). No tiene sentido hacer una copia de seguridad, y tratar de restaurarla es inútil. Sin embargo, si su distribución está configurada para utilizar un /dev no se aplica (marque /proc/mounts , si /dev es un tmpfs es un sistema de archivos de memoria).

Hay otros sistemas de archivos de los que no deberías hacer una copia de seguridad; usbfs (normalmente en /proc/bus/usb Si es que se monta), debugfs (se supone que está en /sys/kernel/debug si está montado, pero algunas personas lo ponen en otro lugar; probablemente no tenga este), devpts (montado en /dev/pts ), otros tmpfs instancias (que a menudo se encuentran en /dev/shm , /var/run , /var/lock y otros lugares; hacer una copia de seguridad y restaurarlas debería ser inofensivo pero inútil, ya que su contenido se pierde al apagar), y cualquier sistema de archivos remoto o directorios mágicos de autocontabilidad (intentar hacer una copia de seguridad o restaurarlas podría terminar en un desastre, ya que podría terminar haciendo una copia de seguridad/restauración en una máquina diferente ). También hay que tener cuidado con /media y /mnt como dispositivos externos (como un CD que olvidaste en la unidad) podrían encontrarse allí, pero también podrías haberlos utilizado a propósito para montar algo de lo que se debería hacer una copia de seguridad.

Tenga en cuenta que, aparte de la mayoría de los inofensivos tmpfs instancias, sistemas de archivos de red/automounters y medios extraíbles, los sistemas de archivos de los que no se debe hacer una copia de seguridad son todos descendientes de /dev , /proc o /sys . Si no tiene sistemas de archivos de red (o automounters), y no hay medios extraíbles, excluyendo /sys y /proc y el reinicio después de una restauración (para borrar el tmpfs instancias) debería ser suficiente.

25voto

jimg Puntos 459

Esto depende realmente de cómo vayas a restaurar tu sistema. Si va a reconstruir, entonces sólo necesita los archivos de configuración/datos para sus servicios (por ejemplo: /etc, /opt, /var, /home)

Si lo que busca es una restauración completa del sistema, entonces podría omitir /proc, /boot y /dev. Entonces puede instalar el sistema operativo mínimo desde su medio de arranque y luego restaurar su sistema a través de su copia de seguridad.

Por supuesto, la mejor copia de seguridad es aquella que ha sido probado y verificado .

Así que omite lo que no crees que necesitas, intenta restaurar en una VM y verifica que puedes recuperar tu sistema usando estos datos.

6 votos

No omitas /boot por completo - es posible que tenga que comparar la antigua configuración de arranque con la nueva configuración de arranque. Sólo asegúrese de no restaurar /boot excepto manualmente.

5 votos

Y excluir /sys también... Y para restaurar al metal desnudo, es mejor excluir /etc/udev/rules.d/ también.

2 votos

También lost+found que para el sistema de archivos, /mnt y /media para no copiar ningún dispositivo montado

19voto

GvS Puntos 28137

Ver El Tao de las copias de seguridad , capítulo 1.

8voto

pjc50 Puntos 1324

Algunos archivos especiales en /proc y /sys confunden a rsync. Por lo general, tampoco es conveniente hacer una copia de seguridad de los sistemas de archivos de red montados. Los archivos dispersos también pueden causar problemas.

Añade -x para limitarlo a un sistema de archivos. Esto evita todos los sistemas de archivos de red y /proc, etc. Sin embargo, tendrá que ejecutar un rsync para cada sistema de archivos que haya montado.

Añade -S para manejar archivos dispersos de forma sensata.

3voto

Michael Pobega Puntos 748

Podrías conseguir una copia de seguridad total usando sfdisk y dd.


Para hacer una copia de seguridad del esquema de particiones de cada disco duro, utilizarías sfdisk de la siguiente manera:

sfdisk -d /dev/sda  > parttable_sda.part

Para hacer una copia de seguridad de cada partición puedes usar dd, así:

dd if=/dev/sda1 of=devsda1.img

Dónde /dev/sda1 está desmontado, como en el caso de un arranque con un CD en vivo.

(tenga en cuenta que va a necesitar mucho espacio libre para escribir este archivo; así que puede querer escribirlo en un medio externo) Haz esto para cada partición, una a la vez, y haz una copia de seguridad de todo.


Entonces, para restaurar en otro ordenador se puede hacer:

sfdisk /dev/sda < parttable_sda.part
dd if=devsda1.img of=/dev/sda1    # do this for each partition

4 votos

ADVERTENCIA: sólo haga esto si la partición está desmontada o montada de sólo lectura. Volcar el contenido en bruto de una partición mientras se está escribiendo en ella puede acabar con un sistema de archivos muy inconsistente en la copia de seguridad (porque los bloques cercanos al principio del sistema de archivos se copian "antes" que los bloques cercanos al final, y los algoritmos del sistema de archivos no esperan esto; puede evitar este problema si puede hacer de alguna manera una instantánea atómica del sistema de archivos). fsck no le ayudará, ya que sus algoritmos también dependen del orden en que el sistema de archivos escribe en el disco.

0 votos

Dd es el camino a seguir. Arrancar en un LiveCD, por supuesto. Y es importante dd if=/dev/urandom of=/dev/sdb bs=512 count=12 para borrar el MBR y la tabla de particiones de la unidad de destino.

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by: