A partir de la versi\u00f3n OpenSUSE 13.2 el sistema de ficheros por defecto es el nuevo Btrfs. Este sistema es el sustituto del ext4. Btrfs, b-tree fs, basado en la funcionalidad copy-on-write y entendido como un \u201cbetter FS\u201d, aporta rapidez, robustez y muchas posibilidades. Entre ellas la que hoy nos ocupa, los \u201csnapshots\u201d.<\/p>\n
<\/p>\n
A partir de la versi\u00f3n OpenSUSE 13.2 el sistema de ficheros por defecto es el nuevo Btrfs. Este sistema es el sustituto del ext4. Btrfs, b-tree fs, basado en la funcionalidad copy-on-write y entendido como un \u201cbetter FS\u201d, aporta rapidez, robustez y muchas posibilidades. Entre ellas la que hoy nos ocupa, los \u201csnapshots\u201d.<\/p>\n
El t\u00e9rmino \u201csnapshot\u201d se utiliza en distintos entornos, y hace mucho tiempo que ha estado disponible. Sin embargo, en estos momentos, el soporte que ofrece Opensuse 13.2 y superiores (ya ha salido la OpenSUSE Leap 34.1) permite aplicarlos para casos de uso muy cotidianos y \u00fatiles.<\/p>\n
Para probar las bondades de los snapshots, montamos un servidor de pruebas, y creamos una partici\u00f3n de tipo Btrfs.<\/p>\n
Formateamos la partici\u00f3n:<\/p>\n
\r\nmiserver \/root# cfdisk \/dev\/sdb\r\nDisk: \/dev\/sdb\r\nSize: 15 GiB, 16106127360 bytes, 31457280 sectors\r\nLabel: dos, identifier: 0x0a20e307\r\n\r\nDevice Boot Start Sectors Size Id Type \r\n>> \/dev\/sdb1 2048 31457279 31455232 15G 83 Linux \r\n<\/pre>\nCreamos el file system, de tipo Btrfs:<\/p>\n
\r\nmiserver \/root# mkfs.btrfs \/dev\/sdb1 \r\nbtrfs-progs v4.1.2+20151002\r\nSee http:\/\/btrfs.wiki.kernel.org for more information.\r\n\r\nLabel: (null)\r\nUUID: ffce50d9-ab70-4712-a4d1-8b87b638d655\r\nNode size: 16384\r\nSector size: 4096\r\nFilesystem size: 15.00GiB\r\nBlock group profiles:\r\n Data: single 8.00MiB\r\n Metadata: DUP 1.01GiB\r\n System: DUP 12.00MiB\r\nSSD detected: no\r\nIncompat features: extref, skinny-metadata\r\nNumber of devices: 1\r\nDevices:\r\n ID SIZE PATH\r\n 1 15.00GiB \/dev\/sdb1\r\nmiserver \/root# \r\n<\/pre>\nMontamos el file system y comprobamos que es ‘btrfs’:<\/p>\n
\r\nmiserver \/root# mkdir \/mibtrfs\r\nmiserver \/root# mount \/dev\/sdb1 \/mibtrfs\r\nmiserver \/root# mount | grep mibt\r\n\/dev\/sdb1 on \/mibtrfs type btrfs (rw,relatime,space_cache,subvolid=5,subvol=\/)\r\nmiserver \/root#\r\n<\/pre>\nCada partici\u00f3n de la que queramos mantener snapshots, debe tener una configuraci\u00f3n propia. Al iniciar el sistema, no hay ninguna configuraci\u00f3n disponible. El sistema nos obliga a tener una configuraci\u00f3n por cada partici\u00f3n sobre la que queramos tomar \u201csnapshots\u201d, porque pueden tener par\u00e1metros de configuraci\u00f3n distintos.<\/p>\n
\r\nmiserver \/root# snapper list-configs\r\nConfig | Subvolume\r\n-------+----------\r\n<\/pre>\nVamos a crear una configuraci\u00f3n para mantener los snapshots de nuestra partici\u00f3n \/mibtrfs:<\/p>\n
\r\nmiserver \/root# snapper -c mibtrfs create-config \/mibtrfs\/\r\nmiserver \/root# snapper list-configs\r\nConfig | Subvolume\r\n--------+----------\r\nmibtrfs | \/mibtrfs \r\nmiserver \/root#\r\n<\/pre>\nDada esta configuraci\u00f3n, listamos los snapshots disponibles:<\/p>\n
\r\nmiserver \/root# snapper -c mibtrfs list\r\nType | # | Pre # | Date | User | Cleanup | Description | Userdata\r\n-------+---+-------+------+------+---------+-------------+---------\r\nsingle | 0 | | | root | | current | \r\n\r\n<\/pre>\nAhora creamos el primer snapshot:<\/p>\n
\r\nmiserver \/root# snapper -c mibtrfs create --description \"snapshot despues de crear el filesystem\" \r\n<\/pre>\nVolvemos a listar los snapshots disponibles:<\/p>\n
\r\nmiserver \/root# snapper -c mibtrfs list\r\nType | # | Pre # | Date | User | Cleanup | Description | Userdata\r\n-------+---+-------+--------------------------+------+---------+-----------------------------------------+---------\r\nsingle | 0 | | | root | | current | \r\nsingle | 1 | | Tue Mar 29 17:05:27 2016 | root | | snapshot despues de crear el filesystem | \r\nmiserver \/root# \r\n<\/pre>\nComprobamos si hay diferencias entre el snapshot 1 y el estado actual, y no hay diferencias, porque no ha habido actividad en el file system.<\/p>\n
\r\nmiserver \/root# snapper -c mibtrfs status 1..0\r\nmiserver \/root# \r\n<\/pre>\nCreamos un fichero y comprobaremos otra vez las diferencias. Ahora, nos aparece el fichero nuevo que hemos creado.<\/p>\n
\r\nmiserver \/root# touch \/mibtrfs\/PROVA\r\n\r\nmiserver \/root# snapper -c mibtrfs status 1..0\r\n+..... \/mibtrfs\/PROVA\r\nmiserver \/root# \r\nmiserver \/root# \r\n\r\n<\/pre>\nVolvemos a copiar algunos ficheros m\u00e1s y volvemos a comprobar:<\/p>\n
\r\ncp -a \/usr\/lib64\/yui\/ \/mibtrfs\/\r\n\r\nmiserver \/root# snapper -c mibtrfs status 1..0\r\n+..... \/mibtrfs\/PROVA\r\n+..... \/mibtrfs\/yui\r\n+..... \/mibtrfs\/yui\/libyui-ncurses-pkg.so.7\r\n+..... \/mibtrfs\/yui\/libyui-ncurses-pkg.so.7.0.0\r\n+..... \/mibtrfs\/yui\/libyui-ncurses.so.7\r\n+..... \/mibtrfs\/yui\/libyui-ncurses.so.7.0.0\r\nmiserver \/root#\r\n<\/pre>\nAhora creamos un snapshot:<\/p>\n
\r\nmiserver \/root# snapper -c mibtrfs create --description \"PROVA y libyui creados\" \r\nmiserver \/root# snapper -c mibtrfs list\r\nType | # | Pre # | Date | User | Cleanup | Description | Userdata\r\n-------+---+-------+--------------------------+------+---------+-----------------------------------------+---------\r\nsingle | 0 | | | root | | current | \r\nsingle | 1 | | Tue Mar 29 17:05:27 2016 | root | | snapshot despues de crear el filesystem | \r\nsingle | 2 | | Wed Mar 30 10:54:18 2016 | root | PROVA y libyui creados | \r\n<\/pre>\nVeamos las diferencias entre los 2 snapshots disponibles, y vemos los cambios, que corresponden a los ficheros nuevos. Lo mismo, si hubi\u00e9ramos hecho borrados y\/o modificaciones.<\/p>\n
\r\nmiserver \/root# snapper -c mibtrfs status 1..0\r\n+..... \/mibtrfs\/PROVA\r\n+..... \/mibtrfs\/yui\r\n+..... \/mibtrfs\/yui\/libyui-ncurses-pkg.so.7\r\n+..... \/mibtrfs\/yui\/libyui-ncurses-pkg.so.7.0.0\r\n+..... \/mibtrfs\/yui\/libyui-ncurses.so.7\r\n+..... \/mibtrfs\/yui\/libyui-ncurses.so.7.0.0\r\n<\/pre>\nSi los cambios no nos interesan, podr\u00edamos volver atr\u00e1s en el tiempo y restaurar el estado existente en el snapshot n\u00famero 1:<\/p>\n
\r\nmiserver \/root# snapper -c mibtrfs -v undochange 1..2\r\ncreate:0 modify:0 delete:6\r\ndeleting \/mibtrfs\/yui\/libyui-ncurses.so.7.0.0\r\ndeleting \/mibtrfs\/yui\/libyui-ncurses.so.7\r\ndeleting \/mibtrfs\/yui\/libyui-ncurses-pkg.so.7.0.0\r\ndeleting \/mibtrfs\/yui\/libyui-ncurses-pkg.so.7\r\ndeleting \/mibtrfs\/yui\r\ndeleting \/mibtrfs\/PROVA\r\nmiserver \/root# \r\n<\/pre>\nAparte de los snapshots que se hacen bajo demanda, el sistema, a trav\u00e9s del cron y usando la utilidad snapper, va haciendo cada hora, un snapshot de seguridad, a no ser que lo desactivemos expl\u00edcitamente. Veamos los snapshots disponibles despu\u00e9s de varias horas de actividad:<\/p>\n
\r\nmiserver \/etc\/cron.daily# snapper -c mibtrfs list\r\nType | # | Pre # | Date | User | Cleanup | Description | Userdata\r\n-------+---+-------+--------------------------+------+----------+-----------------------------------------+---------\r\nsingle | 0 | | | root | | current | \r\nsingle | 1 | | Tue Mar 29 17:05:27 2016 | root | | snapshot despues de crear el filesystem | \r\nsingle | 2 | | Wed Mar 30 10:54:18 2016 | root | | PROVA y libyui creados | \r\nsingle | 3 | | Wed Mar 30 11:30:01 2016 | root | timeline | timeline | \r\nsingle | 4 | | Wed Mar 30 12:30:01 2016 | root | timeline | timeline | \r\nsingle | 5 | | Wed Mar 30 13:30:01 2016 | root | timeline | timeline | \r\nmiserver \/etc\/cron.daily#\r\n<\/pre>\nHemos aplicado los snapshots en una partici\u00f3n de usuario o de datos. OpenSUSE permite el file system Btrfs en la partici\u00f3n root y \/usr permitiendo aplicar los beneficios de los snapshots a esta partici\u00f3n. Esto permite que cada vez que hagamos un update de sistema, o cuando hacemos un mantenimiento con resultados desconocidos, podamos hacer un snapshot antes del cambio, para luego poder volver a ese punto de recuperaci\u00f3n.<\/p>\n
Aplicaciones de los snapshots<\/h2>\n
\n
- \n
Deshacer cambios<\/h3>\n
En el tutorial que hemos comentado al principio, vemos como deshacer cambios. Con el comando snapper y la opci\u00f3n undochange conseguiremos \u201cretornar\u201d al estado anterior.<\/p>\n<\/li>\n
- \n
Recuperar ficheros de snapshots almacenados<\/h3>\n
De la misma forma que hemos deshecho completamente los cambios de todo un snapshot, podemos recuperar s\u00f3lo un fichero contenido en ese snapshot.<\/p>\n
\r\nsnapper -cdiff SNAPSHOT_ID..0 NOMBRE_FICHERO<\/config><\/pre>\n<\/li>\n - \n
System rollback<\/h3>\n
Una vez comprendemos como se utilizan los snapshots, la idea es no utilizarlos manualmente, si no que sean las aplicaciones las que lo utilizan.<\/p>\n
Por ejemplo, instalando snapper-zypp-plugin, conseguiremos que zypper, cuando instale alg\u00fan paquete, nos haga un snapshot antes de la instalaci\u00f3n, para poder hacer una vuelta atr\u00e1s en caso de que se haya desconfigurado algo.<\/p>\n
Los snapshots en la partici\u00f3n root prevendr\u00e1n problemas de arranque. Imaginemos que borramos el fichero \/bin\/bash, en cuyo caso el sistema no botar\u00e1. Si hemos tenido la precauci\u00f3n de hacer un snapshot antes de ese borrado, podremos botar usando ese snapshot.
\n\tLa secuencia ser\u00eda:<\/p>\n\r\nsnapper create --description \"estado correcto\u201d --print-number\r\n35\r\nrm \/bin\/bash\r\n <\/pre>\nEl sistema ahora ya no bota.<\/p>\n
Al botar, a\u00f1adiremos el siguiente par\u00e1metro al kernel:<\/p>\n
\r\nrootflags=subvol=.snapshots\/35\/snapshot<\/pre>\nEl sistema botar\u00e1 correctamente.<\/p>\n
Una vez en marcha, ejecutaremos snapper rollback, para hacer efectivo el cambio, y ya podremos rebotar normalmente.<\/p>\n<\/li>\n
- \n
Crear snapshots manualmente<\/h3>\n
La utilidad principal de los snapshots, es cuando se hacen en la partici\u00f3n root (\/) , para tener historia en los directorios \/etc, y tambi\u00e9n cuando los conectamos a la utilidad de instalaci\u00f3n de paquetes, zypper.<\/p>\n
Es decir, usados como punto de recuperaci\u00f3n a un estado conocido, cuando nos disponemos a realizar cambios.<\/p>\n
Por otro lado, podemos usarlos para tener un backup de ficheros en las particiones de usuario. Esta afirmaci\u00f3n hay que matizarla. No es realmente un backup, que nos protege de si se corrompe el file system o el medio. Nos protege ante p\u00e9rdidas de fichero por parte del usuario.
\n\tPor tanto, un snapshot diario de la partici\u00f3n de usuarios, nos permite poder recuperar r\u00e1pidamente, un fichero a fecha de ayer. Si guardamos los 2 \u00faltimos snapshots, tendremos una memoria de 2 d\u00edas.<\/p>\nHay que tener en cuenta que el snapshot, una vez realizado no consume espacio de disco, solo se trabaja con punteros. El snapshot ir\u00e1 creciendo en base al n\u00famero de ficheros que cambien.<\/p>\n
Un ciclo \u00fatil de snapshots, ser\u00eda guardar 7 snapshots, uno por d\u00eda, y reciclarlos a la semana siguiente. Esto, reforzado con un backup semanal total. Pero, recordemos, que el snapshot se almacena en la propia partici\u00f3n, de tal forma, que si se corrompe la partici\u00f3n, el snapshot ya no ser\u00eda accesible, y no podremos recuperar.<\/p>\n<\/li>\n<\/ul>\n
Conclusi\u00f3n<\/h2>\n
Las nuevas versiones de las distribuciones, entre ellas, openSUSE 13.2, openSUSE Leap 42.1, Ubuntu 14 entre otras, nos ofrecen la posibilidad de trabajar de forma nativa con el file system Btrfs. Este sistema, que usa la funcionalidad \u201ccopy_on_write\u201d, permite realizar snapshots, de una forma muy eficiente y robusta. Un snapshot nos ofrece un punto de recuperaci\u00f3n al que volver cuando el sistema ha llegado a un punto err\u00f3neo.<\/p>\n
En el futuro inmediato, habr\u00e1 que tener en cuenta este sistema, para saber aprovecharlo al m\u00e1ximo. Tambi\u00e9n el file system, Btrfs, dispone de otras funcionalidades que se deber\u00e1n aprovechar, como son los subvolumes. Por otro lado, tiene que quedar claro que el snapshot no sustituye a la herramienta de backup, solamente la complementa.<\/p>\n
<\/p>\n","protected":false},"excerpt":{"rendered":"
A partir de la versi\u00f3n OpenSUSE 13.2 el sistema de ficheros por defecto es el nuevo Btrfs. Este sistema es el sustituto del ext4. Btrfs, b-tree fs, basado en la funcionalidad copy-on-write y entendido como un \u201cbetter FS\u201d, aporta rapidez, robustez y muchas posibilidades. Entre ellas la que hoy nos ocupa, los \u201csnapshots\u201d.<\/p>\n","protected":false},"author":594,"featured_media":1991,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[],"experteses":[17],"class_list":["post-1994","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-uncategorized-ca","experteses-entornosyserviciosticdesoportealaprendizaje-es"],"acf":[],"_links":{"self":[{"href":"https:\/\/inlab.fib.upc.edu\/es\/wp-json\/wp\/v2\/posts\/1994","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/inlab.fib.upc.edu\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/inlab.fib.upc.edu\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/inlab.fib.upc.edu\/es\/wp-json\/wp\/v2\/users\/594"}],"replies":[{"embeddable":true,"href":"https:\/\/inlab.fib.upc.edu\/es\/wp-json\/wp\/v2\/comments?post=1994"}],"version-history":[{"count":0,"href":"https:\/\/inlab.fib.upc.edu\/es\/wp-json\/wp\/v2\/posts\/1994\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/inlab.fib.upc.edu\/es\/wp-json\/wp\/v2\/media\/1991"}],"wp:attachment":[{"href":"https:\/\/inlab.fib.upc.edu\/es\/wp-json\/wp\/v2\/media?parent=1994"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/inlab.fib.upc.edu\/es\/wp-json\/wp\/v2\/categories?post=1994"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/inlab.fib.upc.edu\/es\/wp-json\/wp\/v2\/tags?post=1994"},{"taxonomy":"experteses","embeddable":true,"href":"https:\/\/inlab.fib.upc.edu\/es\/wp-json\/wp\/v2\/experteses?post=1994"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}