solución de copia de seguridad habilitada para btrfs

14

Con btrfs llegando a producción en Oracle EL 14th este mes (junto con fsck de trabajo y depuración de Linux 3.2) estaba pensando en rediseñar mi solución de respaldo actual para utilizarla. Tenga en cuenta que estoy pensando en hacerlo para pequeñas cantidades de datos, menos de 10 TB, eso es bastante estático (menos del 1% cambia diariamente). En resumen, una solución de respaldo SMB / SOHO.

Lo que debe hacer la copia de seguridad:

hacer una instantánea LVM de ext [234] / XFS / JFS en el servidor de producción
rsync/ transferir datos modificados a btrfs en el servidor de respaldo
instantánea del sistema de archivos btrfs
soltar instantáneas antiguas cuando el espacio libre se está agotando

Pros:

Todos los archivos están fácilmente disponibles, no se necesita descompresión ni montaje en bucle
Las instantáneas pasadas también están fácilmente disponibles ...
... para poder compartirlos como recursos compartidos de Samba de solo lectura (con soporte de instantáneas)
Las instantáneas ocupan una cantidad mínima de espacio gracias a la copia en escritura (la instantánea sin cambios toma literalmente pocos KiB en el disco)
Alta consistencia de copia de seguridad: sumas de comprobación en archivos, depuración de todos los datos y redundancia incorporada

Preguntas:

¿Existe alguna solución de respaldo (en forma de Bacula, BackupPC, etc.) que sea, o pueda ser fácilmente, consciente del sistema de archivos de copia en escritura?
¿O tendré que usar una rsyncsolución en el hogar ?
¿Qué hacen las personas con cajas ZFS dedicadas a la copia de seguridad para hacer una copia de seguridad de sus máquinas Linux?

— Hubert Kario
fuente

No puedo ver cons! Una de ellas sería que las instantáneas Btrfs solo son equivalentes a las copias de seguridad incrementales (sin copia física por copia de seguridad de su archivo en el disco). Lo que podría ser importante cuando se enfrentan problemas de superficie del disco. Tenga en cuenta que puede forzar una duplicación con el soporte RAID1 nativo incluido en Btrfs.

— vaab

1

@vaab: eso es pro: más de dos copias no son realmente necesarias si tiene sumas de verificación y frega activamente el FS, tres probablemente vendrán con soporte RAID6. Como he dicho, es una configuración para un sistema de respaldo dedicado, no copias de "respaldo" dentro del FS en una sola computadora. Eso sería "RAID no es una copia de seguridad" y "las instantáneas no son una copia de seguridad". cp -ay rsyncson para eso ...

— Hubert Kario

También estoy considerando hacer una copia de seguridad en btrfs, pero solo estaba pensando rsync -a --delete /home/user /mnt/butterfs/backups/ && snapper create, aparte de crear una instantánea después de la copia de seguridad, ¿qué quieres decir con COW-aware?

— Martillo

1

@unhammer: si usa rsyncsin --inplaceobtendrá múltiples copias de los mismos datos en el sistema de archivos remoto. (rsync normalmente copia datos en un archivo oculto temporal y luego lo mueve sobre el archivo antiguo, con un sistema de archivos de Copia en escritura obtiene dos copias de datos sin cambios de esta manera)

— Hubert Kario

5

Hice una búsqueda exhaustiva en la última semana para algo similar. No he encontrado soluciones para hacer los 4 pasos. Existen numerosos blogs de usuarios domésticos que prueban el tipo de copias de seguridad ' rsync to btrfs ', y todas las principales wikis de Btrfs cubren cómo realizar instantáneas de Btrfs.

También hay algunas personas que intentan diferentes formas de rotar las instantáneas de Btrfs . Sin embargo, usted es la primera persona que he visto que quiere rotar las instantáneas en función del espacio en disco. Estoy jugando con btrfs-snap, que crea un conjunto de instantáneas por hora, semanales y mensuales, y es agradable y simple.

El proyecto Dirvish parece cumplir con muchos de sus requisitos. Algunos desarrolladores están intentando integrar Dirvish con Btrfs . Sin embargo, el proyecto Dirvish parece un poco estancado .

En este momento, estás por delante de la curva.

— Stefan Lasiewski
fuente

Bueno, solo quiero una solución de respaldo tan sencilla como BackupPC: cuando el espacio en disco es bajo, simplemente elimina datos antiguos (instantáneas antiguas). Si bien tenía miedo de estar por delante de la curva, no es que ZFS no haya estado con nosotros en los últimos años ...

