{"id":1332,"date":"2026-02-05T14:36:46","date_gmt":"2026-02-05T17:36:46","guid":{"rendered":"https:\/\/www.marianoacciardi.com.ar\/?page_id=1332"},"modified":"2026-02-05T16:39:03","modified_gmt":"2026-02-05T19:39:03","slug":"caso-btrfs-instantaneas-snapshots-para-branchs-de-testing","status":"publish","type":"page","link":"https:\/\/www.marianoacciardi.com.ar\/?page_id=1332","title":{"rendered":"Caso BTRFS: instant\u00e1neas (snapshots) para branchs de testing"},"content":{"rendered":"\t\t<div data-elementor-type=\"wp-page\" data-elementor-id=\"1332\" class=\"elementor elementor-1332\">\n\t\t\t\t<div class=\"elementor-element elementor-element-e61e7f9 e-flex e-con-boxed e-con e-parent\" data-id=\"e61e7f9\" data-element_type=\"container\">\n\t\t\t\t\t<div class=\"e-con-inner\">\n\t\t\t\t<div class=\"elementor-element elementor-element-8cf366a elementor-widget elementor-widget-text-editor\" data-id=\"8cf366a\" data-element_type=\"widget\" data-widget_type=\"text-editor.default\">\n\t\t\t\t<div class=\"elementor-widget-container\">\n\t\t\t\t\t\t\t\t\t<h4 class=\"western\"><a name=\"__RefHeading___Toc8050_137071848\"><\/a>Uso de la tecnolog\u00eda BTRFS<\/h4><p>Nota: Este documento solo tiene la funci\u00f3n pedag\u00f3gica de ense\u00f1ar como utilizar esta tecnolog\u00eda, no haci\u00e9ndose responsables los autores por ning\u00fan problema o informaci\u00f3n o perdida de datos que el intento de aplicar lo aqu\u00ed mencionado produzca. Hasta no conocer bien la tecnolog\u00eda se sugiere probar lo aqu\u00ed mencionado en un ambiente de laboratorio.<\/p><p class=\"western\">Btrfs es una tecnolog\u00eda que cambia el paradigma de los FS de linux. Recupera todos los avances pr\u00e1cticos de los \u00faltimos 20 a\u00f1os y concibe un sistema completo de storage, incluyendo y superando gran parte de las cosas que se pod\u00edan hacer con mdadm (RAIDs de Linux), lvm (Logic volume manager de Linux), enriqueci\u00e9ndolo con logros y aciertos de zfs (Zettabyte File System original de open solaris y retomado como fs de facto de soluciones BSD como Free\/True NAS). Es una tecnolog\u00eda muy flexible que facilita cosas que de otra manera ser\u00edan muy costosas.<\/p><p>En este caso espec\u00edfico de estudio se indaga la utilidad de los snapshots de btrfs para facilitar la creaci\u00f3n de un ambiente de testing en un servidor con recursos limitados.<\/p><p>Otros usos de snapshots no abarcados por este texto son por ejemplo el resguardo de informaci\u00f3n ante una migraci\u00f3n o upgrade. Ante un problema en la migraci\u00f3n o upgrade, puede volverse al estado anterior restaurando el snaphot previo. Sin embargo este uso no ser\u00e1 descripto aqu\u00ed.<\/p><p>Es imprescindible destacar que lo aqu\u00ed mencionado solo puede ser utilizado en la medida en que las pol\u00edticas de seguridad de la organizaci\u00f3n <strong>admitan la posibilidad de compartir datos entre ambientes<\/strong>. Ya que desde el ambiente de testing creado en el snapshot<strong> se accede, en modo lectura, a toda la informaci\u00f3n del volumen original<\/strong> + los cambios realizados en testing. La informaci\u00f3n original<span style=\"text-decoration: underline;\"><strong> s\u00ed queda resguardada de los cambios que se\u00a0realicen sobre el snaphotde testing<\/strong><\/span>. El volumen original y los snapshot comparten informaci\u00f3n del momento de snapshot pero no modificaciones ulteriores. Cada uno funciona como si fuese un volumen independiente, siendo transparente para las aplicaciones si la informaci\u00f3n est\u00e1 en bloques del volumen original o del snapshot.<\/p><p class=\"western\">Se describe a continuaci\u00f3n las necesidades a que respondi\u00f3 su utilizaci\u00f3n en este caso de trabajo y su contexto:<\/p><ul><li><p class=\"western\">Necesidad de tener la posibilidad de levantar completamente un ambiente de testing.<\/p><\/li><li><p class=\"western\">Restricci\u00f3n de espacio en los servidores que hac\u00edan imposible esta necesidad sin el recurso a snapshots (Instant\u00e1neas).<\/p><\/li><\/ul><h4 class=\"western\"><a name=\"__RefHeading___Toc8052_137071848\"><\/a> Instant\u00e1neas BTRFS.<\/h4><p class=\"western\">Una de las facilidades m\u00e1s flexibles de BTRFS es la posibilidad de sacar instant\u00e1neas de un momento dado del FS. Esta instant\u00e1nea puede servir como backup antes de un cambio riesgoso o explotar otra funcionalidad compartiendo gran parte de los bloques originales de FS en dos l\u00edneas de tiempo\/modificaciones distintas.<\/p><p class=\"western\">El uso m\u00e1s frecuente del Snapshot es congelar el FS antes de los cambios para que, en el caso que algo salga mal, volver al punto de partida de manera r\u00e1pida y segura.<\/p><p class=\"western\">Sin embargo, una de las funcionalidades m\u00e1s interesantes del snapshot es que BTRFS admite la creaci\u00f3n de Snapshots RW, esto es con posibilidad de continuar escribiendo cambios sobre el snapshot, sin alterar el FS original, pero, al mismo tiempo, compartiendo la informaci\u00f3n que no cambia. Un snapshot RW funciona como una copia viva del FS original, pero sin duplicar la informaci\u00f3n y solo incrementa el espacio requerido para los cambios y la duplicaci\u00f3n de la metadata. Es la tecnolog\u00eda ideal para generar un branch de testing, sobre todo si no hay storage suficiente para duplicar todo y la informaci\u00f3n que pueda modificarse en testing es un porcentaje peque\u00f1o del total de la informaci\u00f3n.<\/p><h4 class=\"western\"><a name=\"__RefHeading___Toc8054_137071848\"><\/a> Descripci\u00f3n general del funcionamiento de los snapshots en BTRFS<\/h4><p class=\"western\">No es necesario extenderse demasiado en como funciona, pero se detallan a continuaci\u00f3n algunos aspectos t\u00e9cnicos a los fines de para entender como es el uso de espacio y como se mantiene actualizado el mirror del fs de producci\u00f3n.<\/p><p class=\"western\">BTRFS utiliza por defecto una tecnolog\u00eda llamada CoW (Copy on Write), es decir, si uno no se lo define expl\u00edcitamente, nunca reescribe modificaciones sobre los bloques de datos originales. Esto es, por ejemplo, si yo tengo guardado un archivo y lo modifico parcialmente, cuando se graba, el FS autom\u00e1ticamente genera el archivo modificado a partir de los bloques originales intocados + los bloques modificados grabados en un extent distinto del original. Luego de que la escritura se realiza correctamente se libera el espacio utilizado por los bloques modificados. Esto es transparente para las aplicaciones.<\/p><p class=\"western\">Este principio de CoW se utiliza para los snapshot RW. En el contexto de un branch de testing funciona m\u00e1s o menos de esta manera:<\/p><ul><li><p class=\"western\">En el momento del snapshot ocurre lo siguiente<\/p><ul><li><p class=\"western\">Se crea un sistema de referencias (metadata) completamente nuevo que conforma la metadata del nuevo volumen snapshot .<\/p><\/li><li><p class=\"western\">Todas las nuevas referencias de los archivos apuntan a exactamente los mismos bloques de datos.<\/p><\/li><li><p class=\"western\">En el volumen ahora existen en <b>\/dataoriginal\/miarchivo<\/b> y <b>\/snapshot20260108\/miarchivo<\/b> como dos archivos separados<\/p><\/li><li><p class=\"western\">Las referencias de ambos archivos apuntan a exactamente los mismos bloques de datos en el mismo extent.<\/p><\/li><li><p class=\"western\">En el volumen se encuentra duplicada la metadata de <b>miarchivo<\/b> pero no la informaci\u00f3n o los datos que constituye el contenido del documento.<\/p><\/li><li><p class=\"western\">Para las aplicaciones se trata de dos archivos distintos situados en diferentes volumenes, sin embargo los datos ocupados por ambos son exactamente los mismos<\/p><\/li><\/ul><\/li><li><p class=\"western\">Cuando abro el archivo <b>\/snapshot2026018\/miarchivo<\/b>, lo modifico y guardo:<\/p><ul><li><p class=\"western\">CoW Realiza como siempre una copia de boques originales + bloques modificados y graba el nuevo archivo colocando los nuevos bloques en otro extent.<\/p><\/li><li><p class=\"western\">Cuando termina de grabar, detecta que los bloques originales estaban referenciados por la metadata desde otro lugar: <b>\/dataoriginal\/miarchivo<\/b> entonces no los libera<\/p><\/li><li><p class=\"western\">En este caso el archivo original queda sin tocar, el archivo nuevo puede tener bloques compartidos con el original y bloques nuevos en otro extent. Ahora <b>\/dataoriginal\/miarchivo<\/b> qued\u00f3 intacto y <b>\/snapshot2026018\/miarchivo<\/b> es el archivo modificado.<\/p><\/li><li><p class=\"western\">Advertencia t\u00e9cnica: Lo que define si ambos archivos comparten o no los bloques originales el modo de escritura de la aplicaci\u00f3n. Por ejemplo un procesador de texto en general reescribe todo el archivo y no una parte. Esto hace que el archivo modificado duplica completamente todos los bloques. Es decir si el archivo original ten\u00eda 10K y ahora el nuevo 15k, la cantidad de espacio real utilizado por ambos archivos, habiendo un snapshot que lo referencia, es muy probable que sea 25. Sin embargo esta operatoria sigue siendo v\u00e1lida para un FS\u00a0 donde es much\u00edsima la informaci\u00f3n congelada y poca la que se va cambiando d\u00eda a d\u00eda.<\/p><\/li><\/ul><\/li><\/ul><p class=\"western\">Este funcionamiento nos permite tener un snapshot sobre el que corra la plataforma de testing que comparta todos los bloques de datos del filesystem original en un momento de tiempo dado, salvo las nuevas modificaciones que se vayan haciendo en testing. Se utiliza BTRFS con subvol\u00famenes y reflinks para generar un entorno de testing que comparte bloques con el mirror local de producci\u00f3n.<\/p><p class=\"western\">El subvolumen de testing no se utiliza como snapshot hist\u00f3rico para restaurar un estado anterior, sino como espacio de trabajo aislado mediante Copy-on-Write, permitiendo modificaciones m\u00ednimas de bloques sin duplicar el almacenamiento completo.<\/p><p class=\"western\">La sincronizaci\u00f3n rsync desde producci\u00f3n opera \u00fanicamente sobre el subvolumen principal (\/data) y el mecanismo interno de CoW es transparente.<\/p><h4 class=\"western\"><a name=\"__RefHeading___Toc8054_137071848 Copy 1\"><\/a> Operaci\u00f3n: creaci\u00f3n de snapshots y su disponibilizaci\u00f3n<\/h4><p class=\"western\">La creaci\u00f3n de snapshots se puede hacer en cualquier momento en que se decida congelar el estado de la plataforma. Si se trata de una aplicaci\u00f3n con soporte sobre base de datos, conviene hacer m\u00e1s o menos al mismo tiempo un backup de la base de datos de producci\u00f3n para que coincida lo m\u00e1s posible con el snapshot de los datos replicados. Como se explic\u00f3 m\u00e1s arriba, a partir de ese momento, en el filesystem btrfs se crean dos l\u00edneas de tiempo diferentes con pasado compartido, en donde una de ellas puede ser montado en el HFS est\u00e1ndar del OS como volumen separado.<\/p><p class=\"western\">Si se trata de una aplicaci\u00f3n con FS compartido por ejemplo por NFS, luego de crear el snapshot se debe montar y exportar por nfs de manera de hacerlo accesible a los nodos de aplicaci\u00f3n que lo necesite.<\/p><p class=\"western\"><b>Paso a paso para crear Snapshot<\/b><\/p><ol><li><p class=\"western\">De ser necesaria una definici\u00f3n estricta del momento de corte, se deber\u00eda detener la aplicaci\u00f3n durante unos segundos para que el snapshot tenga lo que realmente necesita tener.<\/p><\/li><\/ol><ol start=\"2\"><li><p class=\"western\">Ingresar con root al servidor que contiene el volumen BTRFS montado Ej: \/var\/ ser\u00eda el punto en donde el volumen original est\u00e1 montado.<\/p><\/li><li><p class=\"western\">Crear snapshot:<\/p><\/li><\/ol><p><code><span style=\"font-family: Liberation Mono, serif;\"><span style=\"font-size: small;\">btrfs subvolume snapshot \/var\/app\/data \/var\/app\/data_test_$(date +'%Y%m%d%H%M%S')<\/span><\/span><\/code><\/p><p><strong>Paso a paso para montar el snapshot como subvolumen<\/strong><\/p><ol><li class=\"western\">Montar el subvolumen snapshot de manera permanante desde fstab.<\/li><li style=\"list-style-type: none;\"><ol><li><p class=\"western\">Verificar que no haya nada en el punto de montaje, ej. \/appTest\/data<\/p><\/li><li><p class=\"western\">Realizar un backup de \/etc\/fstab por las dudas<\/p><\/li><li><p class=\"western\">Especificar la siguiente sintaxis en fstab, tomando como base el UUID del volumen principal nombrado desde la ra\u00edz del punto de montaje. El subvolumen se le especifica en las opciones de FS (4ta columna de fstab o bien -o de mount):<\/p><\/li><\/ol><\/li><\/ol><p><code><span style=\"font-family: Liberation Mono, serif;\"><span style=\"font-size: small;\">UUID=xxxxxx-xxxx-xxxx-xxx-xxxxxxxxxxxx \/var\/appTest btrfs defaults,auto,noatime,compress=zstd,space_cache=v2,subvol=app\/data_test_$(date +'%Y%m%d%H%M%S') 0 0<\/span><\/span><\/code><\/p><ol><li>Montar el recurso luego de la modificaci\u00f3n de fstab:<\/li><\/ol><p><code><span style=\"font-family: Liberation Mono, serif;\"><span style=\"font-size: small;\">systemctl daemon reload &amp;&amp; mount -a<\/span><\/span><\/code><\/p><p>De esta manera, los cambios que se realicen sobre el volumen montado en \/var\/appTest se ver\u00e1n reflejados en el snapshot creado, y los bloques de datos que no son modificados por la plataforma de test se comparten con el volumen original.<\/p><p>Es importante destacar que si se borran archivos en el volumen original, los bloques de datos continuar\u00e1n existiendo en la medida que tengan alguna referencia desde uno o m\u00e1s snapshot. Solo se liberar\u00e1 el espacio cuando los bloques no tengan ninguna referencia desde ning\u00fan snapshot\/subvolumen.<\/p><p>\u00a0Un snapshot es siempre un subvolumen. La rec\u00edproca no es correcta, no todos los subvolumenes son snaphots.<\/p><p>\u00bfQu\u00e9 es un subvolumen en btrfs? Un subvolumen btrfs es un punto o subdirectorio a partir del cual se genera una ra\u00edz de filesystem nueva e independiente. Esto incluye el sistema de referencias a bloques y metadata aislado. Esto permite incluso enviar subvolumenes completos por la red con los comandos send y receive de btrfs. La creaci\u00f3n de subvol\u00famenes es pr\u00e1cticamente instant\u00e1nea. Para el caso de un snapshot puede requerir unos segundos m\u00e1s seg\u00fan el tama\u00f1o de la metadata a duplicar. Es importante reiterar que <strong>no se copian los bloques de datos, sino unicamente la metadata de los archivos<\/strong>. Los bloques de datos, en tanto no se modifiquen archivos son los mismos, s\u00f3lo que ahora referenciados desde dos lugares diferentes.\u00a0\u00a0<\/p><p>La creaci\u00f3n de un subvolumen se ve como si fuese un subdirectorio, sin embargo no comparte estructura de metadata con el resto de los \u00abdirectorios\u00bb. Un subvolumen puede montarse independientemente como se hizo en este ejemplo con el subvolumen del snapshot.<\/p><p>Una vez montado de manera independiente, en el volumen de nivel superior, se oculta. Es decir tenemos dos maneras <strong>excluyentes<\/strong> de acceder a un subvolumen, si no est\u00e1 montado como si fuese parte de la estructura de directorios del volumen principal; si est\u00e1 montado \u00fanicamente desde ese punto de montaje.<\/p><p>Nota: Toda vez que se utilicen subvol\u00famenes se debe considerar que los subvolumenes constituyen una barrera para el snapshot del nivel superior. La instant\u00e1nea se crea para todos los archivos de un volumen\/subvolumen sin atravesar subvolumenes. Si se nos pasa en un snapshot alg\u00fan subdirectorio que es un subvolumen, ese subdirectorio no tendr\u00e1 ning\u00fan dato en el snapshot creado.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t","protected":false},"excerpt":{"rendered":"<p>Uso de la tecnolog\u00eda BTRFS Nota: Este documento solo tiene la funci\u00f3n pedag\u00f3gica de ense\u00f1ar como utilizar esta tecnolog\u00eda, no haci\u00e9ndose responsables los autores por ning\u00fan problema o informaci\u00f3n o perdida de datos que el intento de aplicar lo aqu\u00ed mencionado produzca. Hasta no conocer bien la tecnolog\u00eda se sugiere\u2026<\/p>\n<p> <a class=\"continue-reading-link\" href=\"https:\/\/www.marianoacciardi.com.ar\/?page_id=1332\"><span>Continue reading<\/span><i class=\"crycon-right-dir\"><\/i><\/a> <\/p>\n","protected":false},"author":1,"featured_media":0,"parent":0,"menu_order":0,"comment_status":"closed","ping_status":"closed","template":"","meta":{"_eb_attr":"","footnotes":""},"class_list":["post-1332","page","type-page","status-publish","hentry"],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/www.marianoacciardi.com.ar\/index.php?rest_route=\/wp\/v2\/pages\/1332","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.marianoacciardi.com.ar\/index.php?rest_route=\/wp\/v2\/pages"}],"about":[{"href":"https:\/\/www.marianoacciardi.com.ar\/index.php?rest_route=\/wp\/v2\/types\/page"}],"author":[{"embeddable":true,"href":"https:\/\/www.marianoacciardi.com.ar\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.marianoacciardi.com.ar\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=1332"}],"version-history":[{"count":29,"href":"https:\/\/www.marianoacciardi.com.ar\/index.php?rest_route=\/wp\/v2\/pages\/1332\/revisions"}],"predecessor-version":[{"id":1366,"href":"https:\/\/www.marianoacciardi.com.ar\/index.php?rest_route=\/wp\/v2\/pages\/1332\/revisions\/1366"}],"wp:attachment":[{"href":"https:\/\/www.marianoacciardi.com.ar\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=1332"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}