— Hubert Kario

3

Según Avi Miller (su charla durante LinuxConf.AU) se está trabajando en un envío / recepción de btrfs. Será más rápido que rsync ya que no necesita atravesar directorios para encontrar cambios en los archivos. Sin embargo, aún no sé si hay una fecha de lanzamiento esperada.

Sin embargo, existe una utilidad integrada en btrfs-progs que enumera todos los archivos que han cambiado entre instantáneas / etc. btrfs subvolume find-new

— aburrido
fuente

2

Quiero hacer una copia de seguridad en btrfs, no desde ...

— Hubert Kario

2

Estoy trabajando en un sistema de copia de seguridad del sistema operativo similar a BackupPC. He pensado en esto. Lo que me ha impedido implementar realmente eso es que no se puede vincular entre subvolúmenes. También solo puede crear instantáneas de subvolúmenes -> Un subvolumen por cliente de respaldo. Por lo tanto, la función de deduplicación a nivel de archivo no puede coexistir con este enfoque. Y esa deduplicación a nivel de archivo generalmente ahorra mucho espacio. ¿Desea hacer una copia de seguridad de un solo servidor?

Si btrfs tuvo deduplicación a nivel de bloque, este problema probablemente se puede evitar, pero eso también es muy lento ...

Entonces, dicho enfoque implicaría, por supuesto, una estrecha integración con un sistema de archivos (btrfs), por lo que esta debería ser una característica opcional.

Lo pregunto porque estoy pensando en agregar una función de vaca, pero no sé si debería debido a los inconvenientes mencionados anteriormente.

Editar: UrBackup admite copias de seguridad como se describe en la pregunta ahora con núcleos Linux> = 3.6 (con soporte de reflink de volumen cruzado). Vea cómo configurarlo.

— UrOni
fuente

1

la copia de reflink de subvolumen cruzado (un semi-hardlink hecho por cp --reflink) ya está implementada o se implementará en un futuro próximo. Línea de-duplicación de FS es bien lenta (LessFS) o necesita grandes cantidades de memoria RAM (ZFS) así que dependiendo de que sería realmente una mala función en el software de copia de seguridad. De cualquier manera, el software de respaldo orientado a btrfs tendrá una gran audiencia, se supone que es la próxima ext3 después de todo.

— Hubert Kario

Una cosa más: puede solucionar este problema manteniendo todos los servidores en un subvolumen: puede volver a vincular la copia entre ellos (para deducir) mientras conserva la capacidad de instantánea. Solo tiene que hacer una instantánea después de deducir, ¡aún puede hacer una instantánea después de hacer una copia de seguridad de un solo servidor! Las copias de seguridad no ocuparán más espacio si realiza las copias de seguridad de una en una. Alternativamente, puede hacer una copia de seguridad de todos los servidores, deduplicar y solo luego una instantánea. De esta forma, puede hacer una copia de seguridad de algunos servidores al mismo tiempo.

— Hubert Kario

Tienes razón. No pensé en eso. Para mayor comodidad, puede hacer un enlace simbólico a las instantáneas correctas en otro volumen. También vi un parche para hardlink de volumen cruzado (o --reflink) pero no parecía que lo hiciera / o llegará a la línea principal. ¡Realmente lo investigaré! Ahora probablemente haga sus copias de seguridad a través de ssh. Mi proyecto está especializado para redes locales ... (descubrimiento automático, etc.)

— UrOni

Sí, el parche está vivo y funcionando, desafortunadamente no en la línea principal, no sé por qué. Estoy tratando de molestar a Chris Mason al respecto. En cuanto a su proyecto, no dude en enviarme una línea, con mucho gusto lo probaré en beta (si el tiempo lo permite). Seguro que suena interesante.

— Hubert Kario

Finalmente, ese parche aterrizó en el núcleo principal de Linux 3.6. Con el reflink entre dispositivos, en realidad no fue tanto trabajo. He escrito aquí al respecto: urbackup.org/blog/?p=83 El código se encuentra en la "siguiente" rama del repositorio de git. Actualmente lo estoy probando.

— UrOni

1

La página wiki de btrfs " Casos de uso " enumera algunas herramientas: SnapBtr , Snapper, btrfs-time-machine, UrBackup.

Hay una propuesta para una herramienta integrada llamada autosnap :

Usando la función autosnap, puede configurar btrfs para tomar instantáneas regulares o basadas en eventos y administrar aún más las instantáneas automáticamente.

Autosnap no se trata solo de tomar la instantánea, sino también de administrar las instantáneas creadas, a partir de ahora puede configurar autosnap para eliminar las instantáneas en función del espacio utilizado en el sistema de archivos.

Sin embargo, a partir de octubre de 2013, el wiki afirma que "la funcionalidad de autosnap no está incluida actualmente en la versión anterior de btrfs".

— ignis
fuente

1

Tuve frustraciones similares, así que terminé creando algunos scripts que llamo snazzer . Juntos ofrecen instantáneas, podas, mediciones y transporte a través de ssh (pero a partir de hoy también pueden enviar / recibir a / desde sistemas de archivos locales). Las mediciones son solo informes de firmas sha512sum y PGP de rutas de instantáneas. Aún no está listo para su lanzamiento, pero me encantaría recibir comentarios si alguien tiene tiempo para revisarlo en esta etapa temprana.

CLI-sólo en este punto, pero he tomado algún tiempo para que sea fácil de usar en sistemas con muchas subcaudales btrfs - normalmente tengo subcaudales separadas para /var/cache, /homeetc., que pueden necesitar ser excluido de copia instantánea o tienen más / menos horarios de poda agresivos.

Me temo que el algoritmo de poda simplemente toma decisiones sobre la presencia del conjunto de instantáneas y sus fechas, no hay nada para seguir podando hasta que se cumpla una restricción de uso del disco, ¿cuál elimina primero? ¿Reducir el número de horas por hora primero o por día? Quizás deje caer al más viejo, por ej. Yearlies? Las diferentes implementaciones tendrán diferentes prioridades; y no puedo saber si este es el único nivel de copia de seguridad (en cuyo caso no debe eliminar las copias de seguridad más antiguas en caso de obligaciones legales / de seguro), o simplemente una intermedia (en cuyo caso probablemente tenga esos anuarios archivados en algún lugar seguro en otra parte).

Agregaré compatibilidad con ZFS y / o interoperabilidad en algún momento; está escrito principalmente en shell y perl posix-ish debido a un fuerte deseo de dependencias "cero" en este momento, espero tener una implementación alternativa de Python más limpia mantenida en paralelo en algún momento.

— csirac2
fuente

a menos que su FS sea muy grande y a menudo cambie, hay muy poca diferencia entre mantener una instantánea de hace un mes y solo 1 por día de la semana pasada en comparación con una por día durante todo el mes; btrfs necesitará almacenar la diferencia entre de todos modos, el estado actual y el de hace un mes, mantengo solo diarios, pero debido a que está comprimido y diferido, puedo mantenerlos durante medio año con facilidad, y luego dejar caer las garantías más antiguas para liberar al menos algo de espacio

— Hubert Kario

Bueno, tengo un número no trivial de máquinas virtuales para realizar un seguimiento, algunas con archivos transitorios grandes (es decir, instantáneas con extensiones únicas) que, como ha sugerido, pueden beneficiarse de la poda de instantáneas intermedias. Entonces, si bien es cierto que podar intermedios no libera tanto disco como soltar los más antiguos, ¿qué puedo decir? Mantener solo el número mínimo de instantáneas y hacerlo con el sistema de archivos COW como btrfs parece ser tan eficiente como Obtiene, pero me di cuenta de que hay más a recoger una solución adecuada que eso :)

— csirac2

@ csirac2 ¿estás manteniendo un snazzer? Estoy buscando este tipo de solución. Estoy interesado en snazzer si se mantiene activamente. GitHub no parece mostrar actividad reciente ...

— MountainX-for-Monica

@MountainX Cuando no recibí muchos comentarios iniciales sobre snazzer, perdí el entusiasmo. Cuando comencé a escribirlo, en realidad solo había el pargo de OpenSUSE y un puñado de scripts de shell / python flotando para automatizar btrfs. Cuando llegué a compartirlo con el mundo, aparecieron muchas otras opciones, y diría que btrbk parece tener un gran impulso (aunque la falta de pruebas automáticas [¿tal vez arregladas ahora?] Era preocupante). Si tuviera que hacerlo todo de nuevo, probablemente habría colaborado con el autor sanoid para agregar compatibilidad btrfs allí. Interesado en oir tus pensamientos.

— csirac2